Nützliche Optionen von NLTEST

Hi, Fabian hier. Heute mal mit einem recht kurzen Artikel zu „NLTEST“.

Das Kommandozeilenprogramm „NLTEST“ führt oftmals ein Schattendasein und wird nicht weiter beachtet, außer wenn es um Fragen rund um den secure channel geht. Wie so oft filtert man die „nicht gewünschten“ Schalter, die bei dem Ausführen von „NLTEST /?“ aufgelistet werden, gewohnheitsgemäß aus.

Das Programm bietet jedoch das ein oder andere nützliche Kommando, welches einem so manche Frage schnell beantworten kann oder auch sinnvolle Aktionen ausführen kann. Daher folgt hier ein kurzer Abriß von einigen nützlichen Schaltern, die wir oftmals nutzen – ohne, daß alle NLTEST-Optionen besprochen werden sollen. „NLTEST /?“ oder auch http://technet.microsoft.com/en-us/library/cc786478.aspx zeigen weitere Schalter und Funktionen.

DNS-Aufräumvorgang:
Je nachdem wie man einen DC aus der Active Directory Umgebung entfernt, können DNS-Einträge bestehen bleiben. Im Normalfall wird der DNS-Aufräumvorgang („DNS scavenging“) – sofern aktiviert – nach einiger Zeit die Säuberung der DNS-Zone vornehmen. Der Zeitwert für die Alterung kann manuell pro Zone angepaßt werden. Bis dahin kann es jedoch zu merkwürdigen DNS Abfrageergebnissen kommen bzw. kann es andere Probleme in Bezug auf den nun nicht mehr vorhandenen DC geben. Gerade die Einträge der “_msdcs”-Zone bieten hier einen großen Fehlerpool. Auch für diverse Tests kann es sinnvoll sein, temporär die SRV-Einträge eines DCs zu entfernen.

Möchte man nun nicht manuell die Einträge eines DCs aus der “_msdcs”-Zone entfernen, nutzt man einfach das folgende NLTEST-Kommando:

C:\> nltest /DSDEREGDNS:server01.domain.tld

Damit werden die DC-spezifischen SRV-Einträge entfernt. Möchte man auch die GUID-Einträge des DCs entfernen, können weiterhin die Optionen „/DOMGUID“ bzw. „/DSAGUID“ helfen.

Möchte man die Einträge wieder registrieren, reicht ein auf dem entsprechenden DC ausgeführtes

C:\> nltest /DSREGDNS

Informationen zu Sites:
Gerade wenn Sites ohne DCs existieren, möchte (oder muß) man ab und an prüfen, wo ein DC die sogenannte „Site-Coverage“ (siehe http://technet.microsoft.com/en-us/library/cc759550.aspx) durchführt. Dabei registriert ein DC seine SRV-Einträge für eine Site, in der kein DC eingetragen bzw. vorhanden ist. Möchte man nun prüfen, welche Sites ein bestimmter DC zusätzlich mit abdeckt, setzt man folgendes Kommando ab:

C:\> nltest /DSGETSITECOV

Möchte man dann „nebenbei“ noch über die Kommandozeile herausfinden, welcher Site der DC selbst zugewiesen ist, reicht ein:

C:\> nltest /DSGETSITE

Eine Liste mit allen DCs einer Domäne und der Site, der sie zugeordnet sind, sowie einigen Zusatzinformationen liefert:

C:\> nltest /DCLIST:domain.tld

Informationen zu Domänencontrollern:
Das Kommando

C:\> nltest /DNSGETDC:domain.tld

gibt die DCs der angegebenen Domäne mit Ihren IP-Adressen zurück.

Möchte man einen Aufruf der internen Funktion “DsGetDcName” durchführen / simulieren, so wie ihn auch eine beliebige Applikation bzw. der Client selbst absenden würde, verwendet man beispielsweise:

C:\> nltest /DSGETDC:domain.tld /force

Das interessante an der Rückgabe sind die zusätzlichen Informationen, die zum DC bzw. damit indirekt auch zur DC-Wahl angegeben werden.

Zusätzliche Schalter für „DSGETDC“ und „DNSGETDC“ liefern noch weitere Optionen, um die Auswahl einzugrenzen, etwa um nur Globale Kataloge oder schreibbare DCs anzuzeigen. Dies kann neben der Ausführung auf DCs insbesondere auch für ein schnelles Troubleshooting auf den Clients sehr nützlich sein.

Clientoptionen:
Möchte man manuell ein Computerkennwort (genutzt etwa für den secure channel zwischen Client und DC) zurücksetzen, kann auf auf Memberservern oder Clients das Kommando

C:\> nltest /SC_CHANGE_PWD

eingesetzt werden.

Domänenclients führen beim Betriebssystemstart ein “discovery” nach einem für sie “geeigneten” DC aus. Nachdem dieser DC gewählt wurde und ein sicherer Kanal zu diesem DC aufgebaut wurde, versucht der Client mittels sogenannter “DC stickyness” auch diesen DC während der gesamten Session zu behalten – und damit ist nicht etwa die Logon Session eines Benutzers gemeint, sondern die Session des Betriebssystems (also etwa bis zum Neustart des Clients). Möchte man nun ein erneutes discovery des Clients erzwingen (sei es, weil es Probleme mit einem DC gibt, Site-Änderungen stattgefunden haben oder etwa DNS Prioritäten geändert wurden), kann man diesen discovery Prozess mit dem folgenden Befehl anstoßen, denn nach dem zurücksetzen des sicheren Kanals sucht sich der Client einen (ggf. neuen) DC, mit dem er für die neue Sitzung diesen sicheren Kanal aufbauen kann:

C:\> nltest /SC_RESET

Trusts:
Zu guter Letzt soll noch ein Kommando genannt werden, welches für ein Trust-Troubleshooting nützlich sein kann:

C:\> nltest /DOMAIN_TRUSTS

Hierbei werden neben den Trusts selbst auch einige Informationen zum Status bzw. den Optionen des Trusts angezeigt.

Wie angesprochen liefert NLTEST viele weitere Optionen, die man in einer ruhigen Minute einmal erkunden kann. Natürlich lassen sich die Informationen auch mit anderen Programmen (grafisch als auch auf der Kommandozeile) sammeln – einige Optionen liefert NLTEST jedoch in sehr nützlicher Form, so daß ein Blick in jedem Fall lohnt.

Hinweis: Aufgrund einiger Änderungen im AD-Bereich seit Windows Server 2008 (etwa dem RODC) ist es sinnvoll, bei vorhandenen Windows Server 2008 DCs in der Umgebung, auch die Windows Server 2008 Version von NLTEST zu verwenden, da dieses die neuen „Spezialitäten“ kennt. Das Programm ist hier auf DVD mit dabei und muß nicht über Support Tools nachinstalliert werden, wie es unter Windows Server 2003 der Fall ist. Für Vista steht NLTEST in den RSAT Tools zur Verfügung oder man kopiert sich die NLTEST.EXE von einem Windows Server 2008 System auf den Client.

Viele Grüße
Fabian