Share via

Moving public folder hierarchy for site consolidation

  • Article

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:

  1. In the site where you want the AD hierarchy objects to end up, right click in ESM on the Site object.
  2. From the context menu, select “New“ and then “Public Folders Container“.
  3. Next, drag and drop the “Public Folders“ MAPI hierarchy object from the Folders container in the source site to the newly created Folders container in the other site.

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.

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://www.keyongtech.com/1057049-migrating-coexisting-first-exchange-administrative

  • Anonymous
    July 16, 2004
    Thanks for the tip on how to move a TLH to another site/ag. It was often a wanted feature in many migrations I did with customers...

    Christian

  • Anonymous
    July 21, 2004
    Is the PF hierarchy stored in each public folder store, or on each server that has a PF store (and if so, then where is it actually kept)? The "Send Hierarchy" command doesn't let you select individual stores to use as the source, or target, of forced hierarchy updates.

  • Anonymous
    July 21, 2004
    Paul -

    Yes, the PF hierarchy is actually stored in (and replicated to) each store that is associated with a particular tree. Most customers only use the MAPI tree, so most customers only have a single hierarchy to worry about.

    The reason the "Send Hierarchy" command doesn't allow you to select stores is that by virtue of right-clicking on a particular PF hierarchy/tree in ESM to select the "Send Hierarchy" option, you've already selected a particular store. Only one PF store on each server can be associated with a particular hierarchy/tree (try adding a second PF store on a server and joining it to the MAPI hierarchy, for instance!), so we can make the assumption that if you've selected a particular hierarchy and a particular source server, you will have only one qualifying PF store on that source server.

    The confusion here may be about the terminology. I suppose the thing we're actually moving with these steps is actually the "PF Tree" rather than the "PF Hierarchy", because you're 100% correct -- the PF hierarchy is stored in the store rather than the AD. I just called it the hierarchy because that's what everyone calls it and I wanted searches for this topic to be useful. :)

    Evan

  • Anonymous
    July 21, 2004
    That explanation makes perfect sense, Evan-- thanks for clearing that up!