Share via

So what if the "stub" objects never go away?

  • Article

A while back, I wrote a blog post about verifying that you are ready to remove the source site after undergoing the process of SP1 mixed-mode site consolidation. See here for that intro. Since that post, I've run into a few questions about what to do if these validations never pass.

Suppose you keep checking for the stub objects to disappear in the source site by doing a CSV export and looking for the absence of "X500:ADCDeleteWhenUnlinked" proxy addresses. And suppose these addresses keep turning up each time you check. This means that the stub objects are not being cleaned up -- probably for some good reason.

Here's a deeper look at what has to happen to facilite the cleanup of the stub objects in the source site after the object has been moved cross-site. Suppose we've moved a mailbox:
1) After the mailbox data has been moved to the target site, attributes are changed on the mailbox directory object in the 5.5 source directory and in the AD to indicate the move.

5.5 Source object (soon to become the "stub" object) has:
- its proxy addresses removed
- its alias changed to a random GUID value
- HomeMdb and HomeMta changed to the new server location
- Adc-Global-Names flags updated to indicate cross-site move
- two X500 addresses added (X500:ADCDoNotReplicate and X500:ADCDeleteWhenUnlinked)

AD object is also updated (it will be the "authoritative object" during the cross-site move)
- legacyExchangeDN changed to point to the new site (this is what really defines the move to Exchange)
- msExchADCGlobalNames flags updated to indicate cross-site move
- new X500 address (for the old legacyExchangeDN) added to the existing proxy addresses
- HomeMdb, HomeMta, and msExchHomeServer attributes updated to the new server location
- Each DL this mailbox is a member-of is "touched" to ensure it will replicate the membership back to 5.5

2) The ADC will shortly notice that both the 5.5 source-site object and the AD object have changed

3) ADC will try to replicate the changed 5.5 mailbox object from the source site into the AD. This will be prevented by the "X500:ADCDoNotReplicate" proxy address. This is good. Otherwise the ADC would strip off all the proxy addresses, etc (the changes we made to the 5.5 source-site object during the cross-site move).

4) ADC will reverse direction and try to replicate the object from the AD over to 5.5. It will notice that the msExchADCGlobalNames flag indicates a cross-site move for this object and will reject any object match back to the source-site 5.5 object. ADCwill then need to find a new match, and because the legacyExchangeDN now points to the target site, ADC will create a new mailbox directory object in that site.

5) At some point (there are a number of complicated timing issues we'll avoid for this discussion), we'll also replicate the DLs from the AD back to their home site. Remember, we touched these DLs to ensure they would replicate. ADC will bring across the DLs and their respective memberships -- which now includes reference to the removal of the source-site object, and the addition of the target site mailbox object.

6) 5.5 Dirrep will run between the various sites in the 5.5 organization. The new mailbox object in the target site will eventually show up in the read-only naming context of the source site (All 5.5 directories with dirrep configured have full visibility of the whole 5.5 org). The DLs and their updated membership will also make it around the whole 5.5 organization after replication.  

Status check: So, after all this ADC replication and Dirrep we should have a new mailbox directory object in the target site, an updated AD mailbox directory object, and a "stub" object in the source site. We only retain the "stub" object so that we don't mistakenly remove it from its DL memberships. We can't remove this object until we're SURE that all DLs have been updated to replace the "stub" object with the new mailbox object. Once we've updated all of the DL memberships, we're ready to go onto the next step. This is probably the part of the process where most people get stuck -- waiting on dirrep or ADC replication to finish.

7) The ADC runs a process every 12 hours to do miscellaneous cleanup. One of the new additions in the Exchange 2003 SP1 ADC is the addition of a "stub object cleanup". ADC checks every 12 hours (or you can force it to happen immediately with a "replicate now" action on the CA) for objects in the source site which are stamped with X500:ADCDeleteWhenUnlinked proxy address. If any are found, they are inspected to see if they belong to any DLs. If they do not (meaning DLs have all been transitioned off successfully), ADC also checks to see if there is an object in the 5.5 directory that has the X500 address of the stub mailbox object (indicating that the new mailbox object has replicated in over 5.5 dirrep). If the ADC finds another object with the X500 address, deletes the "stub" object since the process has been completed.

That's a bunch of steps, and it really only covers the most simple ordering. All of these steps are asynchronous and loosely coupled, so it's quite possible it might take several cycles to get all of the steps completed in the right order.

Hopefully that all makes sense. Perhaps I'll drill back into some of it in more detail for a future post if there's any interest.

Bonus tip: If you turn off ADC deletions (and you surely haven't done this now, have you? It's generally a bad idea, in my opinion), the "stub" object won't be deleted in step #7. Rather, the X500:ADCDeleteWhenUnlinked proxy address will be removed. This means that you will find lots of hidden "stub" objects in the 5.5 source directory, but they will not show up in the CSV export looking for this proxy address. You will see only the X500:ADCDoNotReplicate proxy remains on these objects. These are safe to delete, as they're only still retained because Deletions are turned off on the CA.

Update May24,2005: An important point I did not emphasize enough in this original posting is the importance of proper ADC connection agreements. Have a look at this later post for a bit more detail on that topic.

Comments

  • Anonymous
    January 01, 2003
    It’s now been about a year since Exchange 2003 SP1 released, and cross-site, mixed-mode mailbox...