I just worked on one of these again today, so time to post about this issue. If you create pure Exchange 2000 or 2003 Administrative Groups, you’ll want to read on to find out how these appear in 5.5 and about an interesting issue if you don’t have your ADC connection agreements set up just right.
First, a background – If you are running in a mixed mode organization (Exchange 5.5 + Exchange 2000 and/or Exchange 2003), you can use Exchange System Manager to create a new Administrative Group, then install new Exchange 2000/2003 servers into that Administrative Group. This is known as a pure Exchange 2000 / 2003 Administrative Group (Referred to hereafter as a “Pure AG”). When you do this, some special magic has to occur to get this new Pure AG to appear in Exchange 5.5 as a new Site. This is a pretty intricate process, but I’ll try to be succinct:
So, this is fine and dandy, but at this point we have a site with no users in it in 5.5. The arbitration process and Config CA replication only handle configuration objects – not objects in the Site naming context such as users, groups, or contacts created in the new Pure AG. In order to get those down into 5.5, we have to get them replicated via the ADC into our only writeable copy of that Pure Site in the 5.5 world – the SRS database that owns that Pure AG.
At this point, you may be tempted to create a one-way CA to replicate the users with mailboxes in the Pure AG down to the SRS, which will then replicate the users all around 5.5 and be done with it. While that may seem to work just fine, there is actually one big problem with using one-way CAs to replicate the Pure AG mailboxes into 5.5. The problem is group membership updates. You will find that if a Pure AG mailbox is added to a DL in 5.5, and that DL is in a different site than the Pure AG mailbox, the user won’t be added to the group in the AD. And conversely, if you add a pure E2K user to a group in the AD, the user may not show up on the group once it replicates to 5.5.
The reason for this is as follows: When the ADC replicates a group from 5.5 to AD (or vise-versa but we’ll talk about this direction), it must resolve each Member of the DL (which is a 5.5 style DN) to a user account in the Active Directory. The way that it does this is by doing an LDAP query in the AD. The query that it does is based on the msExchADCGlobalNames attribute -- this is the attribute used by the ADC to match objects together. So, for instance, if a user on a DL in 5.5 has a DN of “/o=org/ou=site/cn=Recipients/cn=user” then the ADC will do a query against the AD of (msExchADCGlobalNames=EX5: /o=org/ou=site/cn=Recipients/cn=user*). If this query doesn’t return a user, then the ADC assumes there must not be a corresponding user in the AD to match the mailbox, and it sticks the user’s DN into an attribute called unmergedAtts in the AD. Note that this is a binary encoded attribute which contains the Hexadecimal representation of the Unicode characters of the DN. So, it’s not too easy to see what is in that attribute. But, it does this so that if a user later shows up in the AD which has the matching msExchADCGlobalNames value, the ADC can later clean up those unmerged attributes and put the member on the DL in the AD.
You may still be wondering why all of this matters for Pure AGs and DL membership. So, here’s the kicker: If you use a one-way CA from AD to the SRS to create the Pure AG mailboxes, the users in the AD will never get msExchADCGlobalNames stamped on them. This is because msExchADCGlobalNames is only stamped on an object when that object is a TARGET of ADC replication. If you are only replicating one-way from AD to the SRS, that means the objects will never replicate from the SRS back to the AD, and the AD user will never be the target of ADC replication, and it will never get msExchADCGlobalNames stamped on it. Add to this that 5.5 inter-site replication does not replicate ADC Global Names between sites. So, when the group in Site A replicates down from AD to 5.5 with a Pure AG user as a member, the 5.5 directory in Site A will not have msExchADCGlobalNames in it for the Pure AG user since that user is from a remote site. So, in order to resolve the DL membership, the ADC must search in the AD for a user with msExchADCGlobalNames in order to find the 5.5 DN of that user, so they can be added to the DL. In this case the search is like (msExchADCGlobalNames=NT5:ABC123…*) where the “ABC123…” is the objectGUID of the AD user. If this query fails, the user is not added to the group in Exchange 5.5 and instead unmergedAtts is set on the 5.5 DL.
And what is the fix? The fix is to change your one-way CA to a two-way CA, and to add the Pure AG an export container of the From Exchange tab of the CA, then force a full replication of the CA. Now, since the Pure AG is an export container, the ADC will replicate all those mailboxes from the SRS back to the AD and stamp msExchADCGlobalNames on the AD objects. Then, when unmerged Attribute cleanup happens on the other CAs (every 12 hours or if you restart the ADC service) it will start taking users out of unmergedAtts and putting them in the membership of the group.
Whew! So, if you are having a problem with group membership replication, check the group with missing users to see if unmergedAtts is set on it. If so, check the users that are missing from the group to make sure msExchADCGlobalNames is set on them in the AD and in 5.5 (using raw admin, the attribute is called ADC-Global-Names). If it is not set, then check out your CAs to make sure they are all two-way and configured properly, and try making a change to the object in the remote directory. Once you get msExchADCGlobalNames populated, the user will appear on the DL after some time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.