Article ID: 843107
Article Last Modified on 10/30/2007
APPLIES TO
- Microsoft Exchange Server 2003 Service Pack 1
SUMMARY
The Microsoft Exchange Server 2003 Public Folder Migration tool (pfMigrate) has been updated in Exchange Server 2003 Service Pack 1 (SP1). You can use this tool to consolidate your Exchange sites or administrative groups into centralized sites. By using this updated tool, you can move public folders across administrative groups. This tool is a command-line tool. You use this tool to create a public folder replica on a Microsoft Exchange 2000 Server computer or on an Exchange Server 2003 computer from a Microsoft Exchange Server 5.5 site, from an Exchange 2000 Server administrative group, or from an Exchange Server 2003 administrative group. You can then use this tool to remove the public folder replica from the source site or from the administrative group.
The following requirements must be met to use this tool:
- You must have sufficient permissions in both the source site and the destination administrative group.
- You must upgrade all the Active Directory Connectors to the Exchange Server 2003 SP1 versions.
- You must have an Exchange Server 2003 SP1 computer available to act as a Windows Management Instrumentation (WMI) provider for the public folder move operation.
- You must have an Exchange Server 5.5 computer available if you migrate public folders from an Exchange Server 5.5 site.
Additionally, you must consider certain behaviors that occur both during and after you move the public folders. For example, during the public folder move operation, the public folders may be unavailable for client access. After you move the public folders, features such as message journaling or third-party programs that use the moved public folder may no longer work.
IN THIS TASK
- INTRODUCTION
- How to use the updated pfMigrate tool
- Supported environments for the pfMigrate tool
- Unsupported environments for the pfMigrate tool
- The process that occurs during a public folder move operation
- Permissions that are required for the move
- Things to consider before you use the pfMigrate tool
- Things to consider after you use the pfMigrate tool
- REFERENCES
INTRODUCTION
This article describes how to use the Microsoft Exchange Public Folder Migration tool (pfMigrate.wsf) to move Exchange public folders and to help consolidate public folders into larger, central sites.
The pfMigrate tool is a command-line script that administrators can use to create replicas of system folders and of public folders. This tool has been updated in Exchange Server 2003 Service Pack 1 (SP1). To obtain the pfMigrate tool, use either of the following methods:
- Open the Support\ExDeploy folder on the Exchange Server 2003 CD-ROM.
- Visit the following Microsoft Web site to download the most recent version of the Exchange Server Deployment Tools installation:
Note The security and authentication model for incoming e-mail from outside the Exchange organization has changed since Exchange Server 5.5. E-mail that is destined to mail-enabled public folders from outside the organization is considered to be from "anonymous" users. Therefore, the "default" user setting of "contributor" will not allow messages from the Internet to be sent to public folders. Folders that are migrated to Exchange 2000 Server and to Exchange Server 2003 will have to have the "anonymous" user rights changed to at least "contributor" to enable them to receive mail from external systems.back to the top
How to use the updated pfMigrate tool
To move public folders between sites, you must use the new, updated version of the pfMigrate tool. The updated version is included with Exchange Server 2003 SP1. The pfMigrate script has been updated for Exchange Server 2003 SP1 so that it functions across sites. In the version of the pfMigrate tool that is included with the original release version of Exchange Server 2003, the pfMigrate script is limited to adding folder replicas only within a site. By using the updated pfMigrate tool, you can replicate public folders from the source site to the destination site before you move the Exchange users. This behavior helps make public folders available throughout the migration process.
For more information about the earlier version of the pfMigrate tool , click the following article number to view the article in the Microsoft Knowledge Base:
822895 Overview of the Public Folder Migration tool
Note Although you can manually create public folder replicas instead of using the pfMigrate tool, we do not recommend this practice. If you perform a manual public folder migration, you lose custom proxy addresses on the public folders. Additionally, you lose the public folders' distribution list (DL) memberships.
How to create public folder replicas
To use the pfMigrate tool to create public folder replicas, use the following syntax:
pfMigrate /S: SourceServer /T: TargetServer /A /N:number /SC
To use the pfMigrate tool in report mode, use the following syntax:
pfMigrate /S: SourceServer /T: TargetServer /R /SC
The following list describes the command-line options for the pfMigrate tool:
- /SC This option directs the pfMigrate tool to perform a cross-administrative group add operation. The /SC option refers to "Site Consolidation."
Note When you do not use the /SC option, a typical add operation occurs. A typical add operation requires that both the source server and the destination server be in the same routing group. This is to help make sure that an administrator does not unintentionally add a public folder replica to a different administrative group without first considering the consequences of such an operation. If you unintentionally add a public folder replica across an administrative group and then you remove that replica, a temporary situation occurs. In this temporary situation, all e-mail messages that are sent to that public folder cause non-delivery report (NDR) messages. - /N When you use the /n option together with the /SC option, you can specify to migrate "ALL" public folders.
- /R This option directs the pfMigrate tool to generate a report. Use the /R option to show when all public folders have successfully been removed from the source server. Additionally, use the /R option to show when the destination server has fully populated the public folder replicas. This information helps you determine when you can remove the source Exchange Server computer after you migrate the public folders. To run this report for Exchange Server computers that are in different sites, you must use the /R option together with the /SC option. When you use the /R option, the report gives you the following information:
<number> total public folders on <SourceServer> <number> of those Folders have a replica on <SourceServer> and no replica on <DestinationServer>
When you generate a report after all the public folders have been migrated, you receive the following information:
0 total public folders on <SourceServer> 0 of those Folders have a replica on <SourceServer> and no replica on <DestinationServer>
- /SF The /SF option is blocked from use. The /SF option would duplicate system folders in the destination administrative group. You may think that you must replicate the free/busy system folder. However, you do not have to replicate this folder because mailboxes that are moved have their LegacyExchangeDN attribute changed. Therefore, these mailboxes must republish their free/busy folder information. To republish the free/busy folder information, start Microsoft Outlook, and then modify your calendar. Alternatively, you can use the UpdateFB tool to automate this process for many users. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
841658 Free and busy information for a resource must be re-posted in the calendar after a cross-site mailbox move in Exchange Server 2003
Similarly, the Exchange Server 5.5 Offline Address Book (OAB) is not needed in the new Exchange Server 2003 administrative group. Instead, the updated Exchange Server 2003 Offline Address Book is used. The only system folder that you may have to replicate is the EFORMS REGISTRY folder. If this folder is being used in the remote site, make sure that it has been replicated to the destination administrative group before you remove the source site.
How to rehome public folders after they are moved across an administrative group
After the replication of public folder content to the destination computer has been completed, you can remove the public folder replica from the source computer, and then rehome each public folder to a destination server in the central site or administrative group. Perform this procedure after all mailboxes have been moved from that source site to make sure that the public folder replica is not required by users in the source site. When you move public folders across an administrative group, changes are made to the Exchange Server 5.5 directory and to Active Directory directory service. However, these changes occur only after the pfMigrate tool is used with the /d option to remove the replicas from the source site.
To remove the public folder replicas from the source site and to then rehome each public folder to a destination computer in the central site or in the administrative group, use the following command:
pfMigrate /S: SourceServer /T: TargetServer /D /SC
You cannot remove a cross-administrative group public folder replica unless you use the /SC option. When you use the /SC option together with the /D option, functionality is added to the deletion process. This functionality indicates that all the following operations must be performed:
- The public folder must be moved to a new administrative group.
- The public folder home server must be updated.
- The LegacyExchangeDN attribute must be updated.
If you use the /D option without also using the /SC option, the pfMigrate tool has the same functionality as the earlier version of the pfMigrate tool. For additional information about the functionality that is included in the earlier version of the pfMigrate tool, see the "REFERENCES" section.
back to the top
Supported environments for the pfMigrate tool
The following describes the supported source and destination requirements to use the updated pfMigrate tool that is included in Exchange Server 2003 SP1.
The destination computer must be running Microsoft Exchange 2000 Server or Exchange Server 2003
When you use the pfMigrate tool to perform a public folder migration, the destination computer must be running Exchange 2000 Server or Exchange Server 2003. You cannot use an Exchange Server 5.5 computer as the destination computer. Additionally, no information store fixes are required to move a public folder across a site by using the pfMigrate tool that is included in Exchange Server 2003 SP1.
The source computer can be running Exchange Server 5.5, Exchange 2000 Server, or Exchange Server 2003
You can use the pfMigrate tool to migrate public folders from a computer that is running any one of the following Exchange Server versions:
- Exchange Server 5.5
- Exchange 2000 Server
- Exchange Server 2003
This is the same requirement as when you move mailboxes across an administrative group.
Exchange Server 2003 SP1 Active Directory Connectors are required
New logic exists in the version of the Active Directory Connector service that is included in Exchange Server 2003 SP1 to clean up the public folder objects and distribution list memberships of public folders. Therefore, you must upgrade all Active Directory Connectors (ADCs) in the Exchange organization to the version that is included in Exchange Server 2003 SP1.
You require two-way connection agreements
If you use the /SC switch with the pfMigrate tool, you must configure two-way ADC connection agreements (CAs) for all Exchange Server 5.5 sites. This behavior makes sure that the Exchange Server 5.5 directory obtains the correct updates and that the Active Directory Connector service can clean up distribution list memberships of the Exchange Server 5.5 public folder directory object. A public folder CA must be configured between the source site and the destination administrative group.
Note We recommend that you use the Exchange Server 2003 SP1 ADC Tools to configure the CAs.
Mixed mode Exchange requirements
If you are using the pfMigrate tool in a mixed mode environment, you must have at least one Exchange Server 5.5 computer available. The Site Replication Service (SRS) does not replace this requirement. Additionally, an Exchange Server 2003 SP1 computer is required to function as the Windows Management Instrumentation (WMI) server for the computer that you run the pfMigrate tool from.
Note You do not have to move the public folder or the public folders to an Exchange Server 2003 computer or to an Exchange Server 2003 SP1 computer. However, you must move the public folder or the public folders to a computer that is running Exchange 2000 Server or a later version.
WMI server requirements
The pfMigrate tool must have an Exchange Server 2003 SP1 computer to use to update the public folder replica list and to update the ptagFolderCDN attribute by using WMI. The pfMigrate tool uses the following order to determine which Exchange Server 2003 SP1 computer to connect to by using WMI:
- The Exchange Server 2003 SP1 computer that is specified by using the /WMI option.
- The Exchange Server 2003 SP1 computer that the pfMigrate tool is running on, if applicable.
- The Exchange Server 2003 SP1 destination server, if applicable.
Supported pfMigrate source and destination computers
The following table describes the supported source computers and the corresponding destination computers that you can use with the pfMigrate tool:
| Source | Destination |
| Exchange 5.5 SP3, SP4 | Exchange 2000 Server |
| Exchange 5.5 SP3, SP4 | Exchange Server 2003 |
| Exchange 2000 Server, SP1, SP2, SP3 | Exchange Server 2003 |
| Exchange 2000 Server, SP1, SP2, SP3 | Exchange Server 2003 |
| Exchange Server 2003, SP1 | Exchange Server 2003 |
| Exchange Server 2003, SP1 | Exchange Server 2003 |
Unsupported environments for the pfMigrate tool
The following scenarios are not supported for the updated pfMigrate tool.
Mixed-mode environment without an Exchange Server 5.5 computer
To use the pfMigrate tool, a mixed-mode environment must contain at least one Exchange Server 5.5 computer. A computer that is running Site Replication Service (SRS) does not count toward this requirement. In this scenario, you must either add an Exchange Server 5.5 computer to the organization or change the organization to run in native mode.
Note A native-mode cross-administrative group move is less complex because the legacyExchangeDN attribute does not have to be modified.
An environment that does not have an Exchange Server 2003 SP1 computer
To use the updated version of the pfMigrate tool, the organization must contain at least one Exchange Server 2003 SP1 computer. An Exchange Server 2003 SP1 computer is required as the WMI public folder provider.
An environment that uses an Application top-level hierarchy
You cannot use the pfMigrate tool to move items from an Application top-level hierarchy (TLH). The pfMigrate tool works only with the MAPI TLH. If you perform a site consolidation operation where the remote site is Exchange Server 5.5, this limitation is not a problem because Exchange Server 5.5 does not support a non-MAPI TLH. However, if the following conditions are true, the move operation is not supported:
- The remote site is Exchange 2000 Server or a later version.
- You have a non-MAPI TLH.
- The public folders are homed to that site.
In this scenario, you must use Exchange System Manager to add public folder replicas for the non-MAPI TLH.
An Exchange Server 5.5 destination server
When you use the pfMigrate tool together with the /SC option, you can create public folder replicas only on an Exchange 2000 Server destination server or on an Exchange Server 2003 destination server.
An environment that does not have a public folder connection agreement
Because the updated version of the pfMigrate tool modifies Active Directory when you move public folders to a new site, you must have a public folder connection agreement configured to create the new directory object in the Exchange Server 5.5 destination site.
back to the top
The process that occurs during a public folder move operation
To following describes the operations that occur to objects during a cross-site public folder move operation or during a cross-administrative group public folder move operation. Use this information to help troubleshoot any issues that you may experience when you move public folders.
Changes that are made to the Exchange Server 5.5 public folder directory object
The following changes are made directly to the Exchange Server 5.5 public folder directory object:
- The NM_MOVED_CROSS_SITE flag is added to the NT5 part of the msExchADCGlobalNames attribute.
This behavior effectively "unmatches" the Exchange Server 5.5 directory object from the corresponding Active Directory object. Although both ADC Global Names entries remain, the two objects no longer see themselves as matched. - The directory object is hidden from the Global Address List.
- All e-mail addresses are removed from the directory object.
Note This operation occurs on the Exchange Server 5.5 side only. Active Directory still contains the correct proxy addresses from previous Active Directory Connector replication operations. Therefore, new e-mail messages are delivered after the public folder is moved to the Exchange Server 2003 computer. - The alias of the directory object is changed. The new alias that is assigned is based on a GUID to make sure that it is unique.
- The following X.500 proxy addresses are assigned to the Exchange Server 5.5 directory object:
The "X500:ADCDeleteWhenUnlinked" proxy address tells the Active Directory connector to remove this Exchange Server 5.5 directory object when this object is no longer "linked." The Exchange Server 5.5 directory object is no longer linked when it is no longer a member of any distribution lists (DLs). The "X500:ADCDoNotReplicate" proxy address tells the Active Directory connector to no longer replicate changes that are made to this Exchange Server 5.5 directory object to Active Directory.
X500:ADCDeleteWhenUnlinked
X500:ADCDoNotReplicate
Changes made to the Active Directory public folder directory object
The following changes are made directly to the Active Directory public folder directory object:
- The NM_MOVED_CROSS_SITE flag is added to the EX5 part of the msExchADCGlobalNames attribute.
This behavior effectively "unmatches" the Active Directory object from the corresponding Exchange Server 5.5 directory object. Although both ADC Global Names entries remain, the two objects no longer see themselves as matched.
- The LegacyExchangeDN attribute is updated to point to the new destination site.
Because the Exchange Server 5.5 directory object is no longer matched with the corresponding Active Directory directory object, the Active Directory Connector service will automatically create a new object in the Exchange Server 5.5 or Site Replication Service directory during the next replication cycle. Therefore, Exchange Server 5.5 users will see the new object in the Global Address List.
Note The original directory object is now hidden from the Global Address List. This original directory object has a different Object Distinguished Name which maps to original LegacyExchangeDN from original site. Therefore, a new directory object must be created in the destination site.
- The X.500 proxy address that corresponds to the original LegacyExchangeDN is added to the directory object. This is to make sure that messages that were sent before the public folder was moved can be replied to successfully after the public folder move operation is completed.
- All backlinks in the Is-Member-Of attribute are parsed to find all the distribution list memberships of this directory object. The ReplicatedObjectVersion attribute on each distribution list is updated to make sure that the changed distribution list memberships are replicated to the Site Replication Service or to Exchange Server 5.5 computers. This change enables the Exchange Server 5.5 directory to determine that the original directory object is no longer "linked" to any distribution lists. Additionally, this change enables the Exchange Server 5.5 directory to determine that the new directory object is linked to the distribution lists.
Changes made to the store
The following change is made directly to the information store:
- The updated interface in WMI is used to expose the ptagFolderCDN MAPI property on the Exchange Server 2003 SP1 computer. This property is used to input the distinguished name (DN) of the new directory object.
Permissions that are required for the move
The pfMigrate tool requires the following permissions:
- Write permissions to Active Directory. The pfMigrate tool requires write permissions to Active Directory to update attributes on public folder objects.
- Write directory permissions in the source Exchange Server 5.5 site. The pfMigrate tool requires write directory permissions in the source Exchange Server 5.5 site to update the directory object in the Exchange Server 5.5 directory.
- Read access in the destination directory. The pfMigrate tool requires read access in the destination directory to confirm the presence of the DS/IS consistency adjuster hotfix. Particularly, the pfMigrate tool requires access to the Site Replication Service that owns the naming context for the destination site.
- Modify permissions for public folders in both the source and destination administrative group. The pfMigrate tool requires these permissions to modify the replica list of a public folder.
- The Exchange Administrator role in the administrative group where the source server and the destination server are located. If the source is a pure Exchange Server 5.5 site, the pfMigrate tool requires administrator permissions in the Exchange Server 5.5 site instead.
Things to consider before you use the pfMigrate tool
Consider all the following issues that you must prepare for before you use the pfMigrate tool to migrate public folders in your organization:
- You must upgrade all Active Directory connectors to the Exchange Server 2003 SP1 versions before you use the pfMigrate tool. You cannot move public folders between administrative groups until you upgrade all the Active Directory connectors in your organization to the Exchange Server 2003 SP1 versions.
This behavior occurs because the Exchange Server 2003 SP1 versions of the Active Directory Connector service and the ADC Tools contain new logic to handle a cross-administrative public folder move operation. - The read and unread status of messages in a public folder is lost when you move the public folder to the new server.
This behavior occurs because the read and unread status information of messages in a public folder is not replicated between servers. Therefore, after you move a public folder, all the messages appear as unread when a user accesses that public folder by using Outlook Web Access or by using Microsoft Outlook.
Note This behavior is not specific to cross-site or cross-administrative group move operations. This behavior occurs any time that you move a public folder replica. - Directory replication traffic increases during the public folder move operation.
This behavior occurs because a cross-administrative group move of a public folder must do both the following:- The move operation must update the public folder object of the public folder that you move.
- The move operation must access every distribution list or distribution group that the public folder belongs to.
Note These operations only occur when the public folder move operation removes the public folder replica. This behavior occurs to help clean up the distribution list membership in the Exchange Server 5.5 directory by providing an update for the Active Directory Connector service to replicate to Exchange Server 5.5.
The updates to the distribution group membership do not affect the actual group membership. Depending on inter-site replication in Exchange Server 5.5, replication from Active Directory to Exchange Server 5.5, and the administrative groups that the distribution groups belong to, not all group memberships are updated when you move the public folder. However, the Active Directory Connector service also has logic to clean up distribution list membership. This is to handle a scenario where a move mailbox operation does not have sufficient permissions to modify a distribution list. In this scenario, the move mailbox operation skips the modification of that distribution list.
- The public folder may be temporarily unavailable during the move operation. During the move operation, access to the public folder may be temporarily denied, not redirected to the new home of the public folder, or some of the public folder content may not appear in the newly-moved public folder.
This behavior may occur if one or both the following conditions are true:- If the public folder replica list is not updated on the user's server that accesses the newly-moved public folder, the user is directed to the original public folder replica. If the original public folder replica has been removed, the user cannot access this public folder. In this scenario, the user must wait until the public folder replica list is updated on their server. Typically, the public folder replica list is updated within five minutes of the move operation being completed.
- A user might be directed to the destination site to access the newly-moved public folder before all the public folder content is replicated to that new site. In this scenario, some of the content will not appear in the public folder.
- Access to public folders might be lost if public folder affinity is not set to the new destination site.
This behavior occurs if affinity is not configured for the destination "home" site of the public folder. Before you rehome the public folder, you must configure affinity for the new home site of that public folder, if it is not already configured. This behavior is not specific to cross-site public folder move operations. It also occurs when you move a public folder replica.
Things to consider after you use the pfMigrate tool
Consider the following behaviors that occur after you use the pfMigrate tool to perform a cross-administrative group public folder move operation:
- You may experience unreliable message delivery to the public folder during the cross-administrative group move.
This behavior may occur during the time that the Active Directory Connector service cleans up the Exchange Server 5.5 directory objects. In this scenario, when users send e-mail messages to the public folder, they might receive a non-delivery report (NDR) message. Typically, this NDR message contains an "access denied" error that contains the following error code:0x80070005
- Inbox rules that move e-mail messages to or from public folders, and that are based on the folder IDs (FIDs) of those public folders, no longer work after you perform a cross-administrative group move of those public folders. In this scenario, the rule generates an "Unable to find Destination Folder" error.
- Public folders may temporarily disappear from the Global Address List. After you perform a cross-administrative group move of a public folder, that public folder might no longer appear in the Global Address List in Exchange Server 5.5.
This behavior occurs because the original object from the source site is hidden from the Global Address List. In this scenario, there might be a delay before the new Exchange Server 5.5 object is replicated to the destination site by Active Directory.
Note This does not affect the public folders in Active Directory that were moved across administrative groups. The public folders do not disappear from the Global Address List of Exchange 2000 Server or of Exchange Server 2003. - Message journaling does not work after you move the public folder.
This behavior occurs because the moved public folder's LegacyDN attribute changes. If you rehome a public folder that is used for Exchange Server 5.5 or Exchange 2000 Server message journaling, message journaling stops working.
Note Starting with Exchange Server 2003, we recommend that you do not use a public folder as the message journaling archive. We recommend that you use a mailbox-enabled user as the journal recipient in your organization. To restate this, we recommend that you do not use a public folder or a contact as the journal mailbox when you implement message journaling in your organization. If you must archive messages to an external recipient, create a server-side rule to forward messages from the journal mailbox to the contact that you specified in the server-side rule. For more information about message journaling, click the following article number to view the article in the Microsoft Knowledge Base:843105 Troubleshooting message journaling in Exchange Server 2003 and in Exchange 2000 Server
- Organizational forms are not moved.
Organizational forms are part of the system folders and are not moved between sites. Therefore, you must manually update the public folder replica list for this system folder and for other system folders. - Third-party programs may no longer work after you move the public folder.
The pfMigrate tool does not perform special handling for third-party programs that are based on a public folder and on the LegacyDN attribute of that public folder. Therefore, the third-party program may no longer work after you move a public folder that is managed by a third-party program. - Moved public folders retain the proxy address from their original site. Additionally, the moved public folders do not have new proxy addresses assigned after being moved to a new administrative group. This behavior occurs even if the recipient policy is based on administrative group membership.
This behavior occurs because the Recipient Update Service does not stamp updated proxies when the public folder already has an existing proxy that is based on the original proxy addresses from the original site. If you require a new proxy address for a recipient policy that now applies based on the new administrative group membership, click Apply Now on the recipient policy, and then rebuild the Recipient Update Service.
Note Because the rebuilding of the Recipient Update Service affects server performance, we recommend that you rebuild the Recipient Update Service during a period of low client activity.
Even though the public folder's proxy addresses are not updated, e-mail flow is not affected. In this scenario, the only problem that you might experience is where your SMTP connector performs specific restriction checking. Consider the following scenario:- Administrative group "A" accepts e-mail for contoso.com.
- Administrative group "B" accepts e-mail for cohowinery.com.
- The SMTP connector that connects administrative group "A" to administrative group "B" does not let anybody from outside your Exchange organization to send e-mail messages across the SMTP connector.
- Replication and public folder cleanup operations may take a long time to complete.
Before a public folder cross-administrative group move operation is complete, The Active Directory Connector service must finish several stages of its cross-administrative group move cleanup process. This means that e-mail message delivery will be affected until the Active Directory Connector service is finished. The time involved for this behavior to complete depends on your environment. Additionally, the time involved for this behavior to complete depends on the replication between your Exchange Server 5.5 sites and the replication from Active Directory to Exchange Server 5.5. For example, distribution list cleanup and the removal of stub objects occurs every 12 hours. To force the removal of stub objects, right-click the connection agreement, and then click Replicate Now.
The cleanup of the stub public folder object and the cleanup of the distribution lists are performed at the same time. In a smaller environment, these clean-up operations might be finished in one cleanup cycle, or 12 hours. However, in a larger environment, this cleanup operation may take two or more cleanup cycles to complete, or about 24 hours. This behavior occurs because of the time that is required to replicate information from Active Directory to Exchange Server 5.5, and because of the time that is required for inter-site replication in Exchange Server 5.5. You can speed this process by forcing replication on each connection agreement.
The Active Directory Connector service has the following new behavior for linked Exchange Server 5.5 objects and Active directory objects during a cross-administrative group move operation:- The original, or stub Exchange Server 5.5 object and the corresponding Active Directory object are unlinked during a cross-site move operation. The pfMigrate tool puts a new, different msExchADCGlobalNames value on both of these objects by using the NM_MOVED_CROSS_SITE flag in the msExchADCGlobalNames attribute. The Active Directory Connector service contains logic to prevent this service from matching these two objects.
Note This enables the stub object to be removed from Exchange Server 5.5 at the end of the cleanup cycle without also removing the corresponding Active Directory object. - The Active Directory Connector service must suppress replication of the stub Exchange Server 5.5 object to Active Directory. Because the msExchADCGlobalNames value is removed, and then restamped with a different value, duplicate objects would be created in Active Directory if the Active Directory Connector service did not suppress replication. The pfMigrate tool stamps ADCDoNotReplicate as an X.500 proxy address on the public folder. This indicates that the object should not be replicated to Active Directory.
You cannot use the cross-site bit to prevent replication because intersite replication does not occur for the msExchADCGlobalNames attribute. In this scenario, if a connection agreement replicated changes from a site that is not the local site, the change to the msExchADCGlobalNames value would not be detected. Therefore, the deletions and updates would be replicated. - The Active Directory Connector service must clean up distribution lists. The original Exchange Server 5.5 public folder object must be removed from all the distribution lists. Additionally, the newly-moved public folder object must be added to those Exchange Server 5.5 distribution lists from Active Directory. Active Directory has the correct distribution list membership of the public folder because the distribution list membership is based on a distinguished name (DN) that does not change during the cross-administrative group move of a public folder. The Active Directory Connector service looks up group membership and DN links by using the msExchADCGlobalNames address when it replicates information to Exchange Server 5.5. The Active Directory Connector service can update the Exchange Server 5.5 distribution lists by forcing replication of the Active Directory group. However, a problem might occur because of replication latency between the Exchange Server 5.5 sites. Therefore, when a distribution list is updated in a site, it might not reflect the new public folder object and instead might only point to the original stub public folder object. Because of this, the Active Directory Connector service has a special behavior to perform a DN link lookup to enable linking back to the original object if the new object cannot be found in the Exchange Server 5.5 directory.
If the original Exchange Server 5.5 public folder was removed, and was not left as a stub public folder until after the distribution list cleanup process, the public folder would be removed from distribution lists. This is the same behavior that would occur if those distribution lists replicate to Active Directory and remove the user from their distribution list memberships. However, because the stub public folder is kept, a process is required to clean up these distribution lists so that the newly-moved public folder object is added to the distribution list membership across all the Exchange Server 5.5 sites. Additionally, this process must remove the stub public folder object so that it is eventually removed from all the Exchange Server 5.5 sites.
To do this, the pfMigrate tool accesses all the distribution lists that the moved public folder belongs to in Active Directory. After this behavior occurs, Active Directory replicates the correct distribution list membership back to Exchange Server 5.5. The replicatedObjectVersion attribute is then updated in Active Directory. However, for situations other than where a distribution list is in the destination site, the Active Directory Connector service can automatically force replication of all distribution lists that the public folder belongs to. In this scenario, the Active Directory Connector service searches for objects with a proxy address of X500:ADCDeleteWhenUnlinked. The pfMigrate tool stamps this address on all public folders that are moved to a new administrative group that the pfMigrate tool looks up distribution list membership for. If the distribution group is in the local site, the Active Directory Connector service accesses the group in Active Directory that has the newly-moved public folder as a member. This action forces replication to Exchange Server 5.5. This action is added to the phase that the Active Directory Connector service performs for directory cleanup to resolve unresolved DN links. - The Active Directory Connector service must remove stub objects in the original Exchange Server 5.5 site. The Active Directory Connector service uses the proxy value X500:ADCDeleteWhenUnlinked to indicate that an object should be removed when the MemberOf attribute of that object is empty. When the MemberOf attribute is empty, this object does not belong to any distribution groups. This new behavior is added to the phase that the Active Directory Connector service performs for directory cleanup to resolve unresolved DN links.
Note If deletions are disabled for a particular connection agreement, the stub object is not automatically removed. Instead, this stub object remains and must be manually removed. In this scenario, the X500:ADCDeleteWhenUnlinked proxy address is removed when you manually remove the stub object.
- The original, or stub Exchange Server 5.5 object and the corresponding Active Directory object are unlinked during a cross-site move operation. The pfMigrate tool puts a new, different msExchADCGlobalNames value on both of these objects by using the NM_MOVED_CROSS_SITE flag in the msExchADCGlobalNames attribute. The Active Directory Connector service contains logic to prevent this service from matching these two objects.
- You cannot run the DS/IS consistency adjuster together with the rehome option until the public folder move operation is finished. Generally, we recommend that you do not run this command. However, after a public folder cross-site move operation, do not run the DS/IS consistency adjuster with the synchronized with the directory and reset the home server value option until all directory replication has finished.
If you run DS/IS after public folders have been moved between sites but before directory replication has finished, DS/IS could rehome your public folders to a site other than the destination that is specified by the pfMigrate tool.
REFERENCES
For more information about the Site Consolidation feature in Exchange Server 2003 Service Pack 1, click the following article number to view the article in the Microsoft Knowledge Base:
843104 Overview of the Site Consolidation feature in Exchange Server 2003 Service Pack 1
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
822895 Overview of the Public Folder Migration tool
For more information about how to troubleshoot Active Directory Connector issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:
253841 Troubleshooting Active Directory Connector replication issues
259396 How to set diagnostic logging for the Active Directory Connector
821828 How to troubleshoot issues with the Active Directory Connector Tools that are included with Exchange Server Deployment Tools and ADC Tools
For more information about how to troubleshoot public folder replication, click the following article number to view the article in the Microsoft Knowledge Base:
842273 How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003
Unmerged attributes are discussed in the Understanding and Deploying Exchange 2000 Active Directory Connector white paper. To download this white paper, visit the following Microsoft Web site:
Keywords: kbexchtechbulletin kbhowtomaster kbinfo KB843107
