Issues to know about during site consolidation to an Exchange Server 2003 Service Pack 1-based site

Site consolidation is the process of consolidating remote sites into one large, central site or into several large sites. After a central site has been deployed and clients have begun to run Outlook 2003, the administrator can start to consolidate content from remote sites. Site consolidation will consolidate the main content, the public folders, the mailboxes, and the directory objects. Site consolidation also consolidates services such as the Offline Address Book or foreign connectors to the central site. This article outlines the known issues that may occur during site consolidation. This article also explains what may cause the issues. This article describes workarounds and resolutions. The information is provided to help you understand the issues that may occur. Additionally, the information is provided to help you complete site consolidation.

Install Exchange Server 2003 Service Pack 1 Active Directory Connector

The Active Directory Connector (ADC) in Microsoft Exchange Server 2003 Service Pack 1 is a prerequisite for site consolidation. The Exchange System Manager graphical user interface (GUI) in Exchange Server 2003 Service Pack 1 does not allow cross-site moves to occur until all ADCs in the forest have been upgraded to Exchange Server 2003 Service Pack 1.

Update Exchange Server 5.5 Directory Replication Connector schedule (optional)

During cross-site moves, many directory changes may occur. We recommend that the administrator consider the Exchange Server 5.5 Directory Replication Connector schedule between the remote site and the central site where objects will be moved. To make sure that the replication of changes flow quickly from the central site back to the remote site that is being consolidated, the administrator may want to do the following:

• Make sure that the Exchange Server 5.5 replication connector is set directly between the remote site and the central site.
• Make sure that the same server in the central site is used by the replication connector and the replication bridgehead that the ADC is configured to replicate the Active Directory directory service changes from.
• Make sure that the Exchange Server 5.5 replication schedule is set to Always or to short intervals.

These changes are optional, but they are highly recommended. If directory replication or ADC replication is delayed, the automated cleanup process after cross-site moves may take longer.

ADC behavior

ADC behavior before the move

Before a cross-administrative-group move of a public folder is completed, the ADC completes several stages of cross-administrative-group move cleanup behavior. Message delivery will be affected until the ADC cross-administrative-group move cleanup is completed.

The time to complete the ADC cleanup behavior depends on your environment, on the replication between your Exchange Server 5.5 sites, and on replication from Active Directory to Exchange Server 5.5.

For example, the cleanup of the distribution lists and the deletion of the stub object run every 12 hours. The cleanup of the distribution lists and the deletion of the stub object are completed at the same time. In smaller environments, these may be completed in one cleanup cycle or in 12 hours. In larger environments, these may take two or more cleanup cycles, and they may take closer to 24 hours to complete. Cleanup of distribution lists and deletion of the stub object may take longer in a larger environment because of the following:

• The time to replicate from Active Directory to Exchange Server 5.5
• Inter-site replication in Exchange Server 5.5.

To cleanup faster, right-click the connection agreement and then click Replicate Now. However, the speed is still limited by the following:

• The time to replicate from Active Directory to Exchange Server 5.5.
• Inter-site replication in Exchange Server 5.5.

ADC behavior for linked Exchange Server 5.5 and Active Directory objects during a cross-administrative group move

The stub Exchange Server 5.5 object and the Active Directory object are unlinked during a cross-site move. The Public Folder Rehome Tool (PFMigrate) uses the new NM_MOVED_CROSS_SITE flag in the ADC Global names to assign a different ADC Global names value to both the objects. The ADC does not link these two objects together. Therefore, the stub object can be deleted at the end of the cleanup without deleting the Active Directory object.

The ADC suppresses replication of the stub Exchange Server 5.5 object back to the Active Directory because the ADC GlobalNames are removed and re-stamped with a different value. If the ADC did not suppress replication, the public folder directory object would be replicated back to the Active Directory, and the result would be duplicate objects. Additionally, if the ADCGlobalNames has not replicated to all the domain controllers, the user may be linked back to the Active Directory object. PFMigrate stamps ADCDoNotReplicate as an X.500 proxy address on the public folder. The ADCDoNotReplicate stamp tells the ADC not to replicate this object back to Active Directory. The cross-site bit cannot be used to stop this behavior because the ADC GlobalNames does not replicate inter site. Therefore, the connection agreements that replicate changes that are sourced from a non-local site would not see the cross-site bit, and would still replicate deletions and updates.

ADC Cleanup behavior

Updating Distribution Groups

In Exchange Server 5.5, the old Exchange Server 5.5 public folder object must be removed from the distribution list, and the moved public folder must be updated in the distribution list from Active Directory.

Domain objects are one of the most basic objects in Active Directory. All other objects are subordinate to domain objects. The distinguished name (DN) of a domain object is made up of the domain components (dc) of the domain's DNS name. For example, the microsoft.com domain's object has a DN of dc=microsoft,dc=com. The objectclass that is used for this object is domainDNS and the objectcategory is DomainDNS.

Because the distribution list membership is based on DN and the membership does not change during the cross-administrative group move of a public folder, Active Directory has the correct membership of the public folder. ADC uses the ADCGlobalNames command to look up group membership and DN links when it replicates to Exchange Server 5.5. ADC can update the Exchange Server 5.5 Distribution Lists by forcing replication of the Active Directory group. However, there may be latency between Exchange Server 5.5 sites. Therefore, when the distribution list is updated in a site, it may not have the new object and may only have knowledge of the stub public folder object. To work around this issue, the ADC completes DN link lookups to allow linking back to old objects if the new object cannot be found when the Exchange Server 5.5 directory is searched.

If the old Exchange Server 5.5 public folder were deleted and were not left as a stub public folder until after distribution list cleanup, the public folder would be removed from their distribution lists and the public folder would lose its distribution list membership. This might occur if the distribution lists replicated back to Active Directory and removed the user from their distribution lists. However, because the stub public folder is kept, there must be a process that cleans up these distribution lists so that the newly moved public folder object is added to its distribution lists across Exchange Server 5.5 sites, and so that eventually the stub public folder object can be removed. This behavior may occur in one of the following two ways:

• The PFMigrate process touches all distribution lists that the moved public folder belongs to in Active Directory. Therefore, Active Directory will replicate the correct membership back to Exchange Server 5.5. The replicated ObjectVersion attribute is updated in Active Directory.
• If the distribution lists are not in the target site, the ADC can automatically force replication of all distribution lists that the public folder belongs to. PFMigrate stamps all cross-administrative-group moved public folders with the X500:ADCDeleteWhenUnlinked proxy value and looks up distribution list membership. ADC searches for objects with a proxy address of X500:ADCDeleteWhenUnlinked to force replication. If the distribution group is in the local site, it will touch the group in Active Directory that has the correct membership with the new public folder in the new site to force replication to Exchange Server 5.5. This behavior was added to the phase that ADC has for directory cleanup to resolve unresolved DN links. This behavior runs every 12 hours.

Removing stub objects in the original Exchange Server 5.5 site

The X500:ADCDeleteWhenUnlinked proxy value is stamped on an object by the PFMigrate process to indicate that the object should be deleted when its MemberOf attribute is empty. This means that the object does not belong to any distribution groups because of the updated distribution list behavior that is discussed earlier. This was also added to the phase that the ADC has for directory cleanup to resolve unresolved DN links.

Outlook Web Access and Outlook read/Unread status

When a public folder is moved to a different server during cross-site moves of public folders, the read and unread status of messages in the public folder is lost. This behavior occurs because the read and unread status is not replicated between servers. Therefore, when a user uses Outlook Web Access, or when Outlook accesses a public folder that has been moved cross-site, all messages will appear as unread. This behavior also occurs when you move public folder replicas within the site. This behavior is not specific to cross-site moves.

Access to a public folder that has been moved cross-site

The following behavior may occur:

• Access to a moved public folder may be denied temporarily.
• You may not be redirected to the new home of the public folder.
• Not all the content may be in the new public folder.

This behavior may occur for one of the following two reasons:

• If the replica list is not updated on the user�s server that accesses the cross-site moved public folder, the user is directed to the old replica until the replica list is updated. If the old replica is deleted, the user will not receive access to the public folder. The replica list is expected to be updated within five minutes of the cross-site move. However, if the replica list cannot be replicated before the public folder replica is deleted, users will not have access to the public folder until the replica list is updated.
• The user may connect to the new site to access their public folder before all the content is replicated to the new site.

Public folder affinity

Access to public folders may not complete if public folder affinity is not set to the new site. This behavior occurs because affinity must be configured for the new �home� site of the public folder before the public folder cross-site move. This behavior also occurs when you move public folder replicas and is not specific to cross-site moves.

Public folder affinity is the ability of a client program to view a server on another site and to access a public folder. This is done instead of replicating that folder to the local site. Public folder affinity is typically used if a high-bandwidth connection exists.

Note Public folder affinity is not required if the guidance to provide replicas in both source and target sites during the mailbox move steps are followed. Affinity will be required if public folders are moved in total either before or after mailbox moves.

Known issues: behavior after cross-site public folder moves

Effects on Exchange Server 5.5 users and on Exchange Server 2003 users when e-mail messages are sent to public folders

Message delivery issues may occur when users send e-mail messages to a public folder during a cross-administrative group move and while the ADC is cleaning up the Exchange Server 5.5 directory objects.

Note During the cross-site move, users may receive a non-delivery report (NDR) that contains the following error:

Inbox rules

Rules that move messages to and from public folders that are based on folder ID (FID) will not work after public folders have been moved across administrative groups. You may receive a message that is similar to the following:

Moved public folders in the Global Address List

Public folders that are moved across administrative groups may disappear from the Global Address List in Exchange Server 5.5. This behavior may occur if the original Exchange Server 5.5 object in the old site is hidden before the new Exchange Server 5.5 object is replicated to the new site from Active Directory. Cross-administrative moved public folders are not affected in Active Directory, the Exchange 2000 Server Global Address List, or the Exchange Server 2003 Global Address List.

Journaling

Journaling will not work if a public folder that is used for Exchange Server 5.5 or Exchange 2000 Server Journaling is moved cross-administrative groups. This issue occurs because the LegacyExchangeDN attribute is changed.

Note Journaling to a public folder in Exchange 2000 and Exchange Server 2003 is not supported, and may cause both functionality and performance issues in your Exchange environment. When you reconfigure journaling after the cross-site move, change your journaling to target a mailbox instead of a public folder.

Organizational forms

Organizational forms are not moved cross-site by the PFMigrate script. Organizational forms are part of the system folders, and administrators must manually update the public folder replica list for this and other system folders.

Third-party programs based on public folders

Third-party programs that are based on a public folder and the LegacyExchangeDN attribute of that public folder may not work after a public folder is moved cross-site.

Proxy addresses

Public folders will retain their original proxy addresses from their old site. Additionally, public folders will not gain new proxy addresses from being moved cross-administrative group, even if the recipient policy is based on Administrative Group membership.

The Recipient Update Service will not stamp updated proxies if the public folder already has proxies of that type. To receive a new proxy address for a recipient policy that would now apply to the user based on the new administrative group membership, click Apply now on the recipient policy, and then rebuild the Recipient Update Service. We recommend that you do not do this unless it is required because this may affect the performance of your network.

Although proxy addresses are not updated, e-mail messages flow will not be affected. However, if your system is performing some very specific restriction checking, you may experience an issue if the addresses are not updated. For example, consider the following scenario:

• AG1 accepts e-mail messages for domain1.com.
• AG2 accepts e-mail messages for domain2.com.
• The connector that connects the two administrative groups does not allow anyone from outside the organization to send e-mail messages across it.
• Therefore, the e-mail messages would generate an NDR. The e-mail messages will not be sent across the connector.

Running the Directory Service/Information Store consistency adjuster �rehome� option

After a cross-site move of a public folder, it is best that you do not run the Directory Service/Information Store (DS/IS) consistency adjuster with the Synchronized with the directory and reset the home server value feature turned on until all directory replication has completed. We recommend that you never run the DS/IS consistency adjuster unless it is required. You must wait until public folder cross-site moves are complete before running the DS/IS consistency adjuster.
If you run the DS/IS consistency adjuster shortly after cross-site moves of public folders, it may rehome your public folders to a site other than the target site specified by PFMigrate. This behavior may occur if the following conditions are true:

• You run PFMigrate to add public folder replicas for all public folders in a site to a target server in a new site.
• You run PFMigrate to delete all public folder replicas from all servers in the source site.
• An administrator runs the DS/IS consistency adjuster before homed attributes have replicated back from Active Directory to the Exchange Server 5.5 directory.

However, after Active Directory replicates with Exchange Server 5.5, there is no risk in running the DS/IS consistency adjuster.

Troubleshooting behavior after cross administrative group mailbox moves

Effects on Exchange Server 5.5 users and on Exchange Server 2003 users

There are a number of message delivery issues during a cross-administrative group move and while the ADC is cleaning up the Exchange Server 5.5 directory objects. To prepare for this behavior, it is best that you fully understand the potential issues.

Mail flow issues

For a short time after the mailbox is moved, messages can end up queued for servers that are in a different site as if the servers are in the local site. This is because the Message Transfer Agent (MTA) does not understand how a user can move across sites. Therefore, the MTA makes some incorrect assumptions after the PR_IN_TRANSIT block is released.

Attempts to deliver the messages are made over remote stored procedures (RPC). These attempts fail if only an X400 connector connects the sites and if they do not share the same security context (the same service account). You may also receive error messages that are similar to the following on the Exchange 5.5 server:

Event Type: Warning
Event Source: MSExchangeMTA
Event Category: Interface
Event ID: 9318
User: N/A
Computer: Exchange5.5ServerName
Description: An RPC communications error occurred. Unable to bind over RPC. Locality Table (LTAB) index: 6, NT/MTA error code: 1753. Comms error 1753, Bind error 0, Remote Server Name ExchangeServerName [MAIN BASE 1 500 %10] (14)

The workaround for this problem is to temporarily create a Site Connector between the sites. This allows for a direct RPC connection to be made between the servers in question. This connection allows for mail to be delivered. After the cross-site mailbox move has completed and the MTA has correctly identified the correct routing for the user, you will not experience this problem.

Inbox rules

If you have any client or server side Inbox rules that are based on a user and their Exchange LegacyExchangeDN, the rules will be broken when you move users' cross-administrative groups because the LegacyExchangeDN of a user changes. However, Inbox rules do not break if the user resides on an Exchange Server 2003 Service Pack 1 or later-based server. Inbox rules work in Exchange Server 2003 Service Pack 1 after a cross-administrative group move because changes to the mailbox store allow rules to work even when the LegacyExchangeDN of a user changes. Instead of relying on the LegacyExchangeDN attribute, the additional X.500 proxy-address that was added during the cross-administrative group move can be used during rule processing on Exchange 2003 Service Pack 1 servers.

If the user is not homed on Exchange Server 2003 Service Pack 1, their Inbox rules that are based on a cross-administrative group moved person must be recreated.

Moved users in the Global Address List

Users who are moved cross-administrative group may disappear from the Global Address List in Exchange Server 5.5 for a short time while the original Exchange Server 5.5 object in the old site is hidden and before the new Exchange Server 5.5 object has been replicated to the new site from Active Directory. Cross-administrative group moved users are unaffected in Active Directory, Exchange 2000 Server, and the Exchange Server 2003 Global Address List.

Proxy addresses

Users will retain their original proxy addresses from their old site. However, users will not gain new proxy addresses from being moved cross-administrative group, even if the recipient policy is based on Administrative Group membership.

The Recipient Update Service will not stamp updated proxies if the user already has proxies of that type. To receive a new proxy address for a recipient policy that would now apply to the user based on the new administrative group membership, click Apply now on the recipient policy, and then rebuild the Recipient Update Service. We recommend that you do not do this unless it is required because this may affect the performance of your network.

Although proxy addresses are not updated, e-mail messages flow will not be affected. However, if your system is performing some very specific restriction checking, you may experience an issue if the addresses are not updated. For example, consider the following scenario:

• AG1 accepts e-mail messages for domain1.com.
• AG2 accepts e-mail messages for domain2.com.
• The connector connecting the two administrative groups does not allow anyone from outside the organization to send e-mail across it.
• Therefore, the e-mail message generates an NDR. And, the e-mail message will not be sent across the connector.

Outlook Web Access logon process

In a front-end/back-end implementation, users can access their mailboxes through Outlook Web Access (OWA) by entering either an explicit logon or an implicit logon. The URL for an explicit logon specifies the server and mailbox that the user wants to access and takes the form: http://servername/exchange/username/, where servername is the name of either the OWA front-end or back-end server, and username is the name of the user's Microsoft Windows account. When a user uses an explicit logon to logon to Outlook Web Access (OWA), the logon may not work. This issue occurs because when a user is moved cross-administrative group, the HTTP virtual directory that the user uses for Outlook Web Access (OWA) changes. The HTTP virtual directory that the user uses for Outlook Web Access (OWA) changes because the user's Exchange mailbox back-end server changes. The logon error will occur if the SMTP address on the new HTTP virtual directory is not an SMTP address that the user has.

Note The default Exchange Outlook Web Access virtual directories are all hard coded to use the default recipient policy and the SMTP address in that policy. You can only use different recipient policies that have different SMTP addresses if you create a new virtual directory.

This issue is likely to occur in either of the following two scenarios:

• Scenario One: If the source site is a pure Exchange Server 5.5 site where each site has a different SMTP address, and the current mailbox has an SMTP address in Exchange Server 5.5 that does not match the default Exchange virtual directory SMTP address on the Exchange Server 2003 Service Pack 1 server. When the user is moved from Exchange Server 5.5 to Exchange Server 2003, when the user tries to use an explicit logon with Outlook Web Access to logon to the Exchange Server 2003 Service Pack 1 server, they cannot logon.
• Scenario Two: In a mixed or pure Exchange 2000 Server/Exchange Server 2003 environment, if the user is currently using a dedicated virtual directory that is created by an administrator, and is not the default virtual directory, for Outlook Web Access. The dedicated virtual directory uses an SMTP address from a recipient policy that also supplies SMTP addresses that are used by the mailboxes in the Exchange organization. This means that the SMTP addresses match. When the user is moved to the new site, they are moved to a new Exchange mailbox server that is set up to use the default Exchange Outlook Web Access virtual directory. This default Exchange virtual directory uses the default recipient policy, and has a different SMTP address that the user does not have. Therefore, when the user is moved from Exchange Server 5.5 to Exchange Server 2003, when the user tries to use an explicit logon in Outlook Web Access to logon to the Exchange Server 2003 Service Pack 1 server, they cannot logon.

To work around the issues in Scenario One and in Scenario Two, use one of the following workarounds:

• Create a dedicated virtual directory in the new site for the new mailbox server where the user is moved. Point the new dedicated virtual directory to a recipient policy that has the SMTP address that the user has.
• In a mixed sites or pure Exchange Server 2000 scenario, add the SMTP address from the default recipient policy to the recipient policy that applies to the moved user. After the Recipient Update Service has been updated, the user will have an additional SMTP proxy that now matches the default virtual directory.
• Manually add the correct SMTP address to the moved user

Exchange Server 2003 Service Pack 1 includes a fix that makes it possible to use the SMTP address in implicit logons or explicit logons to work around this issue. Outlook Web Access will always work in the following scenarios when you connect to an Exchange Server 2003 Service Pack 1-based server:

• Implicit logon
  For example, type the URL for OWA access in the following format:
  http://Server/exchange
• Explicit logon using the user principal name (UPN) or SMTP address
  For example, type the URL for OWA access in the following format:
  http://server/exchange/user@Domain_Name.com

When you try to use an explicit logon using the user's alias, and the user does not have the SMTP address of the HTTP virtual directory, the logon will not be completed. For example, if you type the URL for OWA access in the following format: http://Server/exchange/User, you will not access the Exchange server mailbox. This issue occurs whenever an explicit logon using the alias of a user is used for OWA, and is not specific to cross-administrative group scenarios.

Free/Busy information and resource mailboxes

Free and busy information must be re-published after a cross-site mailbox move. For user mailboxes, this will occur 15 minutes after the user uses Outlook to logon to the Exchange server and the user performs a calendar action. For example, if the user approves, removes, or creates a meeting request, the calendar free and busy information is republished 15 minutes later.

The owner of a resource mailbox, for example a meeting room, must open the mailbox and perform a calendar action to re-publish the free and busy information.

This behavior occurs because there will not be a free/busy message for the user�s new LegacyExchangeDN attribute in the target site, but Outlook will not publish an update until a calendar change is made, and the Outlook �local� free/busy cache is dirtied. This behavior also occurs if you run through the GUIDGen process to reset site system folders.

Or, the UpdateFB tool can be used to automate this Free/Busy republishing process.

For additional information about the UpdateFB tool, click the following article number to view the article in the Microsoft Knowledge Base:

Offline Address Book

Offline Address Book download and remote sites

When a user runs Outlook 2003 in cached mode at remote sites with Exchange Server 2003 or an earlier version, they must make sure that they have sufficient bandwidth to support a full download of the Offline Address Book for all clients at that remote site.

Remote sites across slow links

When mailboxes that use Outlook 2003 in cached mode are moved from a remote Exchange Server 5.5 server to a central Exchange 2003 SP1 server, either across sites or not, a full Offline Address Book must be downloaded. Additionally, when there is a significant change to the directory, or when a new Admin Group is added or removed, a full Offline Address Book download will be generated for cached mode users. Therefore, remote sites must make sure that there is sufficient bandwidth to support a full Offline Address Book for all clients at the remote site.

Additional information about full Offline Address Book downloads

Typically, Outlook clients will only see an Offline Address Book diff download. This is a small subset of the full Offline Address Book download that contains only changes instead of the full global address list. However, there are cases where Outlook clients will have to download the full Offline Address Book. If the directory has a significant number of changes, for example, lots of new accounts, name changes, and more, or a new Exchange Admin Group is added or removed, all clients that are in cached mode will be updated with a full Offline Address Book. Additionally, clients that are moved from Exchange Server 5.5 to a new Exchange Server 2003 server will also receive a new full Offline Address Book.

For additional information about limiting the effect of full OAB downloads in Exchange Server 2003, click the following article number to view the article in the Microsoft Knowledge Base:

Wait for directory updates

Administrators will have to wait for directory updates to occur before e-mail messages can flow without creating a non-delivery report (NDR).

Known issues: behavior after object rehome

Message Delivery will be affected on Exchange Server 5.5 and Exchange Server 2003 for users mailing Contact and distribution lists

If users send e-mail messages to Contact and distribution lists during a cross-administrative group move, and during the ADC clean up of the Exchange Server 5.5 directory objects, there are a number of message delivery issues that may occur.

Inbox rules

When the distribution list/Group is re-homed during a cross-administrative group move, Inbox rules that process messages based on the DL as sender or receiver will not work for mailboxes that are hosted on Exchange servers that are earlier than Exchange Server 2003 Service Pack 1. These rules must be re-created, or the mailboxes with the rule must be moved to a server that is running Exchange 2003 SP1.

Moved public folders in the Global Address List

When a Contact/distribution list is rehomed, it may disappear from the Global Address List in Exchange Server 5.5 during the time that the original Exchange Server 5.5 object in the old site is hidden, and before the new Exchange Server 5.5 object has been replicated to the new site from Active Directory. Re-homed objects in Active Directory, the Exchange 2000 Server Global Address List, or the Exchange Server 2003 Global Address List are not affected.

Proxy addresses

Objects that are re-homed will retain their original proxy addresses from their old site. However, they will not gain new proxy addresses when moved cross-administrative group, even if the recipient policy is based on Administrative Group membership.

The Recipient Update Service will not stamp updated proxies on the object if the re-homed object already has the same type of proxies. To receive a new proxy address for a recipient policy that would now apply to the object based on the new administrative group membership, click Apply now on the recipient policy, and then rebuild the Recipient Update Service. We recommend that you do not do this unless it is required because this may affect the performance of your network.
Although proxy addresses are not updated, e-mail message flow will not be affected. However, if your system is performing some very specific restriction checking, you may experience an issue if the addresses are not updated. For example, consider the following scenario:

• AG1 accepts e-mail messages for domain1.com.
• AG2 accepts e-mail messages for domain2.com.
• The connector that connects the two administrative groups does not allow anyone outside the organization to send e-mail messages across it.
• Therefore, the e-mail message would generate an NDR. The e-mail message will not be sent across the connector.

X.500 addresses are overwritten by inter-organizational ADC in contacts that are moved cross-site

Consider this scenario. An inter-organizational connection agreement (CA) creates a contact in an organization. The contact represents mailboxes in another organization. If the contact is moved cross-site, the original directory name of the contact from the source site is stamped onto the moved contact in the form of an X.500 address. However, if the mailbox that the contact represents is changed, the change is replicated back to the moved contact object, and the ADC will overwrite the X.500 address.

To work around this issue, use one or more of the following procedures:

• Re-configure the ADC to a new site, and then run the tool losing all X.500 addresses.
• Export the LegacyExchangeDNs from Exchange Server 5.5 before the cross-site move, and then import the LegacyExchangeDNs as X.500 addresses on the Exchange Server 5.5 mailboxes.
• Switch to Exchange Native Mode, and do not move the contacts.

Wait for the ADC to complete

You must wait for Active Directory to Exchange Server 5.5 replication, intra-site replication, and inter-site replication to complete. E-mail message flow and other operations will be affected until the Exchange Server 5.5 directories are synchronized and the ADC has been run to fix the changes.

Run the Directory Service/Information Store consistency adjuster

After a distribution list that is granted access to a public folder is moved cross-site, you must run the patched Directory Service/Information Store (DS/IS) consistency adjuster tool to make sure that the distribution list is still able to access the public folder.

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: