First published on TechNet on May 14, 2012
Three months ago I posted some information on AD Sites, Subnets and Roaming Clients. The heart of the blog was a PowerShell script that collected and collated netlogon.log files across all Domain Controllers in the forest to report a list of hostnames and IP addresses that have authenticated from IP addresses with no corresponding subnet defined in Active Directory. I call these roaming clients, because they randomly seek out Domain Controllers, with no sense of closeness.
In the past three months, I’ve fielded some good questions from customers about roaming clients and the PowerShell scripts. Below are some of the questions, my responses and an updated script.
Question:
Do I even need to define any subnets in Active Directory?
Answer:
There is one very specific scenario where you don’t need to define any subnets – If you have exactly one site defined in Active Directory. I’ve got some customers who have a simple Active Directory (for an extranet, for example). It has two Domain Controllers (for redundancy) in a single site (usually Default-First-SiteName). In this case you don’t need to define any subnets. All IPs will be associated with that site, and DCs will report no roaming clients in their netlogon.log files. Beware, though. If you define one subnet, you need to define all subnets.
Question:
Getting subnet information from my network team is harder than catching a greased pig. Can I just deploy a “Catch All” subnet to deal with roaming clients?
Answer:
There is a compelling case for using the “Catch All” subnet. To summarize, a “Catch All” subnet is a subnet with a broader scope, which encompasses most/all of your specific subnets. For example, if you have numerous 10.10.x/24 subnets associated with various sites, you could configure a 10.10.0.0/16 subnet and associate it with a major Hub site. So if you forget one of the 10.10.x/24 subnets, the clients will automatically be “caught” by the 10.10.0.0/16 subnet and gravitate to the hub site. So instead of roaming, these forgotten clients will gravitate to the hub site.
|
While there’s nothing wrong with a “Catch All”, I’m not a big fan. First, it hides the problem of subnet definitions. By associating roaming clients with the hub site, you will never see them logged in the netlogon.log file, so you will never be able to properly fix them. Second, while AD doesn’t have a problem with overlapping subnet definitions, some AD-Aware applications like SCCM don’t like them.
The SCCM client in a specific site, which is also covered by a “Catch All” may not be able to determine whether it belongs to the specific site or to the “Catch All” site. AD will always use the more-specific subnet definition when determining which site to which it belongs.
Question:
Since you don’t recommend a “Catch All” and there is no practical way I can keep subnet definitions up-to-date at all times, is there anything else I can do for roaming clients?
Answer:
If your AD environment spans multiple sites, and roaming clients feel the pain of not finding a “close” DC, you can/should use our Branch Office Recommendations. Specifically, you should configure “remote” domain controllers to NOT register generic SRV records. Generic SRV records are used by roaming clients (or non-AD aware clients) to discover DCs. If you configure your remote DCs to NOT register these records, they will only register site-specific SRV records. Thus, only clients in the remote site will find remote DCs. Roaming clients will not find remote DCs, and they will gravitate to hub DCs. Chapter 4 in the Branch Office Guide describes this in more detail, while KB 306602 contains a summary. The beauty of this configuration is that it addresses a number of scenarios where clients might roam, including undefined subnets, in-site DCs being unavailable, or non-site aware applications that look to DNS to discover DCs.
Question:
I’ve tried using your script to report roaming clients. However, after I add subnets to AD and re-run your script, it still reports the clients as roaming. What am I missing?
Answer:
You’re not missing anything. The script isn’t intelligent enough to distinguish between old events and new events. So it will report clients as roaming as long as there are entries in the netlogon.log, regardless of the date. The new script (FindRoamingClientsv2.ps1) is now date aware. You simply run the script and pass it the number of days in the past you would like to consider. For example, the following will only consider events in Netlogon.log from the past 5 days:
.\FindRoamingClientsV2.ps1 5
Note that you can run the script without the # of days parameter. In that case, it will go back 7 days.
Question:
Are there any other improvements to the script that you’d like to gloat talk about?
Answer:
The script now report progress better. So in large environments, you can see which DC you are currently collecting logs from. It also includes the number of the current DC and the total number of DCs, so you have an idea of how much longer it will run. I’ve run the script in environments of 200-500 DCs, across multiple continents. In those cases, it took from 2-6 hours to run.
I hope you enjoy the new script, and it helps you stay on top of AD subnet definitions.
Doug Symalla
Update (6.August.2012): Some customers informed me the script was not returning the expected data in their environments. We discovered, in some cases, the NO_CLIENT_SITE entries in the netlogon.log file contained 6 fields (columns) and in other cases it contained 5 fields (columns). The script assumes these entries will always have 6 fields, with the client name in field 5 and the IP address in field 6. Since this assumption is not valid in all cases the script has been modified to deal with either case. Specifically, instead of looking at position 5 and 6 in an array, we look for position –2 and –1 (the last and second –to-last positions). The attached script contains this update.
Update (3.April.2013): To centralize the storage of all AskPFEPlat scripts, we are now storing them on the TechNet Script Center Repository. This specific script can be found at the following location:
http://gallery.technet.microsoft.com/scriptcenter/Active-Directory-Clients-e18a81c2
Doug Symalla