Partilhar via

Cross-site moves: The importance of proper ADC Connection Agreements

  • Artigo

It’s now been about a year since Exchange 2003 SP1 released, and cross-site, mixed-mode mailbox moves were introduced. In that time, I think folks have really started to get the hang of how it works and what needs to be in place to ensure successful moves.

That said, there’s one topic that I’ve seen popping up more and more frequently over the past few months (perhaps it’s just because some of the other common questions are starting to recede in volume as more and more documentation hits the web).

“Why won’t my stub objects go away?” (or its close cousin — “why do I keep getting NDRs long after I moved the mailbox?”)

Ok, so you might say “hey Evan, didn’t you already cover that in this post”

Yup. That post covers the under-the-hood details of the move, and will probably help you understand where the process is breaking down. Have a look at it if you haven’t yet.

But, I’ve had it brought to my attention that there’s one area of this post that I might not have emphasized enough: You Have To Have The Proper Connection Agreements In Place!

Almost every step in the cross-site, mixed-mode mailbox move process relys on the proper ADC connection agreements being there. The Exchange Deployment tools (download here) guide you through the whole process, and actually have you run the “ADCTools” to create and confirm the proper CAs several times during the process.

This is very important. If you don’t have the proper ADC Connection Agreements in place, you will run into very weird “blocking” problems where objects don’t get created/deleted/updated, etc.

One specific case I’ve had brought to my attention is the scenario described in KB.888032. This is the case where you have a “pure” Exchange 2003 site (ie - a site with only E2k3 in it, no 5.5… no SRS). In this scenario, another site has an SRS that “owns” this pure E2k3 site. Various updates for the “5.5 view” of this pure E2k3 site have to be handled by this particular “owning” SRS. But since it’s a “pure E2k3” site, it’s really quite easy to forget that even this site needs to have a CA too (and that it needs to point to this SRS in another site.. an altogether confusing situation for most people!)

So, in summary, if you’re running into problems with the “transition” part of your cross-site, mixed-mode mailbox moves, I suggest you start with the following:
  1) Have a look through my original detailed process post and see where you’re getting stuck.
  2) Make sure you’ve run the ADCTools and/or confirmed your CAs are correct
  3) Have a look through KB.888032 to make sure it’s not the issue you’re hitting

Comments

  • Anonymous
    May 24, 2005
    Evan,

    I have read your posts regarding cross site move by using E2K3 SP1.

    We are in mixed-mode Exchange 5.5 to Exchange 2003 migration which includes site consolidation (cross site mailbox move). We find an issue related to mailbox delegated permission.

    For example, MailboxA and MailboxB were both in same Exchange 5.5 site (source). And mailboxB has delegated access to mailbox folders of mailboxA. Then mailboxB was cross site moved to Exchange 2003 via ESM (E2K3 SP1).

    Logon mailboxA we could still see mailboxB on folder permission list which pointed to "Stub" hidden object of mailboxB left in source site. When this "Stub" object got deleted, name of mailboxB on permission entry list changed to its original DN name. We do wait (overnight) for more than 12hrs for ADC and DIRsync settled down.

    Basically issue is that cross site moved mailbox lost its delegated access to some resources mailboxes still in source site.

    I have not tested the situation of mailboxA cross moved as well.

    As you indicated your post I can clearly see proxy address of X500:ADCDeleteWhenUnlinked dropped from "stub" hidden object and all DL membeship replicated and retain without problem for mailboxB.

    I wonder if the cross site move tool covers situation of retaining mailbox delegate permissions. In my understanding those ACLs on are IS on DS of Exch55. ADC may not be able to handle. If not, we may have RCA issue here.

    Hopefully you may cross similar situation and had good advices.

    Mnay thanks,
    Tony Du
    tony.du@gsjbw.com

  • Anonymous
    May 24, 2005
    Tony -

    Cross-site mixed-mode mailbox moves definitely do take mailbox delegation into account.

    Exchange 2003 Sp1 servers are smart enough to take into account the idea that a mailbox might have been moved across 5.5 site boundaries, and that an X500 address on this moved mailbox might also be a suitable replacement as a directory-identifier for the "obj-dist-name" (ie - LegDN) attribute.

    So, the short answer to your question is: Always move the manager (ie - the person who has the permissions defined in their mailbox) either before or at the same time as the delegate (the person who has been grated permissions in the manager's mailbox). And once this move is complete, be sure that the mailbox stays on an E2k3 Sp1 server.

    This will ensure that the permissions are always evaluated by an E2k3 Sp1 server. Once the delegate has also been moved, the permissions will still properly resolve, and you'll never have a "broken" state.

    Even if you've already moved the delegate, all hope is not lost. Simply move the manager to an E2k3 SP1 server, and the delegate permissions should resolve themselves at that point.

    Hope it helps!
    Evan
  • Anonymous
    May 27, 2005
    I used cross site moved twice and it works fine.
    I think the wizards are the best practice, even if you need to check after (CA for example).
    The major problem is replication or network link, so same troobleshoot as a normal move mailbox.

    Last point, THANKS EVAN, your blogs helps me a lot especially because I tried it when the service pack was launched on a 20,000 international mbx structure.

    Philippe