So you've done Exchange 2003 SP1 “Site Consolidation” and you think you're ready to remove your Exchange 5.5 site. All the Public Folders, Mailboxes, DLs, and Custom Recipients have been moved to the central site. All the foreign connectors are relocated. You've gone through the Deployment tools and all the Docs (see: http://blogs.msdn.com/evand/archive/2004/06/04/148349.aspx for the links to these docs)
Are you ready to remove the 5.5 site?
Well, the answer is... it depends. Every customer environment is different, and I certainly won't pretend I know your environment well enough to answer that. But, there are a few “validation” steps you can take to help ensure at the very least that all of the Public Folders, Mailboxes, DLs and Custom Recipients have actually finished moving.
Why does it even matter that they've “finished moving“? Well, if you remove the site too early... any object that hasn't finished moving will be removed from all of its DL memberships!
Evan's Tip #1 for doing cross site moves: Always do a CSV export of your DL memberships before beginning. Just in case.
Quick Digression: When you move Public Folders, Mailboxes, DLs or Custom Recipients using the new Cross-site technology, they don't move immediately. The process is a bit asynchronous. At a very high level, it goes a bit like this for whatever object is being moved:
Scenario: Moving an object (say, a custom recipient) from Site1 to Site2.
Ok, so maybe that wasn't as quick a digression as I had planned. Anyways, good info. I expect I'll post more detail later on in preparation of a planned Site Consolidation webcast in July.
So now we'll assume you've run through the Exchange Deployment tools and you're at the step that tells you to “remove the remote 5.5 site”. This is the consolidation part. Your whole goal is to get rid of this site, right? But are you ready?
Well, there are a few things we can check to make sure that the process of moving all of these objects has completed. Let's list them:
PUBLIC FOLDERS - Two parts to this one: Content and Directory Object.
Public folder content can be confirmed replicated when the “instance” in the 5.5 information store in the source site (Site1 in our example above) has been removed. When you remove the replica from the server in Site1, it will linger until all of the data is in sync at the server in Site2 and only then will be deleted from the server in Site1.
Public folder directory object - in Exchange mixed mode, all public folders are mail enabled which means that all public folders have a directory object to hold its email addresses. This object will be “rehomed” into the central site (Site2 in our example above) when the replica is removed from the server in Site1 by the updated PFMigrate script included with the updated Exchange Deployment tools. If the PF is a member of any DLs, these memberships have to transition to the newly created PF directory object in Site2 before the PF directory object in Site1 will be removed. The best way to check if the transition is complete is to search out these PF directory objects in Site1... if they still exist, the transition hasn't completed. You can find these PF directory objects in Site1 in several ways, but here's my recommendation:
If you find any such objects, there are still “stub” objects in Site1 waiting for their DL membership to transition. Be sure ADC replication and 5.5 Directory replication are working.
MAILBOXES - again we have both content and directory objects to consider
Mailbox Content - Check the mailbox resources in the Private Information store of the servers in Site1 to make sure there are no mailboxes which have not yet moved. This is a bit less complicated than the PF content steps above, as we don't do mailbox replication.
Mailbox Directory Object - The check for this one is identical to the PF directory object check above: CSV Export, etc.
DISTRIBUTION LISTS and CONTACTS - Have only directory objects, so no checks in the store for content are necessary. Further, the check for the directory object transition is identical to the PF directory object check described above. Remember, DLs can be nested, so even DLs may be member of another DL and may require transition time.
Once you've validated all content and directory objects have been completely moved to the Central site (Site2) and all of the DL memberships transitioned, it's quite possible you're ready to remove the Remote site (Site1)! You'll know for sure whether there remains anything else to consider based on the planning you did prior to beginning the moves.
Thanks Evan for all the useful info, however there are a few other items with regard to mixed mode cross admin group/site object moves:
Before performing any cross-site/admin group moves, check your ADC CA configuration. For example, in a large multi-site, multi-domain (single Forest) environment, it is possible during co-existence to have a single two-way ADC users CA per-site/domain that is primary for both exchange and AD (in other words, the sites recipients container is mapped to a container in the associated domain and vice-versa). This works fine in a traditional configuration whereby Exchange 5.5 objects (recipients, etc.) are being managed by the ADC within a single site and associated domain.
The problem that occurs is that during a cross-site move to a central site, the new appropriate ADC two-way "primary from windows" CA for the AD domain (that hosts the AD object) to the central site may not have been configured and the original CA for AD to local site replication is not reconfigured to be "primary from exchange" only. As a result the new object instance is never replicated to the central site. If these actions are not taken then the object cleanup (and "un-hiding") of the object never happens in the original site and everything comes grinding to a halt.
Now this may seem like an obvious step to miss, but in a large Exchange mixed mode environment with dozens (or more) of CA's this is an easy step to miss. Additionally, none of the exdeploy or cross-site tools check this prerequisite; they simply see that the AD and 5.5 are in sync and therefore allow cross-site moves to occur. There is also no error handling anywhere to indicate a problem or replication failure.
So before performing any cross-site moves, it is critical to double check your ADC CA topology and verify that you have the appropriate CA's from the Active Directory to the central site to allow the ADC to replicate the new instance of the object.
Thanks for the blogging...
Directory Services and Messaging
hey there - good info thanks. I am a bit confused about moving directory objects between sites (DLs, CRs). Why is this needed? The ADC has already replicated the objects to AD...
Also, I posted this in alother blog but never got a response:
a question about site consolidation: I have a couple 5.5 single-server sites in my org. Is it best to use the cross-site move method described in your webcast, or can I simply install the 2003 server in the single-server site, move all objects, then once in native mode move the server to the appropriate Admin Group?
also, about SP1, can you now move 2003 mailboxes across Admin Groups in mixed mode?