At some point after you've moved all the public folders, mailboxes, distribution lists, and custom recipients from your source site to the target site, you'll be ready to do the validation to ensure you're ready to remove the servers and site. When you've confirmed that all your data and directory objects are finished migrating to the target site, you're ready to start tearing down the servers in the source site, and eventually the source site itself.
One roadblock you're going to run into if the source site you're consolidating was the first Exchange 200x site in your organization is that the MAPI Public Folder hierarchy (or at least the AD representation of it -- remember, the actual hierarchy information is stored in and replicated to every public folder store associated with this tree) is created in the first admin group. Before you can remove the site, you'll need to move the PF hierarchy object in the AD to a different site.
This process is really pretty straightforward, but it's not particularly intuitive so here are the steps:
It really is that simple. This process is also covered in KB.252105, although it's a fairly spartan KB, so you may not find it unless your search is right on target.
Plus, it's becoming something of a tradition... here are a few new KBs this week for SP1 Site Consolidation:
KB.867623 - Throttling full offline Address Book downloads to limit the effect on a LAN in Exchange Server 2003 - This KB covers a new Exchange 2003 SP1 registry value you can set to control bandwidth usage for OAB downloads. As covered in KB.839826, there are a number of circumstances (particularly during and after the Ste Condolidation process) where full OAB will need to be downloaded to all clients in the org. When this happens, it can put a tremendous load on the PF servers that host a replica of the OAB. Setting the KB.867623 registry value will allow better control over the bandwidth used by this process, to ensure that it is not saturated by OAB downloads.
KB.293386 - HTTP 401 or 404 error messages when you access OWA implicitly or explicitly - When you move mailboxes cross site with the new SP1 functionality, they retain only their original proxy (email) addresses. Even though the mailbox will now fall under a new recipient policy, the RUS won't stamp new proxy addresses on the mailbox unless the recipient policy is set to “apply now“. This means that it's possible that OWA access to the mailbox will be affected as described in this article -- email addresses on the mailbox won't match the domain name defined on the HTTP protocol virtual server and logons will fail.