If you're in charge of designing or upgrading your messaging environment, you've probably skimmed through countless articles and books about Active Directory (AD) to learn how it will ultimately affect your Exchange 2000 Server design. You've probably also read about the latest trends and ideas about how to design your AD domain, site, and infrastructure topology with performance and security in mind. ("Related Reading," page 11, provides resources for background information.) Armed with this knowledge, you should be able to tackle the most challenging deployments and migrations with ease. Migrating your distribution lists (DLs) from Exchange Server 5.5 to Exchange 2000 is no exception—if you know what to watch out for. Let's look at groups in Exchange 5.5 and Exchange 2000, then examine how DLs fit in the new AD group structure.
Exchange 5.5 DLs
In Exchange 5.5, a DL is a group of users in the Exchange directory. Most people use DLs to send email to many people at once. When you send a message to a DL, the Message Transfer Agent (MTA) on the originating server (or an expansion server, if specified) enumerates the recipients, and Exchange 5.5 delivers the message to the appropriate mailboxes. If necessary, the MTA fans out the DL to make sure that multiple copies of the same message aren't sent over the same connections. Exchange 5.5 stores DLs in the directory and replicates them throughout the organization.
When you make any changes to the DL membership (including adding or deleting one member), Exchange must replicate the entire DL membership throughout the Exchange organization. An Exchange 5.5 DL owner (or the Exchange administrator for a site) can change the membership of a DL only if the user object exists in the same site in which the owner created the DL.
You can also use DLs to secure access within your public-folder hierarchy. Many companies secure (and simplify the management of) their public folders by granting DLs the appropriate rights to a particular folder, then simply adding users to these DLs. This technique is similar to adding Windows NT 4.0 users to a group, then granting group rights to a resource.
Exchange 2000 Distribution Groups
Because Exchange 2000 relies on AD for its directory information, you must look to AD for DLs as well. AD uses groups to attain similar functionality. In Windows 2000, groups are either distribution groups or security groups, and these groups can be universal, global, or domain local in scope. You can use a distribution group only for email distribution, not for security. A security group is a security principal; therefore, you can use it for both email distribution and security (i.e., to assign security settings to files or public folders).
The group's scope controls how Exchange replicates objects throughout the forest. In universal groups, the group object and its members are replicated forestwide. In global groups, the group object is replicated forestwide but the membership remains local to the domain. In domain local groups, the group object and its membership stay within the domain in which they're created. Tables 1 and 2 summarize the types and scope of groups.
You can use either security groups or distribution groups as DLs, but you need to decide whether you want those groups to be universal groups or global groups. Many AD designers have pointed out pitfalls of universal groups. One disadvantage is that the entire universal group membership (not just changes in individual members) replicates to every Global Catalog (GC) in a forest. Therefore, if your membership changes often, you could be causing a lot of unnecessary replication, even to domains that rarely use the groups. As a result, you might decide that global groups are a better approach. However, because of the way Exchange chooses and uses GCs in your environment, global groups might not be a good choice.
How Exchange Chooses a GC
Exchange 2000 uses an internal process called DSAccess to determine the working domain controller (DC), the working GC, and the configuration DC. Exchange 2000 uses these categories at various times to access and store directory information. (Kieran McCorry, "MAPI Client Directory Access in Exchange 2000," August 2001, InstantDoc ID 21458, explains this process in detail.) Working GCs play a role in DLs. Exchange uses GCs because of their role in keeping information pertaining to universal groups. (A GC holds a copy of all objects in the forest, a complete copy of all objects from a domain, plus a subset of attributes from all other domains.) Exchange 2000 uses the working GC list that DSAccess provides to choose a GC to enumerate DLs. Exchange 2000 needs to look up each noncached recipient address (or other DL) directly from AD. As part of the System Attendant service, the DSGetDCName API creates this list of up to 10 GCs by querying AD for a list of GCs in that AD site. After the API creates the list, Exchange 2000 uses the GCs in the list in a round-robin fashion whenever it needs to.
Single vs. Multiple Domains
In a single-AD domain environment, all GCs hold the same information as DCs. Because no other domains exist, AD requires no other domain naming contexts (NCs) or partitions. DL expansion in a single AD domain has few or no side effects.
With multiple domains, however, the process becomes more complex; many other factors determine correct delivery of messages addressed to a DL. If your organization has multiple domains (specifically, multiple domains in a single Win2K site), the entire DS Access process, expansion servers, and AD site boundaries become important. You must understand exactly how your Exchange 2000 server uses the working GC list to locate an available GC to fulfill certain requests. Most multiple-domain organizations have multiple GCs from different domains in at least one site that houses an Exchange 2000 server.
Sending a Message to a Universal Group
To illustrate the consequences and ramifications of an AD, Exchange 2000, and ADC design, let's look at what happens when you send a message to a universal group, then compare that process with what happens when you send to a global group. First, let's set up the environment.
Assume that you have a two-domain AD infrastructure within a single site. (You could have several other domains, but a two-domain topology will demonstrate the design ramifications sufficiently.) The root domain is xyz .com; abc.xyz.com is a subdomain in the xyz.com tree. Within this site is one pure DC (i.e., a DC that isn't also a GC) and one DC/GC combination from each domain. All user and group objects as well as the Exchange 2000 server, ex01.abc.xyz.com, are in the abc.xyz.com subdomain. Figure 1 illustrates this topology. The xyz.com domain holds only the Schema and Enterprise Admin accounts. (The Web sidebar "Using an Empty Root Domain in AD Forests," at http:// www.exchangeadmin.com, InstantDoc ID 23521 explains why you isolate these accounts.) In this example, you have four DCs—two for each domain. Let's assume that these DCs are the only DCs in the forest. Because most companies will use AD security groups to set ACLs on public folders, I discuss this topic in the context of security groups. Distribution groups follow similar processes.
When you use Outlook to send a message to a DL (e.g., a DL called UniversalGroup, which is a Universal Security Group—USG), the Exchange 2000 server receives the message and grabs the next GC in the working GC list. The server attempts to enumerate the recipients first against its Directory Service (DS) cache, then against the GC. The DSADiag utility (available from http://www.exinternals.com) that's run from an Exchange 2000 server in the abc.xyz.com domain produces the output that Figure 2 shows.
In the list that Figure 2 shows, gc1 .abc.xyz.com appears to be unreachable (because it has an X in the DOWN column). Therefore, Exchange queries gc1.xyz.com in an attempt to enumerate the DL. Gc1.xyz.com parses the Member attribute of the USG group object UniversalGroup and returns the corresponding membership entries. Although gc1.xyz.com is technically not in the same domain as gc1.abc .xyz.com, the membership of a universal group is replicated to all GCs in the forest. Gc1.xyz.com passes the membership entries back to the Exchange 2000 server, and the internal message-routing process takes over to send the message successfully. The Web sidebar "Processing the DL" (http://www.exchangeadmin.com, InstantDoc ID 23522) explains what happens during DL expansion.
DSAccess uses the Lightweight Directory Access Protocol (LDAP) to query listed DCs and GCs about every 5 minutes. DSAccess also performs full network redetection
- when the Kerberos ticket expires (the default duration is 10 hours)
- when you change the configuration (e.g., add a new DC or GC)
- if all the DCs or GCs in the list are down
However, if a DC or a GC goes down, DSAccess won't redetect your network settings if other DCs or GCs are in the DSAccess list. You can force a scan at any time by typing
at the command line.
Now, let's say the working GC list in the example changes (i.e., gc1.abc.xyz .com comes back online) and DSADiag produces the output that Figure 3 shows. This output reveals that all GCs in the forest are now reachable. When another user sends a message to the same DL, the Exchange 2000 server chooses gc1.abc.xyz.com again; because this GC contains the correct information, the DL is enumerated and processed, and the message is sent successfully.
Sending a Message to a Global Group
By contrast, let's look at what happens when you send a message to a global group instead of to a universal group. Figure 4 shows the DSADiag output that shows the network configuration.
Using Outlook, a user sends a message to the DL GlobalGroup. The Exchange 2000 server receives the message and queries gc1.xyz.com to enumerate the DL. Gc1.xyz.com once again looks up the Member attribute for the group and sends the results back to Exchange. However, instead of sending Exchange all the results, gc1 .xyz.com responds with the Member attribute list of the GlobalGroup object, which in this scenario is empty. Exchange then sends to null (nobody), and the process is complete. The sending user doesn't receive a nondelivery report (NDR) and calls you to find out what happened. You troubleshoot by sending a test message to GlobalGroup, and everything seems in order: The message successfully reaches all appropriate members as expected.
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.
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."