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).
Preparing to Move or Migrate
When you simply move public folders from one Exchange 2003 server to another, little preparation is required. However, you must ensure that the destination Exchange 2003 server has enough free disk space for the public folder database and transaction logs of the source public folders. As a rule, the volumes that will host the public folder database and the transaction logs should have at least 30 percent free space. Because moving a large amount of public folder content can affect performance of the source and destination servers and of the intervening network links, you should always perform public folder moves during nonbusiness hours. (Pay attention to the volume of log files that such moves generate because numerous public folder moves can cause the log files' size to grow considerably and consume disk space.)
Before you migrate public folders from an Exchange 2000 or Exchange 5.5 server to an Exchange 2003 server, you must complete some preparatory tasks. First, ensure that the domain that holds Universal Security Groups (USGs) that will be associated with public folders on the Exchange 2003 server is in Windows native mode. USGs can exist only in a native-mode Windows domain, and only USGs let you enforce permissions on public folders.
Second, check that all recipient connection agreements from the Exchange 5.5 Directory Service (DS) to AD are correct and in place and that all objects replicate successfully. You can use Exchange 2003's ExDeploy tools to validate successful replication. Exchange 2003 is more forgiving of incomplete Active Directory Connector (ADC) recipient replication than Exchange 2000 is. Incomplete replication in Exchange produces so-called "zombie users" who are specified in the public folder's ACL but aren't in AD. For example, users specified in a public folder ACL might not yet be replicated from the Exchange 5.5 DS to AD.
When Exchange 2000 discovers zombie users in a public folder's ACL, Exchange 2000 blocks access to the public folder for everyone except the public folder owner. With Exchange 2000 Service Pack 1 (SP1), Exchange blocks access for everyone only if the ACL has never been correctly evaluated before. Exchange 2003 and Exchange 2000 SP3 with the post-SP3 hotfixes provide an even better solution to zombie users by adding the "Ignore zombie users" registry key. When this key is set, Exchange ignores zombie users identified in an ACL, even the first time Exchange evaluates the ACL.
Before you migrate from Exchange 5.5, you should run the DS/Information Store (IS) consistency adjuster against Exchange 5.5 public folders. To access the DS/IS consistency adjuster, open the Properties page of an Exchange 5.5 server that hosts public folders, click the Advanced tab, then click All inconsistencies. By verifying that users named on ACLs are valid users, the consistency adjuster ensures that ACLs on the public folders remain when you replicate public folder contents. You should also ensure that all Exchange 5.5 servers are accessible; Exchange will rehome public folder entries that it can't resolve back to a public folder home server. Migrating public folders from an Exchange 2000 or Exchange 5.5 source server to a destination server running Exchange 2003 or Exchange 2000 simply by replicating content and then removing the source server works well for most public folder data.
Rehoming Public Folders
Rehoming user public folders to an Exchange 2003 system is straightforward even when the public folders you want to move are on a legacy Exchange 5.5 server. Simply follow these steps:
- Start the Exchange 2003 ESM. Expand Administrative Groups, navigate to the site that contains the public folders you want to move, then navigate to Folders, Public Folders.
- Right-click the first public folder you want to rehome and choose Properties.
- Click the Replication tab, click Add, then select the server on which you want the public folder replica to appear.
- Click Apply.
- Right-click the desired public folder again, click All Tasks, click Propagate Settings, select the Replicas check box, then click OK.
This procedure replicates user public folders to the destination servers. After replication is complete, you can choose to remove the public folder from the original server. To confirm replication of a public folder, right-click the folder in ESM, click Properties, click the Replication tab, then click Details. A Replication Status value of In Sync indicates a successful replication.
You might also have to rehome system public folders, typically those on the first Exchange 5.5 server installed in the site. You can also perform this replication from ESM:
- Expand Administrative Groups, navigate to the site that contains the public folders you want to move, then navigate to Folders, Public Folders.
- Right-click Public Folders and select View System Folders. Follow Steps 3 and 4 for each system folder that Table 1 shows.
- For each system folder, select the object, right-click it, and select Properties.
- Click the Replication tab and make sure that an Exchange 2003 public folder server has a replica of the system public folder. If necessary, add an Exchange 2003 public folder.
You might see other system public folders, but you can safely ignore them because they are already homed on Exchange 2003 servers. (You can verify this fact through the public folder's Properties page.) After the system public folders are replicated, you can remove the original from the source server.
Using pfMigrate
Although the manual process described earlier works well, using it to move many top-level public folders can be tedious. To automate the migration process, Microsoft supplies the Public Folder Migration Tool (pfmigrate.wsf) on the Exchange 2003 CD-ROM in the \support\exdeploy folder. pfMigrate is a command-line script that lets you create replicas of user and system public folders. You can use pfMigrate to create replicas only on a new server and within a routing group. Furthermore, you must execute pfMigrate from an Exchange Administrator account that has administrator permissions to either the public folders you're moving or higher in the public folder hierarchy.
To generate a report that shows how many public folders are on an Exchange server, you can run pfMigrate with the /r parameter. If neither the source nor target server is an Exchange 2003 system, you must use the /wmi switch to specify an Exchange 2003 server on your network that can supply Windows Management Instrumentation (WMI) services because Exchange modifies WMI counters during the move operation.
Be aware that pfMigrate operates against the Messaging API (MAPI) public folder Top-Level Hierarchy (TLH) only; you can't use it for other applications' TLH public folders. Also, you can't specify a particular public folder or public folder tree to move--you must specify individual folders.
Although pfMigrate performs many functions, one way you can use it is to replicate user public folders from a source server to a target server. To do so, use the following syntax:
pfmigrate.wsf /s:<source> /t:<target> /a /n:10 /f:c:\pfmigrate.log
where source is the source server and target is the target server. The /a parameter indicates an add replica operation, /n defines the number of public folders to move, and /f defines the log file. If the number of public folders to be moved specified by the /n parameter is less than the total number of public folders on the source server, the remaining public folders stay on the source server. You must use the /n parameter with the /a parameter.
After the user public folders are replicated, you can delete replicas from the source server by using the following command:
pfmigrate.wsf /s:<source> /t:<target> /d /f:c: pfmigrate.log
The /d parameter activates a delete replica operation from the source server for any public folder that has a replica on the target server. After you delete the replicas, you can remove the server from the organization.
To move system public folders, use the syntax
pfmigrate.wsf /s:<source> /t:<target> /a /n:10 /sf /f:c:\pfmigrate.log
The /sf parameter specifies that system folders will be deleted. You can obtain a full description of pfMigrate's syntax by executing the pfmigrate.wsf command with no parameters.
Happier Migration
Although public folders haven't changed greatly in Exchange 2003, they've changed in subtle ways. Administrators should find no big surprises with public folder deployment and migration, but the improvements I describe can ease the pain associated with managing these often-dreaded features.
| RESOURCES |
|
MICROSOFT ARTICLES "Troubleshooting Public Folder Performance Issues Related to ACL Conversions" http://support.microsoft.com/?kbid=328880 "Using the Ignore Zombie Users Registry Key" http://support.microsoft.com/?kbid=812963 "XGEN: March 2003 Exchange 2000 Server Post-Service Pack 3 Rollup" http://support.microsoft.com/?kbid=813840 |
