So what happened? For one thing, the working GC list changed to the configuration that Figure 5 shows. You were able to send successfully because gc1.xyz.com is a GC in the xyz.com root domain and it's in the SITE1 site. Remember, DSAccess chooses any GCs within its Win2K site (up to 10 GCs), including gc1.xyz.com and gc1.abc.xyz .com in this example. Gc1.xyz.com knows of the GlobalGroup object, but the corresponding Member attribute is null because only universal groups replicate the Member attribute. Although GlobalGroup is a valid distribution group, it contains no members —at least according to the xyz.com domain. Exchange got exactly what it asked for: the contents of the Member attribute for that particular group. So, every time Exchange grabbed a GC, it could have grabbed a GC in a different domain than that of the GlobalGroup object to which it was sending. For the first request, Exchange chose gc1.xyz.com to fulfill the enumeration request; for the second request, Exchange chose gc1.abc.xyz.com. Exchange's choice of different GCs explains why the first attempt to send was unsuccessful and the second attempt worked fine.
Exchange does its best to make the process work by putting local domain GCs at the top of the list, but obviously this process isn't foolproof, nor does it account for specified expansion servers in other Win2K sites and possibly other AD domains. You could set the expansion server to an Exchange 2000 server that resides in the domain that houses the GlobalGroup DL, but even then, DSAccess on that Exchange 2000 server might choose a GC in another domain. Obviously, the more domain-specific DCs and GCs you have in each Win2K site, the better your odds of successful enumeration. However, a little forethought (i.e., using universal groups) can save the unnecessary added expense of placing additional GCs in other sites. (Kieran McCorry, "MAPI Client Directory Access in Exchange 2000," explains some of DSAccess's intricacies. Also, note that Exchange 2000 Service Pack 2—SP2—replaces DSADiag with a GUI. For more information, see Tony Redmond's Windows & .NET Magazine article, "Exchange 2000 Service Pack 2," http://www.winnetmag.com, InstantDoc ID 23527.)
I recommend that you consider using universal groups for your DLs whenever you can because of the confusion that global groups can cause. If you think that the extra overhead of replicating universal group membership throughout your organization isn't worth it, remember that you were already replicating the entire membership in Exchange 5.5—you've just transferred the replication to AD.
Migrating DLs from Exchange 5.5
With this background about universal and global groups, let's look at how to migrate your Exchange 5.5 DLs to Exchange 2000. The Active Directory Connector (ADC) is key to the migration. This seemingly simple tool performs many tasks with little intervention. However, you must understand what the ADC can and can't do. After you create the connection agreement (CA) and configure it correctly, the ADC automatically and transparently migrates DLs and their membership from Exchange 5.5 to AD. When migrating a DL from Exchange 5.5, the ADC converts the DL to a Universal Distribution Group (UDG) in the target AD domain.
If the Store detects that a distribution group is being used as a security principal (e.g., on public folders), the Store process converts those groups to USGs. This conversion might occur if you replicate an Exchange 5.5 public folder to Exchange 2000 and the public folder contains a UDG (an old DL that you migrated with an ADC) that's being used temporarily for permissions. Or it might happen if you upgrade an Exchange 5.5 public folder Store in which DLs are used for permissions or if you try to add a UDG to an ACL on a public folder.
Migrating a DL works fine if you're migrating to a native-mode AD domain, but a mixed-mode AD domain doesn't have USGs. As a result, the conversion process will fail, and you'll quickly realize that you don't have the appropriate access to any public folders that were secured through DLs.
If you have a mixed-mode domain, you can get around the security-group problem by creating a separate native-mode domain specifically for migrating DLs. This technique works because universal groups are still domain-specific objects (i.e., they're created and exist in only one domain). They appear to span the forest because their membership is flagged for AD to replicate it to all other GCs in the forest. So by creating this new DL domain—and making it a native-mode domain—the Store can convert UDGs to USGs when it needs to without a problem.
The better you understand the ADC, the easier your migration will be. The articles in "Related Reading" provide good background about the ADC.
Important Tools
As you can see from this article, the ADC and DSAccess are two extremely important concepts to understand, for both designing a new Exchange 2000 topology and migrating Exchange 5.5 objects. I suggest familiarizing yourself with these concepts by reading the articles and papers in "Related Reading."