If Active Directory performs poorly, Exchange Server does too. This can be a real problem if you have other applications...
that heavily tax your Active Directory domain controllers. In this tip, I explain two registry hack techniques that will ease the burden on overloaded Active Directory domain controllers and boost Exchange Server performance.
Don't let Exchange Server use the PDC emulator
On a small network, it's usually no big deal if Exchange Server tries to use the PDC emulator. But on a larger network, you can often increase efficiency by directing Exchange Server to a different domain controller.
In addition to its domain controller responsibilities, the PDC emulator often has other duties as well. If Active Directory is running a default configuration, then the domain controller that's acting as the PDC emulator is also performing the other operations master roles for the domain.
If the domain happens to be the first domain that was created in the forest, then the PDC emulator is also performing forest-level operations master roles. Furthermore, some older applications are designed to interact directly with the PDC (or in the case of an Active Directory environment, the PDC emulator).
To configure Exchange Server to avoid the domain's PDC emulator:
- Open the Active Directory Users and Computers (ADUC) console.
- Right click on the domain for which you want to find the PDC emulator and select the Operations Masters command to view the Operations Masters properties sheet.
- Navigate to the PDC tab to access the PDC emulator.
- Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
MSExchangeDSAccess\Profiles\Default. (If the Profiles\Default containers don't exist, then you will have to create them.)
- Create a REG_DWORD value in the Default container named MinUserDc (this is case sensitive).
- Now, you must set a value for the MinUserDC key.
If you want Exchange Server to avoid accessing the PDC emulator in all circumstances, set the MinUserDC key's value to 1. This isn't always a good idea though, because it could cause Exchange Server to malfunction in some situations.
For example, if your domain only has two domain controllers and you tell Exchange Server to never use the PDC emulator, then only one domain controller is left for Exchange Server to use. If that domain controller ever dropped offline, Exchange Server would not be able to function because no usable domain controllers would be available.
Rather than telling Exchange Server to never use the PDC emulator, it's usually better to tell it to avoid using the PDC when other domain controllers are functioning correctly.
To do so, simply enter the minimum number of domain controllers that should be functional before the PDC emulator is avoided. For example, if you wanted to make sure that the PDC emulator is avoided only when three or more domain controllers within the domain were functional, you would assign the MinUserDc registry key a value of 3.
Designate a specific global catalog server to Exchange Server
Another way you can optimize Exchange Server's Active Directory access is by designating to it a particular global catalog server. Any time Exchange Server needs to access the Global Address List (GAL), it does so by making an LDAP query against the global catalog server.
In many Active Directory deployments, there is only one global catalog server. By default, the global catalog server is the first domain controller deployed in the Active Directory forest.
This means that the global catalog server is also holding all forest-level operations master roles and the operations master roles for whatever domain the server belongs to. Therefore, as was the case with the PDC emulator, the global catalog server can get overloaded.
There's more to it than that though. If the global catalog server were to fail, not only could it cause problems for Exchange Server, but nobody except the domain administrator would be able to log in until the global catalog server was brought back online.
You can improve the way that Exchange Server (and your network as a whole) functions by designating at least one more domain controller to function as a global catalog server. That way, if your network's original global catalog server were to fail, Exchange could still function correctly and users would still be able to log onto the domain.
Once you have created one or more additional global catalog servers, you can configure Exchange Server to use a specific one. If that designated global catalog server becomes unavailable, Exchange Server will revert to using any available global catalog server.
- Pick a domain controller that you want to function as a global catalog server. Generally this should be a server with a light workload and near constant availability.
- Open the Active Directory Sites and Services console (found in Windows Server 2003's Administrative Tools menu).
- Navigate to Active Directory Sites and Services -> Sites -> Default First Site Name (or the site of your choice) -> Servers -> your server of choice -> NTDS Settings.
- Right click on the NTDS Settings container and select Properties.
- Go to the General tab.
- Select the Global Catalog checkbox and click OK to configure the server to act as a global catalog server.
Now it's time to configure Exchange Server to use the new global catalog.
- Open the Registry Editor on the Exchange server and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
MSExchangeDSAccess\Profiles\Default\UserDC1. (If the Profiles\Default\UserDC1 containers do not exist, you will have to create them.)
Once the necessary containers are in place, there are three registry keys you have to create.
- The first key you must make is a REG_SZ value named HostName. Assign this key a value that reflects the fully qualified domain name (FQDN) of the global catalog server that you want to use.
For example, on my own network I am designating a server named Taz that exists in a domain named production.com. Therefore, I would assign the HostName key a value of taz.production.com.
- The next registry key is a REG_DWORD value named IsGC. This key should be assigned a value of 0x1, and it simply activates the global catalog server assignment.
- The last registry key you need to create is a REG_DWORD key named PortNumber. This key tells Exchange Server which port number to use for LDAP access to the global catalog server. Unless you have configured Active Directory to use non-default port numbers, you should use a value of 0xCC4 (0xCC5 for SSL).
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
- Tip: Global catalog server best practices for Exchange Server
- Tip: Troubleshooting Exchane Server global catalog issues
- Tip: How to audit changes to Active Directory
- Reference Center: Exchange Server and Active Directory technical resources
Please let others know how useful this tip was via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.
Dig Deeper on Microsoft Exchange Server and Active Directory