Public folder implementation and migration are similar in Exchange Server 2003 and Exchange 2000 Server, and moving or rehoming user public folders (folders that contain users' documents) from an Exchange Server 5.5 server to an Exchange 2003 server is simple. However, migrating system public folders, which contain data relating to items such as Offline Address Books and Schedule+ free/busy information, is somewhat different. Here are some techniques for implementing your public folder infrastructure and for moving or migrating user and system public folders. The procedures are the same for Exchange 2003 and Exchange 2000 servers unless otherwise noted. The migration techniques that I describe in this article apply only to migrations within an organization, not to the more complex interorganizational migrations.
Efficient Public Folder Access
Your usage of public folders determines the number and location of your public folder replicas. If your company uses many public folders (e.g., more than 200), consider locating public folder content on servers that are near those folders' users. You can do so by replicating the folders to multiple servers distributed across the network. Alternatively, you can use high-bandwidth, low-latency connections between clients and a few core public folder servers to ensure that public folder access is as fast as possible.
For public folders that receive several hundred connections a day, you should designate at least one server per routing group to host public folder content. For business-critical public folder data, you might want to have multiple replicas of the content within a routing group. You can maintain less frequently accessed content (e.g., folders that receive fewer than 100 reads or updates per day according to reporting tools) on one server or on several servers that aren't necessarily distributed across your network.
When an Outlook client requests public folder content, the Exchange Information Store service on the client's home server determines the location of the requested content. If the content is on the same server or another server in the same routing group, the Information Store service directs the client to the appropriate server's public folder database. If the content is on a server outside the routing group, the Information Store service performs a public folder referral to direct the client to the remote server in another routing group that hosts the requested content. (In Exchange 5.5, this feature is known as public folder affinity.) If only one such remote server exists in the organization, the Information Store service directs the user to that server. If multiple remote servers host the required content, the service uses the costs associated with the routing group connectors, SMTP connectors, or X.400 connectors that link the routing groups to calculate the lowest-cost transitive route to the remote server. For example, if a client on the network that Figure 1 shows requests public folder content that's stored on servers C and D, the Information Store service chooses the less expensive option and directs the connection to Server C.
If the Do not allow public folder referrals check box is selected on a connector's Properties page, the Information Store service ignores that path to public folder content. If routes to multiple remote servers have the same cost, the client randomly selects a route to use. If the Information Store service can't determine a route, the client can't access the public folder content.
When the Information Store service calculates the lowest-cost route to a particular server, the Information Store service caches the route information on the user's home server for 60 minutes so that Exchange can more efficiently service subsequent requests for access to the same content. (You can't change the cached information; however, you can flush the cache by restarting the Information Store service.) Additionally, after the client initially contacts a public folder server, it persistently uses that public folder server for the 60-minute lifetime of the cache entry to ensure a consistent view of public folder information as long as the client connection remains intact.
Affinity-Based Referrals
Exchange 2003 reintroduced the public folder affinity feature that appeared in Exchange 5.5. Exchange 5.5 has no transitive routing mechanism to determine where it should direct a client for specific public folder content. Instead, you explicitly define a server for a particular public folder, and Exchange 5.5 always directs referrals to that server. Exchange 2000 lacks this public folder affinity capability. However, this feature is included in Exchange 2003, giving administrators more flexibility for dealing with public folder referrals.
Exchange 2003 lets you set public folder affinity costs on a server-by-server basis. For example, say that your home mailbox server is OSBEX01 and you host specific public folder content on server OSBEX02. You can set the Public Folder Referrals property of OSBEX01 by selecting and right-clicking the server within Exchange System Manager (ESM), clicking Properties, going to the Public Folder Referrals tab, clicking Add, and entering information about OSBEX02. Exchange then directs all public folder referrals to OSBEX02, as Figure 2 shows.
This Exchange 2003 affinity mechanism doesn't let you implement much granularity. (However, Exchange 5.5 does allow public folder referrals to subsites/locations.) Nor can you use public folder referrals based on routing costs as a fallback; you must use either public folder referrals or routing group connector costs. However, you can define multiple affinity servers and associate a cost with each; Exchange uses the lowest-cost affinity server available for client referrals.
Entering server information on the Public Folder Referrals tab sets the msExchFolderAffinityCustom attribute to 1. The cost values you enter for the affinity servers are in the msExchFolderAffinityList multivalued attribute. You can review these settings using the ADSI Edit utility or the Ldp utility; both attributes are properties of the CN=Configuration Container/CN=Services/CN=Microsoft Exchange/CN=OrgName/CN=Administrative Groups/CN=SiteName/CN=Servers/CN=ServerName object in Active Directory (AD), where OrgName is the name of your Exchange organization, SiteName is your Exchange site, and ServerName is your Exchange server. From a deployment perspective, you can easily populate these values programmatically using an approach such as Collaboration Data Objects for Exchange Management (CDOEXM).