AD Sites and Services: NLTEST /DSAddressToSite

Who knows all functions of NLTEST? In answer to this question, not a lot of people would say “yes”. After the triumph of Powershell, some other nice tools were simply forgotten. A lively discussion led me to remember a small hidden, but very useful function of NLTEST: The resolution of an IP address to an AD site 

Log-on takes too long

There were complaints about long log-on times to the Active Directory domain at a customer. One reason for that could be an inconveniently selected domain controller. The selection of an appropriate domain controller is done, among other things, via the assignment of the IP address of the client to an Active Directory site. This, in turn, is assigned to a domain controller.

In case an Active Directory site cannot be determined for a client IP address, a random domain controller is selected from the “general records” in the DNS. In the default configuration, all domain controllers of the domain are entered there. Hence, a client from a not-registered sub-network in America can select a domain controller from Singapore for authentication (and this definitely does not improve performance).

This leads to the question:

Is the IP address of the client assigned to an Active Directory site?

Two frequently used solutions for identifying an AD site are “gpresult /r” or “NLTEST /dsgetsite“. But these commands have to be run locally on the computer in question. This leads to unnecessary time-consuming interaction with the helpdesk and delays trouble shooting.

The less well known NLTEST parameter /DSADDRESSTOSITE manages that task on any computer belonging to the respective Active Directory domain.

This is what it looks like:

NLTEST /DSADDRESSTOSITE:<IP address>

The example shows you how to check if the IP address 10.10.10.100 is assigned to the Active Directory site “DEFRA” using the NLTEST command. However, it leaves open whether the client is located in Frankfurt or not ;).

If it is not assigned to “DEFRA” it will look like that: