A Creative (and Easy) Way to Assign IP Subnets to AD Sites

As a consultant, I’m oftenbrought in as hired helpwhen projects or dailytasks are overwhelming theonsite IT staff. In this role, Isometimes get assigned maintenance or cleanup tasks thatinitially seem, well, boring.What can make these jobs moreinteresting is the chance to becreative in accomplishing thechore. When the solution involves writing some nifty codethat does the job in minutes,what seemed to be just anothertedious assignment turns out tobe downright satisfying. Thiswas the case when I wasrecently asked to look into aNetlogon warning that wasshowing up on all the domaincontrollers (DCs) in a fairly largecorporation. This warning wasaccompanied by spotty complaints of slow logons. Figure 1 shows the importantparts of the warning message.

This company has a homeoffice with several thousandusers and hundreds of branchoffices with hundreds of clientsat each branch. Apparently,when the company migrated toActive Directory (AD), onlysome of the IP subnets in usehad been assigned to AD sites. As event 5807 warns, not associating IP subnets to AD sitescan lead to clients at one location authenticating to a DC inanother location several IP hopsaway, even though there mightbe a DC sitting just 10 feet fromthe client. The Microsoft article“How Domain Controllers AreLocated in Windows” (http://support.microsoft.com/?kbid=247811) emphasizes the importance of having subnets associated with AD sites as a client’sprimary means of finding anoptimal DC with which to communicate.

When I looked at the netlogon.log file on one of the branchoffices’ DCs, I discovered the filewas a whopping 17MB and consisted primarily of NO_CLIENT_SITE entries, as Figure 2 shows. Closer inspection ofthis log revealed that clientsfrom the home office and clientsfrom other branches (whichhad their own local DCs) hadbeen authenticating to thisremote server. Clearly, theimportant task of associating IPsubnets to AD sites had fallenthrough the cracks during themigration to AD, and this problem needed to be fixed.

Let me walk you through thesolution I used to fix the subnetproblem. This solution involves getting the necessary subnet information, using a macro called Subnets, andusing a script named Subs2site.vbs.

Getting the Subnet Information
Fortunately, the company in questionhad records of which subnets were inuse at the various locations. Besidesneeding this information, I alsoneeded an easy way to extract subnetinformation from the netlogon.logfiles. With both sets of information, Icould use a script to associate IP subnets to AD sites.

Microsoft Excel is a perfect tool forextracting data from log files. It supports Visual Basic for Applications(VBA) through a macro-editing toolcalled Visual Basic Editor. Using theeditor’s Watch feature, you can monitor the value of any variable as youstep through the macros or scriptsthat you create with this tool. You canget explanations and examples ofcode syntax at any time by highlighting a keyword and pressing the F1 key.Visual Basic Editor is included withmost Microsoft Office programs, soyou probably already have it on hand.A separate scripting tool with thesame level of functionality as VisualBasic Editor can cost more than $100,so it’s worth getting to know this editor.

To extract the subnets from the IPaddresses in the netlogon.log files, youcan follow a simple five-step procedure:

Using the Subnets Macro
The Subnets macro, which Listing 1 shows, progresses through the list of IP addresses in Sheet1, extracts a list of unique subnets, and writes them to a column in Sheet2. You can download this macro by clicking the Download the Code Here button above. The sidebar “How the Subnets Macro Works” describes the macro’s code.

To use the Subnets macro, follow these steps:

Using Subs2site.vbs
I used Subs2site.vbs, which Listing 2 shows to import the subnets into AD. Although I could’ve written this code using Visual Basic Editor, I instead chose to adapt an existing script to save time. You can download Subs2site.vbs by clicking the Download the Code Here button above.

Subs2site.vbs is somewhat limited in that it can import subnets to only one site at a time. Thus, if the extracted subnets need to be imported to different sites, you need to group the extracted subnets by site and save the groups in separate files.

To use Subs2site.vbs, follow these steps:

Subs2site.vbs will then import the listed subnets to the specified AD site. Note that if a particular subnet already exists in that site, the On Error Resume Next statement allows the script to continue to the next subnet without causing the script to end with an error. If you have multiple sites to which you want to assign subnets, you simply repeat steps 1 through 5 for each site.

A Creative Solution
Thanks to Visual Basic Editor, I was able to be resourceful and even a little artistic in devising a solution to the subnet problem. Even better, the Subnets macro and Subs2site.vbs script let me reduce a substantial task into a handful of mouse clicks and keystrokes.