Set-ExchangeServer cmdlet can ease domain controller workloads

Exchange Server can distribute workloads evenly among domain controllers, but external factors can cause them to become overworked . Executing Exchange Management Shell's Set-ExchangeServer command can help lessen domain controller workloads.

Active Directory requests from Exchange Server can often overload domain controllers. Using Exchange Management Shell's Set-ExchangeServer command can protect domain controllers from additional stress.This tip from Exchange Server expert Brien Posey explains how AD requests can overload domain controllers, how the Set-ExchangeServer command works and the parameters that the command can be used in conjunction with to control which domain controllers Exchange Server uses.

Placing Exchange srvers into a dedicated Active Directory site can be a viable option for organizations running Exchange Server 2003. However, since Exchange Server 2007 uses AD site topology for message routing, having a dedicated site can be counterproductive.

Organizations create dedicated Active Directory sites for Exchange servers to limit the impact on certain domain controllers. Abandoning a site that was previously dedicated to Exchange Server can overwhelm any domain controllers that don't receive LDAP requests.

Exchange Server 2007 generally distributes requests across multiple domain controllers instead of overwhelming a single domain controller; however, global catalog servers can be an exception to this. Although Exchange Server tries to evenly distribute AD requests, external factors can play into how well domain controllers handle the increased workload.

Exchange Server probably isn't the only AD-dependent application in your network. Other applications generate just as many AD requests. These applications may focus on specific domain controllers, rather than spreading Active Directory requests across multiple ones. This means that you may have some domain controllers that are already overworked -- before they even begin servicing Exchange Server requests.

Another factor to consider is that all your domain controllers may not have the same hardware capabilities. Some domain controllers may be able to service more requests than others because they run on more robust hardware.

If external factors are a concern, you can mitigate this by instructing Exchange Server which domain controller to use. One way is to use Exchange Management Shell's Set-ExchangeServer command to instruct Exchange servers on which domain controllers to use -- or not to use.

Note: If you use the Set-ExchangeServer command, you should use the –WhatIf parameter first. Appending the –WhatIf parameter to the Set-ExchangeServer command allows you to see what would've happened if the command had actually been executed. If you're satisfied with the results, you can remove the –WhatIf parameter and execute the command.

Table 1 lists the parameters that can be used with this command to control which domain controllers Exchange Server uses.

Table 1. Set-ExchangeServer cmdlet parameters that determine which domain controllers Exchange Server will use. 




Use this parameter to specify the name, GUID or distinguished name of the server to which you want to apply the command.


This parameter does not place any restrictions on domain controller selection. It specifies which domain controller should be used when the Set-ExchangeServer command is processed.


Tells Exchange Server which domain controller the server should use in conjunction with DSAccess.


Provides Exchange Server with a list of domain controllers that the specified server should use for directory service access (see note below).


Excludes one or more domain controllers from being used by a specified Exchange server.


Allows you to provide the specified Exchange server with a list of the global catalog servers it should use.

The Set-ExchangeServer command can force a specified server to use (or not use) specific domain controllers. Under normal circumstances, avoid assigning Exchange Server a static list of domain controllers.

However, if you previously used a dedicated Active Directory site for Exchange, then using a static list of domain controllers is preferred, as long as the placement of the dedicated site does not negatively impact message routing.

Note: If you must use the Set-Exchange command to provide Exchange with a static list of domain controllers, I'd recommend informing Exchange Server about which domain controllers it should not use, rather than which domain controllers it should use. If you only authorize Exchange Server to use one or two domain controllers -- and those domain controllers become inaccessible -- then Exchange Server will fail even though there may be other domain controllers online.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. 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 website at

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for 

Dig Deeper on Microsoft cloud computing and hybrid services

Cloud Computing
Enterprise Desktop
Virtual Desktop