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.
- Tool marks the 5.5 custom recipient in Site1 as “moved“ and hides it from the GAL
- Tool makes some changes on the AD Contact that is matched to the (now moved) 5.5 custom recipient
- Move is now considered “complete“ from the tool’s standpoint…
- ADC runs and creates a new custom recipient in Site2 (*this is new ADC behaviour for cross-site moves!)
- Directory replication runs and brings the (new) custom recipient from Site2 back over into Site1 — now both Site1 and Site2 have a representation of the moved custom recipient.
- The presence of the “new“ custom recipient in Site1 will allow DL membership to be updated to contain the “new“ Site2 custom recipient instead of the original Site1 custom recipient.
- The ADC checks on a periodic basis if the original Site1 custom recipient is a member of any DLs. If it’s not, the object is deleted in Site1. This “stub“ object in Site1 is only retained until DL membership has been transitioned to the new Site2 custom recipient…
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:
- In 5.5 Admin program, do a directory export to CSV of the GAL. Be sure to include “hidden objects“ and “subcontainers“
- Open this CSV file and search for any objects with an email address of “X500:ADCDeleteWhenUnlinked“.
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.