Note on IT

Published: December 6, 2004

Heavy messaging load within Microsoft requires high performing and highly available Active Directory servers to help satisfy the service level agreements (SLAs) for mailbox servers, public folder servers, Simple Mail Transport Protocol (SMTP) and routing group bridgehead servers, and Exchange front-end servers. Microsoft IT outlines steps for creating a dedicated Active Directory site for large enterprise data centers where Exchange data is located.

Introduction

At Microsoft, there are over 100,000 mailboxes and over 85,000 distribution groups. Microsoft circulates more e-mail messages internally and receives more inbound Internet mail than most other organizations its size.

When running Microsoft® Exchange Server 2003 or Exchange 2000 Server in larger environments, the frequency of queries to the Active Directory® directory service can be very high. Exchange Server uses its directory access component to communicate with Active Directory domain controllers and global catalog servers to perform tasks such as e-mail address lookups, distribution group expansion, Microsoft Outlook® client proxy, and referral services. With such a heavy load being placed on domain controllers, Microsoft IT optimized the performance of Exchange when communicating with Active Directory by creating a new Active Directory site and isolating domain controllers and global catalog servers just for Exchange.

This document is intended to create an understanding of the environmental inputs that affect the Microsoft IT Active Directory server performance and Exchange performance and will provide a design solution to those inputs.

Note   For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed applications and files used in this document do not represent actual names used within Microsoft and are for illustration purposes only. In addition, the contents of this document describe how Microsoft IT runs its enterprise data center. The procedures and processes included in this document are not intended to be prescriptive guidance on how to run a generic data center and may not be supported by Microsoft Customer Service and Support.

Background

Active Directory sites typically represent the physical structure of an enterprise network. Sites are groups of well connected networks connected through site links. Sites define an organization's replication topology. Subnets are associated with sites in classless interdomain routing (CIDR) format. Subnets allow administrators to associate groups of computers and other network devices to a particular site. Sites can also be used to determine where users authenticate.

For example, WORKSTATION1 is a Microsoft Windows® XP Professional client that has recently joined the Microsoft corporate domain, nwtraders.local:

1. When the user of WORKSTATION1 attempts to log on to the domain for the first time, WORKSTATION1 queries the Domain Name System (DNS) server specified in its Transmission Control Protocol/Internet Protocol (TCP/IP) configuration settings to query for the _ldap._tcp._dc._msdcs.nwtraders.local record in Active Directory.
2. The DNS server returns a list of domain controllers in that domain, sorted by priority and weight (discussed later in this document).
3. WORKSTATION1 chooses a domain controller with which to make an attempt to authenticate.
4. WORKSTATION1 issues a Lightweight Directory Access Protocol (LDAP) query to establish contact with this domain controller. That domain controller returns back to WORKSTATION1 information about itself, and using the source address from the LDAP query, information about the site of which WORKSTATION1 is a member.
5. WORKSTATION1 performs as site-specific DNS lookup for a domain controller. Subsequent operations are performed using this domain controller.

This process also takes effect when an Exchange member server does site discovery. For more information about how clients authenticate, see the following Microsoft Knowledge Base articles: "How Domain Controllers Are Located in Windows XP" and "How Domain Controllers Are Located in Windows".

Creating an Active Directory Site for Exchange

There are three steps to creating an Active Directory site for Exchange:

1. Create the Active Directory site.
2. Create a new subnet.
3. Isolate authentication traffic from clients to Exchange facing domain controllers.

Microsoft IT creates sites using the Active Directory Sites and Services snap-in for the Microsoft Management Console (MMC). To view sites from a non-domain controller, either install the Windows Administration Pack (Adminpak.msi) from the %SystemRoot%\system32 folder or manually open it from within MMC, using the following steps:

1. Click Start, and then click Run.
2. Type mmc.exe and press Enter.
3. Click File, and then click the Add/Remove Snap-In.
4. Click Add.
5. Select the Active Directory Sites and Services module and click Add.
6. Click Close.
7. Click OK to finish.

Creating the Active Directory Site

Follow the instructions to create a new Active Directory site:

1. Open the Active Directory Sites and Services module in MMC.
2. Right-click the Sites container and select New Site.
3. Type a site name that reflects the purpose of this new site. (In this example, Datacenter-Exchange will be used.)
4. Choose a site link appropriate for your environment. (In this example, DEFAULTIPSITELINK will be used, but the actual link used will differ in each enterprise, depending upon the topology used.)
   • Configure the siteLink replication interval to be the minimum (15 minutes).
   • Configure the siteLink cost value to be the lowest value in the environment.
5. Click OK.
6. Move domain controllers and global catalogs to the new site:
   1. Right-click each domain controller and global catalog you want to move and select Move.
   2. Select the new site (Datacenter-Exchange) to which to move the server, and then click OK.

Note   Although Microsoft suggests a 1:4 global catalog processor to Exchange processor ratio for global catalog servers that service Exchange environments, Microsoft IT has determined that a better approach should be based on performance, number of users, hardware specifications, and reliability and redundancy requirements. The number of domain controllers and global catalog servers moved should be based on your organization's needs.

Create a New Subnet

Follow the instructions to create a new subnet:

1. With the Active Directory Sites and Services module open in MMC, right-click the Subnets container and select New Subnet.
2. To create a subnet scoped to one Exchange server, follow these directions referencing Figure 1 that follows:
   1. For the IP address, type the exact IP address of the Exchange server (such as 10.0.0.10).
   2. For the subnet mask, type 255.255.255.255.

   This will result in a subnet scoped to just the one Exchange server with the name of 10.0.0.10/32, which is the CIDR notation for the IP address and a 32-bit subnet mask.

   
   If your browser does not support inline frames, click here to view on a separate page.

   Figure 1  Creating a new subnet for one Exchange server

   Notes   If you have multiple servers whose IP addresses are not contiguous, you will also need a subnet as defined above.

   If you have multiple Exchange servers with contiguous IP addresses, it may be possible to create a subnet for these servers. This process requires some knowledge of subnetting. For example, to build a subnet that can support three Exchange servers with contiguous IP addresses, you would use a formula similar to 2n - 2 >= 3. In this example, n represents the number of network bits borrowed for the hosts. So, 23-2 >= 3. Based on this calculation, a subnet mask of 255.255.255.248 is needed.

   Although you can create a subnet for a range of IP addresses, remember you only want the IP addresses of Exchange servers in this site. For this reason, Microsoft IT recommends that servers be added to sites singularly using /32 subnet masks (255.255.255.255).

3. Under Select a site object for this subnet, choose the newly created site Datacenter-Exchange created earlier.
4. Wait at least 30 minutes (or twice the replication interval configured for 15 minutes in the earlier site link creation step) for the new site and subnet to replicate.
5. To verify membership has been updated, run the following command at a command prompt:
   nltest /dsgetsite

   This command will return the site membership of the server, similar to the following:

   Datacenter-Exchange The command completed successfully.

6. If site membership is not updated, use the Services MMC snap-in to stop and restart the Net Logon service on the Exchange server to update its site membership.
7. If site membership has not updated, it is probably being read from cache. You can be sure to return non-cached information by using the following command:
   nltest /dsgetdc:<NetBIOS domain name> /force

   The command will return information similar to the following, using "intranet" as a sample NetBIOS domain name:

   C:\ >nltest /dsgetdc:intranet /force DC: \\DC1 Address: \\10.1.1.50
                   Dom Guid: bfa3fad5-fa44-4268-b416-0626c013f9ea Dom Name: INTRANET Forest Name: nwtraders.local
                   Dc Site Name: Datacenter-Exchange Our Site Name: Datacenter-Exchange Flags: GC DS
                   LDAP KDC WRITABLE DNS_FOREST CLOSE_SITE The command completed successfully.

Isolate Client Authentication Traffic from Exchange Facing Domain Controllers

When clients authenticate, the DNS server returns a list of servers. In DNS, service (SRV) records have three values associated with them.

For example, in DNS Manager, you would see an SRV record that looks similar to the following:

_ldap._tcp._dc._msdcs.nwtraders.local      [0] [100] [389]      dc1.nwtraders.local

The numeric values of the middle portion of this display are defined as follows:

• [0] represents the priority of the record. A client must attempt to contact the target host with the lowest-numbered priority it can reach. Target hosts with the same priority should be tried in an order defined by the weight of the record. The range is 0–65535.
• [100] represents the weight of the record. Weight determines how records of the same priority will be load balanced. The higher this value, the more likely the client will choose the domain controller identified in this SRV record against which to perform queries. Typically, weights are adjusted depending on the hardware platform of the domain controller. If there are two domain controllers, one with more processing power than the other, the more powerful domain controller can handle more query requests and thus should be given a greater percentage of the total workload.

  Note   Exchange Directory Access uses only the weight value to determine which server the client should prefer. Therefore, administrators can use the priority value to control Active Directory load generated by logons, and the weight value to control Active Directory load generated by Exchange. A higher weight results in a higher probability that Directory Access will choose a server. Directory Access treats a weight of 0 the same as it treats a weight of 1. If Directory Access cannot read the weight, it uses a default weight of 100.

• [389] represents the network port on which the service record will listen for activity.

These values are controlled by the Net Logon service on the domain controller. Values of 0 for priority and 100 for weight are the default. Modify these values in the domain controller's registry.

The following steps detail how Microsoft IT implemented specific registry modifications to change server priority.

Warning   Incorrectly editing the registry can have serious, unexpected consequences that can prevent the system from starting and require you to reinstall Microsoft Windows. A recommended best practice is to export the subkey before editing it. You can also set a System Restore point prior to using Registry Editor.

1. Start Regedit.exe, and then browse to the subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\
   Parameters
2. On the Edit menu, click Add Value, and then enter the following registry subkey values:
   • Value name: LdapSrvPriority
   • Data type: REG_DWORD
   • Set the value to the desired value of the priority, such as LDAPSrvPriority REG_DWORD = 1

   Note   The priority for all domain controllers in the site must be the same, and the priority for all domain controllers in the site must be greater than all authentication domain controllers in the domain.

3. To change server weight, on the Edit menu, click Add Value, and then enter the following registry values:
   • Value name: LdapSrvWeight
   • Data type: REG_DWORD
   • Set the value to the desired value of the weight, such as LDAPSrvWeight REG_DWORD = 50

   Note   The LDAP weight value determines the percentage of clients (not queries) which will discover a domain controller. This percentage is equal to the LDAPSrvWeight of the server, divided by the combined LDAPSrvWeight of all domain controllers in the site with the same priority.

4. Close Regedit.exe.
5. Using the Services MMC snap-in, stop and restart the Net Logon service on the domain controller.

   Note   The priority and weight can be changed from within the DNS management console. However, making changes there does not result in the changes being static. The next time the Net Logon service refreshes its DNS records (either hourly or by means of restart of the Net Logon service), the default values will be used, and new SRV records will be created in DNS. This results in multiple SRV records for the same server, which can lead to unexpected behavior.

In environments with pre-Windows 2000 clients, or in which Windows Internet Name Service (WINS) is still used by clients or applications, modifications must be made to the WINS database to prevent authentication traffic from discovering the Exchange facing domain controllers:

1. Delete the WINS <1C> record that is dynamically created by the domain controllers.
2. Create a new WINS <1C> record for the domain, configured as follows:
   • Static
   • Only contains the IP addresses of authentication domain controllers

   Note   The WINS <1C> record is a multi-valued list of up to 25 IP addresses for domain controllers in the domain. In this configuration, this list must be manually updated by an administrator when the IP address of an authentication domain controller is modified.

After following the preceding steps, a new site has been scoped to the specific IP addresses of your Exchange server. In addition, domain controller and global catalog servers have been assigned to this site, shielded from client authentication traffic.

To verify that Exchange is now in its own site, open the properties of the Exchange server and look at the Directory Access tab. Diagnostics logging can also be increased on MSExchangeDSAccess Topology to Maximum. To make this change, follow these steps:

1. Start Exchange System Manager.
2. Right-click and choose Properties page of the server you moved into the Exchange site.
3. Click Diagnostics Logging.
4. Select the MSExchangeDSAccess object and increase Topology to MAX.

Every 15 minutes, the directory access component of Exchange will do a topology rediscovery and report Event ID 2080 in the application log with information about domain controllers and global catalog servers, both in-site and out-of-site. The Event 2080 record will look similar to the following:

Event Type: Information Event Source: MSExchangeDSAccess Event
        Category: Topology Event ID: 2080 Computer: EXCHANGE1 Description: Process MAD.EXE
        (PID=1808). DSAccess has discovered the following servers with the following characteristics:
        (Server name | Roles | Reachability | Synchronized | GC capable | PDC | SACL right
        | Critical Data | Netlogon | OS Version) In-site: dc1.nwtraders.local CDG 7 7 1
        0 0 1 7 1 dc2.nwtraders.local CDG 7 7 1 0 1 1 7 1 Out-of-site: dc3.nwtraders.local
        CDG 7 7 1 0 1 1 7 1 For more information, click http://www.microsoft.com/contentredirect.asp.

For more information about the preceding event log record, see Microsoft Knowledge Base article "Event ID 2080 from MSExchangeDSAccess".

Summary

As outlined in this document, Microsoft IT created new Exchange sites in Active Directory as a part of its overall design methodology in enterprise data centers for robust, highly available Active Directory servers for Exchange. Microsoft IT adds Exchange servers to Active Directory sites singularly using /32 subnet masks. Microsoft IT also uses the following priority and weight values:

LDAPSrvPriority REG_DWORD = 1 LDAPSrvWeight REG_DWORD = <value
        is dependant upon the server hardware platform used>

The values another enterprise will choose should be specific to their organizational needs and topology.

To monitor Active Directory performance for Exchange, see the section labeled "Ruling Out Active Directory-bound Problems" in the chapter of Microsoft white paper Troubleshooting Microsoft Exchange Server 2003 Performance titled "Chapter 3: Isolating the Causes of the Degraded Performance".

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/services/microsoftservices/howmsdoesIT.mspx

http://www.microsoft.com/technet/itsolutions/msit/default.mspx

For any questions, comments, or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send an e-mail message to:

showcase@microsoft.com

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this document, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Outlook, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.