Recipe 11.6 Finding Missing Subnets

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.