Undefined subnets in Active Directory

It seems like in many environments, there is always a disconnect between the people deploying networks, and ensuring the new subnets are defined in the proper active directory sites. Perhaps there are some IPAM solutions or other neat tricks to come up with for finding these, however we can do some basics with powershell as well. Most Active Directory people will be familiar with the netlogon.log, and may know that there are events logged there for connections from clients that do not map into an AD site. You will also see event log messages in the System log / Netlogon Source / EventID 5807 which state that there were a number of siteless clients connecting and you can look at the netlogon.log for further details. Depending on the level of netlogon debugging that is going on, you may have a lot of noise to deal with in there. But with powershell, some filtering and manipulations, we can strip it all down to source IP's very quickly:

$uniqueIP = get-content c:\windows\debug\netlogon.log | 
? { $_ -cmatch "NO_CLIENT_SITE" } | 
% {$_ -match "\d+\.\d+\.\d+\.\d+"|out-null; $matches[0]} | 
Group-Object | Select Count,Name| Sort Name 

Here we have in the pipeline:
1) Get-content to read the file
2) ? = where. -Cmatch for case sensitive matching of NO_CLIENT_SITE.
3) % = foreach. For each matching line, we look for an IPv4 matching pattern and ignore the true/false result, and display the first matched object
4) Then we group all of these IP addresses as we will have duplications
5) Filter the results to just a count of how many occurrence and which IP is the source
6) Sort by the Name attribute. In this case Name = IP address, so we see our IP's in order which helps us see IP's that might all be in one subnet


If we don't want to get too fancy at this point, we can just visually look through our list and identify possible subnets base on how large our typical subnet blocks are allocated in our environment. We can look at the IP settings of the client remotely via WMI with my get-ipconfig script or another method. Since we may not know the actual location that the new network was deployed, sometimes we can get this from router details. If your organization has telnet open on routers, and puts location details in the banner, this is one useful way of checking. You can look at my telnet script to read these banners. Otherwise, sometimes machine naming conventions or other site specific build details can give away the site location [(nbtstat -a ) or powershell version of this netbios command]. Additionally if you run this type of check frequently, you may end up relooking at Ip's that you already defined subnets for. To get around this you can do some extra filtering in the initial powershell command to read the log. Select with the -last option can reduce your results to the last few lines. Otherwise some date matching could be done. Also you can see for what site the subnet exists in using my powershell script for this.

If you want to try grouping the original results by potential /24 bit subnets:


$uniqueip|select  Name,@{name="mask";expression={$_.name.substring(0,$_.name.lastindexof('.'))}}|group mask |
select @{name="PossibleSubnet";expression={$_.name}},@{name="UniqueIPAddr";expression = {$_.group|select -expand name}}



This will provide a guess at the subnet ID, along with all the related IP's that are in that range.