Lesson 2: The Impact of Exchange 2000 Server on the Active Directory Service | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Active Directory of Windows 2000 is a special network service that maintains a database of directory objects that allow you to control literally everything in your Windows 2000 domain environment. There are directory objects for servers, printers, workstations, users, system services, and other resources. Exchange 2000 Server extends this collection with numerous additional objects for its own configuration information. Servers and clients access Active Directory in many situations, such as when logging on to the network, connecting to a mailbox, or accessing server-based address lists. In short, your messaging environment requires a dependable Active Directory infrastructure that satisfies the business requirements of your organization as well as the technical requirements of Exchange 2000 Server.

This lesson discusses how Exchange 2000 Server integrates with Active Directory. You will read about the various directory partitions that hold Exchange 2000-related objects and how domain controllers and GC servers replicate this information across the network. The explanations from this lesson will help you design an Active Directory environment that best suits the needs of your Exchange 2000 organization.

After this lesson, you will be able to

Describe which portions of the Active Directory database hold what type of Exchange 2000-related information and how this information is replicated across your organization
Analyze existing Active Directory structures and identify requirements for local authentication servers and global catalogs to optimally support Exchange 2000 Server and its messaging clients
Decide where to place domain controllers and GC servers in the network in given scenarios

Estimated time to complete this lesson: 60 minutes

Understanding Active Directory Dependencies

Using Windows 2000 Server, the definition of a domain controller is easy to comprehend—it is a computer that runs Active Directory. One or more domain controllers may exist in a Windows 2000 domain. The domain, in turn, defines the security boundary for all network resources it contains.

The Active Directory Service

To promote an ordinary Windows 2000 server to a domain controller, launch the Active Directory Installation Wizard (DCPROMO.EXE) and then make your choices on the various wizard pages that appear. It takes about 18 steps and up to an hour to complete the installation. For Active Directory to function properly, your DNS servers must support SRV records, as Microsoft DNS Server does, which can be installed automatically in the Active Directory Installation Wizard.

If you check the list of installed services on a Windows 2000 domain controller (via the Services utility from the Administrative Tools program group), you may be confused not to find a service called Active Directory. Nevertheless, the directory service is there. For historic reasons, it is called Net Logon instead of Active Directory. Microsoft Windows NT domain controllers used a Net Logon service to maintain their domain information in the Registry, and that is where this name comes from. The executable file is LSASS.EXE, which stands for Local Security Authority Security System, also a name from the previous versions of Windows NT. You can stop and restart the Net Logon service at any time, which may be a good idea, for instance, if you want to refresh the SRV records of your domain controller in DNS. If your DNS servers support dynamic updates, domain controllers will register themselves automatically, saving you the manual configuration.

Note

A stopped Net Logon service prevents users and processes from logging on to the system. You should not terminate this service any longer than necessary, at most for a few seconds.

The Active Directory Database

To maintain its database, Active Directory takes advantage of the Extensible Storage Engine (ESE), which is a very reliable, tried, and proven transaction-oriented database technology. All versions of Exchange Server rely on this technology as well. You can specify the path to the Active Directory database files in the Database And Log Locations wizard screen of the Active Directory Installation Wizard. If you have accepted the default settings, the database location is the \Winnt\Ntds directory.

Internally, the Active Directory database contains three different sections, called naming contexts (NCs); perhaps a better name would be directory partitions. These are the domain, configuration, and schema NCs, and they are separated because they replicate differently across the Active Directory environment, as covered in more detail later. The ADSI Edit utility from the Microsoft Windows 2000 Server Resource Kit (also available on the Windows 2000 Server product CD) is a very handy tool to examine the various NCs of Active Directory (Figure 3.8).

Caution

ADSI Edit allows you to modify objects in Active Directory without checking the validity of the configuration settings, similar to a Registry editor for the Windows 2000 Registry. Do not use ADSI Edit to change directory information directly unless you have no alternative. Editing directory objects directly can seriously damage Active Directory and may require you to reinstall the entire forest (that is, all domain controllers in your network).

Figure 3.8 - The naming contexts of Active Directory

The Schema Naming Context

The schema NC holds hundreds of objects that describe the various object classes and attributes that Active Directory knows about. Classes define the various instances of directory objects (organizational unit, user, computer, and so on) and specify the relationships between them. When you create a user account, for instance, you are creating an object (or instance) of the user object class. Directory objects are sets of attributes (user name, logon name, alias, password, and so on), and attributes are governed by syntaxes (single value, multiple value, data type, and so on). Exchange 2000 adds a large number of new object classes to the schema and new attributes to existing classes. Likewise, existing attributes are modified to be included in GC replication. You can find detailed information about the Active Directory schema in the Windows 2000 Server Resource Kit.

If you want to take a glance at the schema NC on an Exchange 2000 server, use ADSI Edit or the Active Directory Schema console (Figure 3.9). You may have to enable the Active Directory Schema console explicitly by running the REGSVR32 SCHMMGMT.DLL command. After that, you can add the snap-in to a custom Microsoft Management Console (MMC) and check the existing classes and attribute definitions. Exchange 2000-specific classes and attributes begin with msExch or ms-Exch.

Note

Exchange 2000 Server adds 155 object classes and 818 attribute descriptions to the Active Directory schema and marks 270 attributes for replication to the GC.

Figure 3.9 - Exchange 2000-specific information in the schema NC

The Configuration Naming Context

Exchange 2000 Server stores the vast majority of its configuration data in the configuration NC. (Only a minimum amount of information is kept in the server’s local Registry database to allow the Exchange 2000 services to start and initialize.) To get a full picture of the configuration NC, use ADSI Edit or the Active Directory Sites and Services console. When using the latter, do not forget to activate the Show Services Node option from the View menu; otherwise, you will not be able to find the configuration information for Exchange 2000 Server, which is under the Services node. A sample Exchange 2000 organization, as displayed by both ADSI Edit and the Active Directory Site and Services console, is shown in Figure 3.10.

Figure 3.10 uses ADSI Edit and Active Directory Sites and Services for illustration purposes only. The primary tool for working with Exchange 2000 configuration information is actually the Exchange System Manager snap-in. Yet, Exchange System Manager displays only that information that is underneath the directory object for your Exchange 2000 organization. In Figure 3.10, this is the Adventure Works container object. The parent containers, called Microsoft Exchange, Services, and Configuration are not visible, which is unfortunate, because it can confuse the administrator when granting and revoking permissions to the Exchange 2000 organization, as you will read in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

Figure 3.10 - Exchange 2000 information in the configuration NC

The Domain Naming Context

Exchange System Manager is not the right tool if you want to manage user accounts and mailbox settings because this information is not in the configuration NC. It is in the domain NC instead, which contains all organizational units (OUs), servers, printers, and user account objects for the domain. To access the domain NC, the administrator will use the Active Directory Users and Computers console, as shown in Figure 3.11.

Figure 3.11 - Information from the domain NC

Exchange 2000 Server stores all its recipient information in the directory objects of the domain NC, which is the basis for single seat administration of user accounts and mailbox settings. However, the original snap-in of Windows 2000 is unable to deal with Exchange 2000 information, such as mailbox settings, because the required property pages and wizards are missing. To manage user accounts and their mailboxes together, use the extended version of Active Directory Users and Computers, which comes with Exchange 2000 as part of the management utilities. It is possible to install the management utilities directly on the server and on a workstation running Windows 2000 Professional.

Replicating Active Directory Information Within Domains

Everything is simple as long as you have only one domain controller in your domain. All domain information resides on this one computer and does not need to be synchronized with other copies elsewhere. However, a single domain controller does not provide any fault tolerance. If your central domain controller were to go down (or if you stopped the Net Logon service), your entire domain would become unavailable. To avoid this situation, implement at least two domain controllers in every domain, even if this means that you have to install Exchange 2000 Server on a domain controller.

It is not difficult to add a new domain controller to a domain. Run the Active Directory Installation Wizard, and on the Domain Controller Type wizard screen, select the Additional Domain Controller For An Existing Domain option. On the Additional Domain Controller wizard screen make sure you select the correct domain to join. The Knowledge Consistency Checker (KCC), which is an internal component of Active Directory, dynamically configures the replication links between the domain controllers for you. Your domain controllers will discover each other automatically and then start replicating their database contents.

The Schema Master Domain Controller

Windows 2000 allows you to change the directory objects in the domain NC and configuration NC on any domain controller. This is a great feature because it allows you to configure your user accounts, groups, and any Exchange 2000-related configuration objects literally from any DC in the domain. Remote administration could not be any more flexible than that. Active Directory automatically replicates your changes across the entire domain. In a LAN environment, this takes no longer than five minutes.

In contrast to the domain and configuration NCs, the schema NC is read-only by default to prevent accidental damage to Active Directory. To add or modify classes and attributes, you have to set a Registry key on a specific domain controller known as the schema master, which controls all schema updates and modifications (DWORD value HKEY_LOCAL_MACHINE\System\Current Control Set\Services\NTDS\Parameters\Schema Update Allowed = 0x1). Only one schema master can exist in the entire forest at any time. It is possible to change the database schema programmatically, as the Exchange 2000 Setup program does during the installation of the first server in the forest. In this case, you don’t need to set the Registry key, but you need to have access to the schema master over the network. Only members of the Schema Admins group can modify the schema.

Note

You can use the Active Directory Schema snap-in to identify and change the schema master in your Active Directory environment. Add this snap-in to a custom MMC tool and open the schema NC as displayed in Figure 3.9, right-click the Active Directory Schema node, and then select Operation Masters to display the Change Schema Master dialog box, where you can examine and change the schema master server. You can also write-enable the schema in this dialog box.

Flexible Single Master Operations

The schema master role is one of five specific flexible single master operations (FSMO) roles in Windows 2000. The other four roles are domain naming master, infrastructure master, relative identifier (RID) master, and primary domain controller (PDC) emulator. The schema and domain naming FSMO roles are forest-wide; the three remaining roles are per domain.

The domain naming master is responsible for controlling changes to the forest-wide domain namespace. In other words, this domain controller controls the addition and removal of domains in your Active Directory environment. Only one domain controller can assume this role. You can change the domain naming master in the Active Directory Domains and Trusts console. Right-click the Active Directory Domains and Trusts root object in the console tree, and then select Operations Master to display the Change Operations Master dialog box.

The infrastructure master is responsible for updating object security identifiers (SIDs) and distinguished names in cross-domain references. This domain controller updates group membership information in its local domain when user account information in another domain changes. For instance, if you rename a user account, the new account name must be incorporated into the group membership list. The infrastructure master in the group’s local domain is responsible for this update. There can only be one infrastructure master per domain. You can change this server in the Active Directory Users and Computers console. Right-click the Active Directory Users and Computers root object in the console tree, and then select Operations Masters to display the Change Operations Master dialog box, where you need to select the Infrastructure tab.

The RID master assists the other domain controllers in the domain in generating unique SIDs for user accounts, security groups, and other resources. A SID consists of two portions: a domain-specific ID that is the same for all SIDs in the domain and a RID that is unique for each resource or user account. The RID master assigns RID pools to the other domain controllers in its domain. You can change the RID master in the Active Directory Users and Computers console. Display the Change Operations Master dialog box as described earlier and then select the RID tab. There can only be one RID master per domain. You will read more about SIDs in Lesson 3.

As you will notice in the Change Operations Master dialog box, there is also a PDC tab to change the PDC emulator server. One PDC emulator exists per domain to support Windows 95, Windows 98, and Windows NT workstations, member servers, and backup domain controllers. The PDC emulator manages password changes for all systems running versions of Windows earlier than Windows 2000 that Windows 2000 domains can support in mixed mode. Even in native mode, however, when previous Windows NT domain controllers are not supported, the PDC emulator still assists Windows 2000 domain controllers in handling password discrepancies. To give an example of such a discrepancy, let’s assume you have changed your password on a computer running Windows 2000 Professional. Any Windows 2000 domain controller can handle this request, but it takes time to replicate the new password to all other domain controllers in your domain. The PDC emulator is the preferred replication partner for password changes, which means that it is informed about the changed password first (preferential replication). Now, if you try to log on to a domain controller, which has not yet received the update, your logon attempt will fail due to an incorrect password. In this case, the domain controller does not deny you access right away, but forwards the authentication request to the PDC emulator for validation. The PDC emulator is also the domain master browser in the domain.

Active Directory Replication Infrastructure

Active Directory can replicate directory information using RPCs over IP or e-mail messages via SMTP. RPCs work best with fast and reliable network connections. E-mail, on the other hand, is an alternative if network connections are unreliable or slow, or if the data transfer generates costs. To identify reliable network connections, configure Windows 2000 sites in the Active Directory Sites and Services console. Sites are identified by means of IP subnets and can contain computers from a single domain or from multiple domains. Multiple Windows 2000 sites may also exist within a single domain. Sites have nothing to do with your domain topology. Your server’s IP address (that is, the IP subnet) determines to which site it belongs.

Sites define the physical structure of your Active Directory environment and determine the communication mechanism used for replication (Figure 3.12). Within sites, Active Directory replication always relies on RPCs, and between sites RPCs or e-mail can be used. Between sites, replication links must be configured manually because domain controllers are not supposed to replicate their data across site boundaries automatically. Domain controllers that perform directory replication with domain controllers in other sites are called replication bridgeheads. The Knowledge Consistency Checker (KCC) designates bridgehead servers in each site automatically, but you can also specify preferred bridgeheads. Replication within a site, on the other hand, is always direct and doesn’t require any manual adjustments. The configuration of sites and site links is covered in detail in the Windows 2000 Server product documentation.

Figure 3.12 - Active Directory replication in a single domain environment with two sites

Replicating Active Directory Information Across Domain Boundaries

It is possible and advantageous to build a single domain environment with multiple sites to host all of your worldwide resources and user accounts, as it can greatly simplify your network administration. However, there are reasons to use multiple-domain environments as well. One possible reason is the migration of an existing, complex Windows NT domain structure to Windows 2000 and Active Directory. You would migrate the master domain first, followed by the other account domains, and then the resource domains, which implicitly leads to a multidomain Active Directory environment. Another reason may be that you want to structure your network administration according to the internal divisions and departments of your organization. For example, a company called Adventure Works, with headquarters in Canada and subsidiaries in the United States, South Africa, and Australia, might find it appropriate to register the Internet domain name adventure-works.com for Canada and the United States, adventure-works.co.za for the facilities in South Africa, and adventure-works.com.au for the Australian subsidiary. To distinguish the Canadian mother company from the subsidiary in the United States, the company might also split adventure-works.com internally into ca.adventure-works.com and us.adventure-works.com. Adventure Works can then use all of these DNS names for their Windows 2000 domains. In Figure 3.13, the domains adventure-works.com, ca.adventure-works.com, and us.adventure-works.com form a domain tree and, because the child domains contain the DNS name of the parent, they also form a continuous namespace. The domains adventure-works.co.za, and adventure-works.com.au do not form a continuous namespace with adventure-works.com because their DNS names are not included in adventure-works.com. These domains are not part of the same tree, yet they are still interrelated because they are part of the same forest.

Figure 3.13 - An Active Directory environment with continuous and disjointed namespaces

The domains ca.adventure-works.com and us.adventure-works.com are child domains of adventure-works.com, which is consequently their parent domain. Together they form a structure known as a domain tree. Adventure-works.co.za and adventure-works.com.au are likewise trees, although they do not have any branches or child domains. Together, this arrangement of domain trees represents an Active Directory forest. Within a particular forest, transitive two-way trust relationships exist between all domains; in other words, all domains trust each other completely.

A particular Active Directory database can only hold information from a single forest, and within this forest, the configuration and schema NCs are always replicated to all domain controllers in every domain, no matter how complex the domain structuring. Because the configuration of your Exchange 2000 organization is part of the configuration NC, it is automatically available in all domains of the forest. This implies that a particular forest cannot span multiple Exchange 2000 organizations, and a particular Exchange 2000 organization cannot span multiple forests. This dependency is a very important design factor.

Global Catalog Servers

It is likewise important to note that Active Directory does not replicate the domain NC to any domain controllers in other domains. It seems that there is no reason to replicate the user accounts because transitive two-way trust relationships make it possible to grant a user from any domain access to resources in all other domains of the forest. However, the fact that the domain NC (the user accounts, distribution groups, contacts, and so on) is not replicated to ordinary domain controllers in other domains has several important consequences for the messaging organization because Exchange 2000 maintains all recipient information in this NC. How can you build a complete address list in a multidomain forest if all user information is kept in the local domains only? Among other things, it wouldn’t be possible to have a consistent global address list.

To overcome this quandary, Active Directory replicates selected information from the domain NCs to specific domain controllers independently of their domain membership. These domain controllers, known as GC servers, can then provide your users with a forest-wide global address list. The GCs are furthermore the only domain controllers that can handle universal groups, which can contain members from any domain in your forest. Due to the overhead of GC replication, however, you should not configure every domain controller as a GC server.

GCs contain the schema, configuration, and domain NCs, as does any other domain controller in the local domain, plus a partial replica of all other domain NCs in the forest. In other words, all domain NCs of your forest are present in the GC, but only with those attributes that are marked for GC replication in the schema definition. Ordinary domain controllers listen on TCP port 389 for incoming Lightweight Directory Access Protocol (LDAP) connections and on TCP port 636 for LDAP connections over Secure Sockets Layer (SSL). GCs listen in addition on TCP port 3268 for GC-specific requests and on port 3269 for GC requests over SSL. GC servers must be registered explicitly through SRV records in DNS.

By default, only the first domain controller in the forest is a GC server, but you can promote other domain controllers to GC servers using the Active Directory Sites and Services console. To do so, right-click the NTDS Settings object under the desired server and click the Properties command (you may have to expand the Sites container in the console tree, then Default-First-Site-Name, and then Servers to find the desired server). In the NTDS Settings Properties dialog box, in the General property page, select the Global Catalog check box. It is a good idea to reboot the server to ensure all interfaces initialize properly. Specifically, the Name Service Provider Interface (NSPI) required to support MAPI-based clients might otherwise cause trouble.

More Info: Domain Controller vs. Global Catalog

To illustrate the differences between a domain controller and a GC server, use Microsoft Outlook Express on your Windows 2000 server to query Active Directory via LDAP. After launching Outlook Express, open the Tools menu, select Accounts, and then, in the Internet Accounts dialog box, select the Directory Service tab. Select the account called Active Directory and click Properties. Select the Advanced tab and verify that the Directory Service (LDAP) port is set to 3268. Click OK and then click Close to close the Internet Accounts dialog box. On the Outlook Express toolbar, click Addresses. In the Address Book – Main Identity window, click Find People, and then, from the Find People list box, select Active Directory. You will be able to look up user and group information from the entire forest. Close all Address Book windows, and then, from the Tools menu, click Accounts again, double-click the Active Directory account entry, and then, in the Advanced tab, change the Directory Service (LDAP) port to 389. Repeat the address book lookups and verify that only information from the local domain is returned.

Remember, in single-domain environments, domain controllers and GCs return the same set of information because all user and group accounts are in the local domain NC, which implies that every domain controller can be a GC without increasing the replication overhead. In multidomain environments, GC replication increases the replication overhead.

Global Catalogs, MAPI Clients, and Servers

MAPI-based clients and server-based components, such as messaging connectors, expect to find a directory service on each Exchange server to look up mailbox and recipient information via the NSPI. However, there is no Exchange directory in Exchange 2000, and, consequently, MAPI clients have to be redirected to a GC server. This is the responsibility of the Directory Store proxy (DSProxy), which is an internal module of the Microsoft Exchange System Attendant (SA) service. DSProxy forwards directory lookups of MAPI-based clients straight to a GC, keeps a reference of each client connection, and ensures that the response from the GC is passed back to the correct client. The client is unaware of the proxy process.

Note

DSProxy works over TCP/IP, SPX/IPX, and AppleTalk.

The forwarding of client connections to another computer in the network (the GC) uses resources on the Exchange 2000 server and slows down address book lookups. It would be smarter to instruct the MAPI clients to contact a GC directly. Smart MAPI clients, such as Outlook 2000, have the ability to query GCs without proxying—they only need to learn which one to use. DSProxy, especially its Directory Service Referral (RFR) Interface, can divert Outlook 2000 (and later) clients to a GC. Outlook 2000 contacts the SA, obtains the name of a GC, and then uses this server for all subsequent directory access.

Exchange 2000 servers can locate the nearest GC automatically. It is also possible to set explicit Registry keys to specify servers manually. You can set a REG_SZ value called NSPI Target Server to the name of the GC you want DSProxy to use for legacy MAPI clients, and a REG_SZ parameter called RFR Target Server to identify a specific GC for directory referrals of smart MAPI clients. You could also set a DWORD value called No RFR Service to 0x1 to disable the referral process and proxy all MAPI clients, including Outlook 2000. However, keep in mind that setting these Registry parameters disables the automatic GC discovery process and therefore reduce the system’s fault tolerance. If a manually specified GC is unavailable, clients will not be able to contact another GC.

The Registry key for all three parameters is:

 HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet  \Services  \MSExchangeSA  \Parameters

Note

MAPI-based clients communicate with the GC in many situations, such as for client logon, displaying the address book, resolving recipient information, and so forth.

More Info: Outlook 2000 and Directory Referrals

Outlook stores the referral received from the server in its MAPI profile and does not need to issue further queries to the SA. Only if you launch Outlook 2000 and your client cannot contact the registered GC is the SA asked for another GC referral. You can examine the information in the Registry editor. Open the following key:

 HKEY_CURRENT_USER \Software  \Microsoft  \Windows NT  \CurrentVersion  \Windows Messaging Subsystem  \Profiles

Right-click on the Profiles node, select Find, and then, in the Find dialog box, under Find What, type 001e6602 , and then click OK. The string value 001e6602 refers to the GC referral. Unfortunately, editing MAPI profiles is easier said than done. However, knowledge of this value may be useful in a troubleshooting situation if you need to modify the client’s GC information manually.

Documenting the Existing Active Directory Environment

Every Active Directory environment consists of two independent topologies that establish the logical and the physical infrastructure. Correspondingly, you should include both in your project documentation. The logical structure outlines the domain topology and provides information about where in the Active Directory forest Exchange 2000 can be installed. The physical structure, or the site topology, on the other hand, determines the efficiency of directory replication and the speed of GC access.

When documenting an existing Active Directory environment, include the following information:

The domain topology, which includes the domains and OUs, the domain controllers and FSMO servers, and the trust relationships to domains in foreign Active Directory forests and Windows NT domains
The site topology, which includes information about existing directory replication links, replication bridgeheads, and the location of GC servers
The hardware configuration of GC servers

The Domain Topology

The domain topology of your network has a tremendous influence on the design of your Exchange 2000 organization. As mentioned earlier, your organization cannot span multiple Active Directory forests, for instance. Consequently, you need to know how many forests there are and whether it is possible to migrate them into a single forest environment. It is likewise important to identify the domain of the schema master because this is the domain where you need to extend the schema. You should also include the OU structure of each domain in the documentation because all user, group, and contact objects reside in OUs, and so does the recipient information that Exchange 2000 adds to these objects. It is useful to include one or multiple topology diagrams, as discussed later in greater detail.

When documenting the domain topology of an Active Directory forest, include the following information:

A descriptive name for the Active Directory forest.
The name and domain of the schema master.
The names of the domain trees and domains in the forest, and the names of their main administrators, as well as the domain controllers and the number of users in each domain. You should also indicate whether the domains are in native or mixed mode.
The OUs in each domain that hold user accounts, groups, and contact objects, and the administrators with full control over these OUs.
The trust relationships to domains in foreign Active Directory forests and Windows NT domains.

Tip

You can find a Microsoft Excel workspace with a worksheet to document domain topologies in the \Chapter03\Worksheets directory on the Supplemental Course Materials CD. The filename is ACTIVE_DIRECTORY.XLS.

The Site Topology

The site topology of your forest influences the design of your Exchange 2000 organization because your servers will join a site automatically based on their IP subnet. You need to ensure that your Exchange 2000 servers belong to the correct sites and that GC servers are available in them. As mentioned earlier, Exchange 2000 servers and MAPI-based clients require access to a GC and this access should be over a reliable high-speed connection to minimize delays in client logons and address book lookups. Sites, per definition, identify regions with reliable high-speed network links.

When documenting the site topology of your environment, include the following information:

The name of the Active Directory forest for which you are documenting the site topology
The replication links, their configuration parameters, and the preferred bridgehead servers
The IP subnets of each site
The locations and the names of the GC servers

Tip

The ACTIVE_DIRECTORY.XLS workspace contains a worksheet called Site Topology that you can use as a template to document the sites in your Windows 2000 network.

Global Catalog Servers

GCs are very important resources in any Exchange 2000 organization. You may already have documented the hardware of your GC servers in your network documentation, but it is also a good idea to include it in the Active Directory documentation, just to have it readily available when working on the Active Directory optimization plan.

When documenting the configuration of your GC servers, include the following information:

The configuration of the server hardware, such as the CPU type, amount of memory, network cards, hard disk space, and so forth
The processes that the GCs run in addition to Active Directory, such as Microsoft DNS Server
Which service packs are installed

Tip

The ACTIVE_DIRECTORY.XLS workspace contains a worksheet called Global Catalog Servers, which you can use as a template to document your GCs.

Analyzing and Optimizing an Active Directory Forest

When reviewing your Active Directory environment, the most critical questions revolve around the GC servers in the environment and the directory replication topology. There are other important aspects as well (see Figure B.8 in Appendix B). For instance, you need to limit your Active Directory environment to a single forest because multiple forests require multiple Exchange 2000 organizations.

To be optimally prepared for Exchange 2000 Server, an Active Directory environment should:

Be limited to a single Active Directory forest with at least one domain operating in native mode
Be extended using the Exchange 2000 Setup program in ForestPrep mode
Have GCs in each site
Have more than one domain controller in each domain
Show a well-structured site topology for efficient directory replication

Increasing the Resilience of the Active Directory Environment

It is generally advantageous to provide domain controller redundancy because without a DC, users cannot access Exchange 2000 Server. Hence, if you choose to eliminate single points of failure within your domain, you should have a minimum of two domain controllers; medium and large domains should have no fewer than three. This may require you to install Exchange 2000 Server on a domain controller, although Microsoft does not recommend this configuration. In an environment with multiple servers, you should always give fault tolerance preference over maximum system performance. Bear in mind that Microsoft’s recommendation does not take financial constraints into account.

Note

Domain controller redundancy is not an issue if your network consists of exactly one server running Exchange 2000 Server as part of Microsoft Small Business Server 2000.

Redundancy is likewise important for GC servers. All sites in which you plan to install Exchange 2000 Server should have a minimum of one GC, but to provide sufficient fault tolerance, each site may have two or more. Otherwise, you may end up with the problem illustrated in Figure 3.14. Ideally, Exchange 2000 and GC servers reside in the same network segment.

Note

To tolerate directory failures, Exchange 2000 Server can reacquire GCs if the current GC server fails.

Estimating Hardware Requirements for Global Catalog Servers

In addition to ensuring that the network connections between MAPI-based clients and GC servers are fast and reliable, you also need to check that your GCs can cope with the workload. To facilitate this job, Microsoft provides a helpful Resource Kit tool called Active Directory Sizer (MSSIZER.EXE). You can download this tool from Microsoft’s Web page (www.microsoft.com ). Search for the phrase "Active Directory Sizer."

The Active Directory Sizer allows you to estimate the hardware resources needed on your GCs based on the number of users per domain and other information, such as the total number of attributes replicated to the GC per user. For detailed information, see the Active Directory Sizer help file, which comes with the utility.

Important

You need to ensure that Windows 2000 Service Pack 1 is installed on all of your GC servers because Service Pack 1 contains many fixes related to Active Directory.

Figure 3.14 - Access to a global catalog over slow network connections

Verifying the Site Topology

The demand for two or more domain controllers in each domain and two or more GCs in each site can result in a large amount of replication traffic that your network must be able to sustain. For this reason, you should check your site topology to verify that your sites do not span WAN links. The configuration of your site links determines the paths and patterns that the directory replication takes through your network.

You should define and configure all sites before deploying Exchange 2000 Server because the extension of the Active Directory schema, which happens during the first server installation, generates substantial replication traffic. All domain controllers in the forest must receive the schema updates. Likewise, all GCs must rebuild their GC information because the schema changes affect the existing user account and group objects.

Note

It is not unusual for very large organizations to initially install and configure all GC servers in a central location in order to perform the first replication over LAN connections. Once the directories are replicated, the servers are shipped to the remote sites. This approach can help to minimize replication traffic over the WAN.

Preparing an Active Directory Forest for Exchange 2000

The preparation of an Active Directory forest for Exchange 2000 entails the extension of the directory schema and possibly the preparation of the domains. Microsoft recommends extending the schema as early as possible—ideally right after the installation of the very first domain controller (that is, the root domain controller). Domain controllers added subsequently will then receive the extended schema right away, which effectively saves you the replication overhead that occurs in a fully deployed Active Directory environment. In a multidomain forest with numerous domain controllers and GCs, it would be advisable to carry out the schema extension at off-peak hours (for instance, over a weekend).

It is not necessary to fully install Exchange 2000 Server to extend the schema. Launch Setup in ForestPrep mode (Setup /ForestPrep) if you want to avoid the full server installation. In any case, you need to perform the schema extension in the domain of the schema master, which is typically the root domain of your forest. Your user account must be a member of the Schema Admins, Enterprise Admins, and Domain Admins groups. ForestPrep prompts you for an organization name and an administrator account, which will be assigned Exchange Full Administrator permissions in the organization. The Exchange administrator account should be a member of the Domain Admins group if you want to use it later for installing Exchange 2000 Server. (Schema Admins or Enterprise Admins privileges are then not required). You only need to run ForestPrep once within your forest.

The Exchange 2000 Setup program also provides you with a /DomainPrep command-line switch to prepare the domains in your forest without installing any servers. This is required, for instance, if you have domains in your forest that contain user accounts but do not contain Exchange 2000 servers. DomainPrep creates a domain-local security group called Exchange Enterprise Servers and a global security group called Exchange Domain Servers and adds the Exchange Domain Servers group as a member to the Exchange Enterprise Servers group. Exchange Enterprise Servers is used to grant the Recipient Update service of Exchange 2000 the required rights to access the user information in the domain to build consistent address lists. It is usually not necessary to prepare those domains beforehand where you plan to install Exchange 2000 Server.

Note

Setup launches the ForestPrep and DomainPrep modes automatically if you install Exchange 2000 Server in an unprepared forest or domain.

Native Mode Domains

Mail-enabled Windows 2000 groups provide a convenient way to address multiple recipients at one time, and they can also be used to grant permissions on public folders and other resources. Active Directory supports security and distribution groups with a domain-local, global, or universal scope. The difference is that security groups can be used to delegate access permissions to its members, whereas distribution groups do not represent security principals and don’t support permission assignments. For this reason, give security groups preference over distribution groups.

In multidomain environments, domain-local and global groups have significant disadvantages. Domain-local groups, for instance, are unavailable in other domains and are not suitable to build a consistent global address list. Global groups, on the other hand, cannot contain any members from other domains, which somewhat limits their usefulness. Only universal groups can contain members from any domain in the forest and are globally available because they are replicated to the GC servers. Thus, you should use universal security groups in your messaging environment to build consistent server-based address lists across all domains.

There is one catch, however. Windows 2000 domains in mixed mode do not support universal security groups. Therefore, you should switch your domains into native mode to best meet the requirements of the messaging organization. If you need to support legacy Windows NT domain controllers, and are thus unable to switch to native mode, consider installing Exchange 2000 in a native mode child domain and then creating all mail-enabled universal security groups in this domain. Another possibility is use of universal distribution groups as long as the domains must remain in mixed mode (although this limits your flexibility when configuring permissions for public folders). As soon as all Windows NT domain controllers are decommissioned, switch your domain into native mode and convert the universal distribution groups into universal security groups.

The Active Directory Environment of Adventure Works

Adventure Works, a fictitious Canadian company, offers customized expeditions through North America and the Arctic Circle as well as photographic safaris through South Africa and Australia. The company plans to unify the management of user accounts and mailbox resources based on a consolidated directory infrastructure.

As mentioned earlier in this lesson and shown in greater detail in Figure 3.15, Adventure Works has structured its domain topology according to their locations in Canada, the United States, South Africa, and Australia. Figure 3.15 also shows the site topology with three sites for North America, South Africa, and Australia.

TIP

You can find more information about the Active Directory environment of Adventure Works in ADVENTURE_WORKS.XLS, which is in the \Chapter03\Examples directory on the Supplemental Course Materials CD.

When reviewing the environment of Adventure Works, you can find that the Active Directory design:

Is limited to a single forest with all domains operating in native mode
Has more than one domain controller in each domain (with the exception of adventure-works.com, which only has one domain controller because it does not contain user accounts)
Has two or more GCs in each site (three in North America)
Shows a well-structured site topology for efficient directory replication with the site of North America as the central replication hub
Gives the required permissions to extend the schema in the root domain adventure-works.com to Mr. John Y. Chen

Even though Adventure Works relies on fast WAN connections between the various geographical locations, you may find it reasonable to split the site of North America to ensure optimal GC response times in Canada and the United States. It may also be a good idea to install a second domain controller in the root domain and configure it as a GC to provide redundancy in case VAC-01-DC goes down or is destroyed.

Figure 3.15 - The sample domain and site topology of Adventure Works

Activity: Evaluating Active Directory Environments

In this activity, you are introduced to two fictitious companies that plan to deploy Exchange 2000 Server as their enterprise messaging system. It is your task to analyze the existing Active Directory environments to identify required changes to best accommodate Exchange 2000 Server.

TIP

For this activity, you can find two workspaces containing detailed information about the Active Directory environments in the \Chapter03\Examples directory on the Supplemental Course Materials CD. The filenames are COHO.XLS and WOODGROVE.XLS.

Scenario: Coho Vineyard & Winery

For 75 years, family-owned Coho Vineyard & Winery has retained its reputation as a fine and painstaking wine-maker, offering a complete range of California wines to its customers. Overlooking the Napa Valley in California, the winery, with its 250 employees, is always seeking ways to improve customer satisfaction. To further enhance the winery’s reputation for selfless support of the wine-making community, Coho Vineyard & Winery plans to build an interactive Web-based communications network for home wine-makers. "We prefer to leave the wine-making to the yeast and focus on an optimization of our business processes," says Paul West, Information Technology Administrator at Coho Vineyard & Winery, with a smile. "We already installed a Windows 2000 Server for our SQL-based accounting application and fully deployed Windows 2000 Professional on all workstations. Now, we plan to implement workgroup solutions based on Exchange 2000 Server." Coho Vineyard & Winery’s Active Directory environment is displayed in Figure 3.16.

Figure 3.16 - The domain topology of Coho Vineyard & Winery

It is your task to assess the readiness of Coho Vineyard & Winery’s Active Directory environment for Exchange 2000 Server.

List two advantages of the current approach for Coho Vineyard & Winery.
List the most important disadvantage of the current approach for Coho Vineyard & Winery.
List three possible improvements for the Active Directory environment of Coho Vineyard & Winery.

Scenario: Woodgrove Bank

Woodgrove Bank, one of the largest private banks in Switzerland, has been providing worldwide financial services for more than 150 years. The bank has offices in Zurich, Bern, Basel, Frankfurt, London, Tokyo, Hong Kong, New York, and the Cayman Islands. Always interested in streamlining business processes, Woodgrove Bank has decided to implement Exchange 2000 Server. "We just finished migrating our Windows NT environment to Windows 2000 and Active Directory," explains Mr. Luis Bonifaz, Chief Information Officer at Woodgrove Bank. "It was a complex undertaking and I must admit that we had several problems in the beginning, but after hiring an experienced computer consultant and upgrading the WAN links between Zurich, Bern, and Basel to 4 Mbps, everything went smoothly. I’m convinced you won’t find anything wrong in our Active Directory environment." The Active Directory environment of Woodgrove Bank is shown in Figure 3.17.

It is your task to assess the readiness of Woodgrove Bank’s Active Directory environment for Exchange 2000 Server.

Name one critical issue in Woodgrove Bank’s Active Directory environment.
Which approach would you choose and why?

Lesson Summary

Exchange 2000 Server is the first messaging system from Microsoft that comes without a proprietary directory. Instead, this platform takes full advantage of Active Directory and integrates tightly with the Windows 2000 domain environment. During the installation of the first Exchange 2000 server in a forest, the Setup program extends the Active Directory schema to support Exchange 2000-specific object classes and attributes. Exchange 2000 Server stores the majority of its configuration and all recipient information in Active Directory.

Active Directory replicates its schema and configuration information to all domain controllers in the forest, which implies that a particular Exchange 2000 organization always spans the entire forest. It also implies that there cannot be two or more organizations and that a single organization cannot span multiple forests. The extension of the database schema can generate substantial replication traffic. For this reason, Microsoft recommends updating the Active Directory schema using Setup in ForestPrep mode as early as possible in the Windows 2000 deployment.

Figure 3.17 - The Active Directory environment of Woodgrove Bank

Recipient information—that is, information about mailbox- and mail-enabled user accounts, contacts, groups, and public folders—is maintained in the domain NC. This allows you to use standard utilities, such as the extended Active Directory Users and Computers console, to manage user accounts and mailbox settings in one place. However, you need to exercise care if you want to provide global distribution lists. For instance, you should switch your domains into native mode to gain the ability to use universal security groups for this purpose. Universal security groups are available across the entire forest, can have members from any domain, and can be used to assign public folder permissions to members.

It is important to keep in mind that Active Directory does not replicate domain information to ordinary domain controllers outside the local domain. You need to configure GC servers to accomplish this. GCs receive a partial replica of every domain NC in the environment. MAPI-based clients use the NSPI to communicate with GCs and Internet-based clients can use LDAP to access recipient information. To avoid end-user complaints, make sure that the client connections to the GCs are fast and reliable. The placement of GC servers in the network is a critical design consideration for Exchange 2000.