Active Directory Health Check: Replication Topology & Subnets

Active Directory provides authentication and authorization services. A healthy Active Directory environment keeps all other services running effectively. As a result, most production services these days rely heavily on the authentication and authorization subsystem of Active Directory.

While many organizations have processes and procedures in place that help in performing a health check of an Active Directory environment, not all will have important checks included in their health check processes.

For example, some IT admins might forget to include checking replication topology and some might not include a basic check to ensure the ISTG role is defined for every Active Directory site that holds two or more domain controllers.

How to run an Active Directory health check

In today’s Server Tutorial we are going to list a few important Active Directory health check items that every Active Directory admin should perform to ensure Active Directory is optimally providing the required services.

Active Directory Replication Topology: There are two Active Directory topologies that can be defined: Hub-Spoke Replication Topology and Mesh Replication Topology.

In a Mesh Replication Topology, Active Directory sites are connected to each other. In Hub-Spoke Replication Topology, Spoke sites, sometimes referred as branch sites, always talk to a Hub Site. A Hub Site is sometimes referred to as the central site. Microsoft always recommends Hub-Spoke Replication Topology. There are several benefits associated with Hub-Spoke Replication Topology as outlined below:

• KCC (Knowledge Consistency Checker), a component designed to re-evaluate the replication topology, takes less time to calculate and create the replication connection objects between domain controllers.
• Hub-Spoke Replication Topology allows you to ensure that the Active Directory replication occurs between domain controllers running in the central site and domain controllers running in the Spoke sites. This prevents domain controllers running in spoke sites to replicate with each other.
• Helps you distribute Active Directory replication changes quickly. In the Hub-Spoke Replication Topology, changes made in a Hub Site will ensure that changes are distributed to all domain controllers running in the spoke sites quickly and efficiently.
• Helps you troubleshoot replication issues quickly. Since Spoke sites will talk to Hub site for replication, it is easy to identify replication connection objects and then troubleshoot any issues.

To check Active Directory Replication Topology, you need to ensure that each AD Site Link created in AD Sites and Services has a maximum of two AD sites. Each AD Site Link must contain a Hub site name.

For example, if there are six Spoke sites and one Hub site, each AD Site Link must contain one Hub Site and one AD Site from Spoke sites. If there are hundreds of Active Directory sites, it will take a considerable amount of time to identify the Site Links that contain more than three AD Sites.

We have put together a script that you can use to collect this information in a CSV file:

$CurForestName="ServerWatch.com"
$TestCSVFile="C:TempTestCSV.CSV"
$RPath="C:TempADTopology.CSV"
$TestText =""
$FinalTot = 0

IF (Test-Path $RPath)
	{
	Remove-item $RPath
	}

IF (Test-Path $TestCSVFile)
	{
	Remove-item $TestCSVFile
	}

$ThisString="AD Site, In Total AD Site Links, AD Site Links"
Add-Content "$TestCSVFile" $ThisString
Add-Content $RPath "Sites:"

$R=Get-ADReplicationSiteLink -filter *
ForEach ($Link in $R)
	{
	$RR=$Link.SitesIncluded
	ForEach ($AllS in $RR)
		{
		$STR = $AllS+":"
		Add-Content $RPath $STR
		}
	}

$RCSV = Import-CSV $RPath -Delimiter ":"
$a = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext("Forest", $CurForestName)
[array]$ADSites=[System.DirectoryServices.ActiveDirectory.Forest]::GetForest($a).sites

IF ($Error.count -ne 0)
	{
	ForEach ($Site in $ADSites)
		{
		$ThisSite = $Site.Name
		$ThisSiteLink = $Site.SiteLinks
		$CompDN=(Get-ADReplicationSite -Identity $ThisSite).DistinguishedName
		$TotNow=0
		ForEach ($AllSitesNow in $Rcsv)
			{

			IF ($AllSitesNow.Sites -eq $CompDN)
				{
				$TotNow++
				}
			}

		IF ($TotNow -ge 2)
			{
			$ThisStr=$ThisSite+","+$TotNow+","+$ThisSiteLink.Name
			$ThisStr
			Add-Content "$TestCSVFile" $ThisStr
			$FinalTot++
			}
		}

	IF ($FinalTot -eq 0)
		{
		}
		else
		{
		$TestText = "Some AD Sites appear in multiple AD Site Links. This creates Mesh Topology."
		}

	}

$TestText

Note that you need to change “$CurForestName” variable in the above script to reflect your Active Directory forest name.

Subnets not associated with AD Sites:Another important Active Directory health check you need to perform is to ensure that subnets are associated with AD Sites.

Every AD Site location that has at least 100 users must have a subnet associated with it. While many Active Directory admins do not pay attention to this health check item, it can help you with several things as outlined below:

• If you associate appropriate subnets with AD Sites, users in that AD Site will not go to remote domain controllers for authentication.
• Helps you load balance authentication traffic by ensuring that local services use local domain controllers for authentication and authorization purposes rather than connecting to remote domain controllers, which in turn might result in overworked domain controllers at remote locations.

To get a list of subnets that have not been associated with AD Sites yet, you can get a list by collecting “NO_CLIENT_SITE” information from %SystemRoot%DebugNetLogon.Log on each domain controller.

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 nirmal_sharma@mvps.org.

Follow ServerWatch on Twitter and on Facebook