GuidesAD Key Health Checks, Part 3: Designating Bridgehead Servers

AD Key Health Checks, Part 3: Designating Bridgehead Servers

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Welcome to the latest installment of our popular Active Directory Key Health Check Items series of server tutorials. In Part 1, we explained some of the basic checks you can perform to ensure you have implemented a Hub-Spoke AD Replication topology.

We also provided a PowerShell script that you can run against an Active Directory Forest to ensure each AD Site Link created in the AD Sites and Services has a maximum of two AD Sites. Windows Server TutorialsEach AD Site Link must contain a Hub Site name to implement a Hub-Spoke AD Replication Topology model.

Part 2 of the series focused on domain controller storage health checks. We provided a PowerShell script that can report on the location of Active Directory files and also provide you with the amount of free space available on each disk volume on each domain controller.

An important health check in an Active Directory environment you should always perform is verifying the bridgehead server assignment in each Active Directory site. In today’s Server Tutorial we are going to explain why it becomes imperative to avoid designating manual bridgehead servers in a large Active Directory production environment. We also provide a PowerShell script that allows you to collect Bridgehead Server information from each Active Directory Site.

Why It’s Important to Avoid Manually Assigning Bridgehead Servers

A bridgehead server in an AD Site is responsible for replicating changes to and from bridgehead servers running in other AD Sites. KCC, an Active Directory component, is responsible for designating domain controllers as bridgehead servers automatically, and it has the ability to recover from failed bridgehead servers automatically.

For example, if an automatically assigned bridgehead server goes down, KCC will re-evaluate the AD Replication topology and configure another available domain controller in the AD Site as a bridgehead server.

Manually configuring bridgehead servers may lead to replication errors. In other words, the Active Directory changes you are expecting to be replicated across an Active Directory Forest might fail if one of the manually assigned bridgehead servers goes down.

This is because when you manually configure a domain controller as bridgehead server, KCC will use only that server to perform Active Directory replication functions. If a manually configured bridgehead server goes down in any of the AD Sites, KCC will not be able to automatically select an alternate bridgehead server, resulting in replication failures.

Collecting Bridgehead Server information from an Active Directory Forest

To ensure there are no manually configured bridgehead servers, you can execute the following PowerShell script. This script performs the following functions:

  • Collects the current Active Directory Forest Name
  • Verifies the domain controllers configured as bridgehead servers in each AD Site
  • Checks to see how many “manual” IP and SMTP bridgehead servers have been configured in each AD site
  • Provides the name of the domain controllers configured as bridgehead servers
  • Reports the output in a CSV file

Note: This script does not perform any write operations to the Active Directory environment.

Please follow the steps outlined below to ensure the script works properly on your end:

  1. Change “” as the forest name. Although this script collects the Active Directory name automatically by executing the Get-ADForest PowerShell cmdlet, you can specify the Active Directory Forest that you would like the script to query by modifying the “$CurForestName” variable in the script.
  2. Modify the report file location in the “$TestCSVFile” variable. The default location for storing script output is C:TempADSiteBHServers.CSV.
  3. Copy the entire script below to a .PS1 file and then execute from an elevated PowerShell window.

### Script starts here ###

$TestCSVFile = "C:TempADSiteBHServers.CSV"
$ThisString="AD Site,Auto BH,Servers,Manual IP-BHs,IP-Servers,Manual SMTP-BHs,SMTP-Servers,Final Status"
Add-Content "$TestCSVFile" $ThisString

$GetForestName = (Get-ADForest).Name

$CurForestName = $GetForestName   ## Type your AD Forest name here…

$a = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext("Forest", $CurForestName)

IF ($Error.count -eq 0)

ForEach ($Site in $ADSites)
	$SiteName = $Site.Name

	IF ($Site.PreferredRpcBridgeheadServers.Count -ge 1 -or $Site.PreferredSmtpBridgeheadServers.Count -ge 1)
		$FinStatusNow="Check why Manual Bridgehead Servers were assigned to AD Site."
	Add-Content "$TestCSVFile" $ThisStr

IF ($ErrorOrNot -eq "Yes")
	$TestText = "Please check to make sure a Domain Controller is reachable to execute AD Test."
	$SumVal = ""
	$TestStatus="Error executing AD Test."
	IF ($TotNo -eq 0)
		$TestText = "No Manual Bridgehead Servers were found in AD Sites."
		$SumVal = ""
		$SumVal = $TotNo
		$TestStatus = "High"
		$TestText = "Some AD Sites are configured with manual Bridgehead Servers. Since KCC can designate a domain controller as a bridgehead server automatically, it is recommended to avoid assigning manual Bridgehead Servers. "

$STR = $ADTestName +","+$TestStartTime+","+$TestStatus+","+$SumVal +","+$TestText

### Script Ends here ###

Once the script has finished executing for the Active Directory Forest, a report will be generated in the C:TempADSiteBHServers.CSV file as shown in the screenshot below:

Active Directory Health Check - Figure 1

As you can see in the report above, the script collected all AD Sites from the Active Directory Forest assigned in the “$CurForestName” variable and then reported the bridgehead server names for each AD Site.

In the output above, the script reported “Check Why Manual Bridgehead Servers were assigned to AD Site” in the Final Status column for SiteC. This is because the script found two manual bridgehead servers named and in the SiteC AD Site. However, the script reported “Ok” in the Final Status for AD Sites that didn’t have a manually assigned bridgehead server.

This PowerShell script is part of the “AD Site Bridgehead Servers Test” Dynamic Pack that is available for use with the Active Directory Health Profiler.

The AD Health Profiler is capable of reporting the issue severity for each issue it identifies in a managed Active Directory Forest. As you can see in the red square on the screenshot below, the AD Health Profiler reported High Severity when it found the manual bridgehead servers in the Active Directory Forest:

Active Directory Health Check - Figure 2

The Active Directory Health Profiler allows you to run 67 Active Directory heath checks and can be executed for the entire Active Directory forest, for individual domains or for individual domain controllers.


We explained why it is necessary to avoid manual bridgehead server assignments. Since KCC automatically takes care of designating appropriate domain controllers as bridgehead servers and facilitates recovery from a failure of an automatically assigned bridgehead server, you should always avoid configuring manual bridgehead servers in large production Active Directory Forests.

The PowerShell script we offered in this Server Tutorial can be used to collect a report on Bridgehead Servers from each Active Directory site and help you identify the AD Sites that have manual bridgehead servers configured.

Nirmal Sharma is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He specializes in directory services, Microsoft Azure, Failover clusters, Hyper-V, System Center and Exchange Servers, and has been involved with Microsoft technologies since 1994. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Health Packs for ADHealthProf.ITDynamicPacks.Net solutions. Nirmal can be reached at

Follow ServerWatch on Twitter and on Facebook

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories