How to use Set-ExchangeServer cmdlet to manage the workload on Active Directory Domain Controller

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.

Set-ExchangeServer cmdlet parameters that determine which domain controllers Exchange Server will 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.