Recipe 11.6 Finding Missing Subnets | Active Directory Cookbook, 3rd Edition

11.6.1 Problem

You want to find the subnets that are missing from your site topology. Missing subnets can result in clients not authenticating against the most optimal domain controller, which can degrade performance.

11.6.2 Solution

Having all of your subnets in Active Directory is important because a client that attempts to logon from a subnet that is not associated with any site may authenticate with any domain controller in the domain. This can result in the logon process taking longer to complete. Unfortunately, Microsoft has not provided an easy way to rectify this problem.

Under Windows 2000, the only source of missing subnet information was the System event 5778. Here is an example:

Event Type:        Information Event Source:        NETLOGON Event Category:        None Event ID:        5778 Date:                1/27/2003 Time:                12:07:04 AM User:                N/A Computer:        DC2 Description: 'JSMITH-W2K' tried to determine its site by looking up its IP address ('10.21.85.34')  in the Configuration\Sites\Subnets container in the DS.  No subnet matched the IP  address.  Consider adding a subnet object for this IP address.

The only way to dynamically determine missing subnets is to query each domain controller for 5778 events and map the IP addresses specified within the events to a subnet you add to the site topology.

With Windows Server 2003 things are not that much better. One of the issues with the 5778 events under Windows 2000 is that they could easily fill up your System event log if you had many missing subnets. In Windows 2003, Microsoft decided to instead display a summary event 5807 that states that some number of connection attempts have been made by clients that did not map to a subnet in the site topology. Here is an example:

Event Type: Warning Event Source: NETLOGON Event Category: None Event ID: 5807 Date: 1/10/2003 Time: 10:59:53 AM User: N/A Computer: DC1 Description: During the past 4.18 hours there have been 21 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file '%SystemRoot%\debug\netlogon.log' and, potentially, in the log file '%SystemRoot%\debug\netlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters\LogFileMaxSize'; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/ events.asp.

Instead of scraping the event logs on every domain controller, you can look at the %SystemRoot%\debug\netlogon.log file on each domain controller and parse out all the NO_CLIENT_SITE entries. This is still far from an easy process, but at least the event logs are no longer cluttered with 5778 events.

Here is an example of some of the NO_CLIENT_SITE entries from the netlogon.log file:

01/16 15:50:07 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157 01/16 15:50:29 RALLENCORP: NO_CLIENT_SITE: SJC-BACKUP 44.25.26.142 01/16 16:19:58 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157 01/16 16:20:07 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157 01/16 16:50:07 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157 01/16 16:57:00 RALLENCORP: NO_CLIENT_SITE: JSMITH-W2K1 10.61.80.19 01/16 17:20:08 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157 01/16 17:50:08 RALLENCORP: NO_CLIENT_SITE: RALLEN-TEST4 164.2.45.157

If you wanted to get creative and automate a solution to do this, you could write a script that goes out to each domain controller, opens the netlogon.log file and retrieves NO_CLIENT_SITE entries. You can then examine all of the IP addresses and create subnets in Active Directory that would contain them. You could associate all of those subnets with a default site or even use the Default-First-Site-Name site. Then once a week (or whenever), you could look at the sites that were created or that were associated with the default site and determine what site they really should be associated with.