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 https://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 https://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

Comments

• Anonymous
  January 01, 2003
  Hallo Nick, ich hoffe, daß wir nicht aneinander vorbeireden - aber den "DC locator cache zu löschen" ist nicht gleichbedeutend mit "den sicheren Kanal zurückzusetzen". Dieser bleibt während einer Session (sollten alle dafür notwendigen Faktoren stimmen) bestehen. Viele Grüße Fabian

• Anonymous
  January 01, 2003
  Hallo Fabian, eine Frage zu dem Thema "Secure Channel": Der Client baut beim Start einen SecChannel zu einem DC auf und cacht den Eintrag. In meinem Verständnis wird dies durch den DC Locator Prozess durchgeführt. Demzufolge müsste "sc_reset:domain" und "/DSGETDC:domain /force" doch das gleiche Ergebnis liefern. Bei meinem Test zeigt sich, dass das nicht so ist. Gruß   Nick

• Anonymous
  January 01, 2003
  Hallo Fabian, sorry, es war wohl nicht klar genug: es geht mir um den Unterschied zwischen "sc_reset" und "dsgetdc". Mein Test in Kurzform:

1. "sc_query" => Trusted DC: DC1
2. "dsgetdc /force" => DC: DC2
3. "sc_query" => Trusted DC: DC1 ? sollte jetzt doch DC2 sein ?
4. "sc_reset" => Trusted DC: DC3
5. "sc_query" => Trusted DC: DC3 Gruß   Nick

• Anonymous
  January 01, 2003
  Hi Nick, wie hast Du das Vorgehen denn getestet? Unter Umständen wurde schlichtweg der selbe DC nach dem SC_RESET verwendet wie davor? Grundsätzlich wird bei einem SC_RESET der DC Locator neu initiiert, von daher findet die Auswahl eines DCs nach den bekannten Faktoren statt (site-specific records, DNS priorities, DNS weights etc.). Testweise kannst Du auch einen konkreten DC bestimmen, der bei einem NLTEST /SC_RESET zum Aufbau des secure channel verwendet werden soll. Dazu nutzt Du folgendes Kommando: NLTEST /SC_RESET:DOMAINDC_NAME . Wenn es hier Probleme gibt, kannst Du mit einem Netzwerktrace + Netlogon.log prüfen, woran es liegt. Viele Grüße
  Fabian

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Hallo Nick, Dein Test sieht doch gut aus - DNS round robin funktioniert und Du hast eine Lastverteilung auf die verschiedenen DCs. Ein DSGETDC erneuert nicht den sicheren Kanal - es macht lediglich einen API-Call, der z.B. auch durch das Zurücksetzen des secure channels durchgeführt werden würde. Es ändert aber nichts am bestehenden secure channel und damit auch nichts am LOGONSERVER etc. Viele Grüße
  Fabian

• Anonymous
  July 06, 2009
  Hallo Nick, ein DSGETDC Cache Reset hat für den Netlogon SC keine direkte Auswirkung, erst bei der nächsten DC discovery. Zudem macht SC_RESET selbst auch wieder ein DSGETDC /FORCE. Daher bringt ein vorangestelltes DSGETDC /FORCE nicht wirklich etwas, man kann dadurch den DC für SC_RESET nicht beeinflussen. Umgekehrt kann am aber feststellen, daß SC_RESET den Cache von DSGETDC verändert haben kann. Grüße, Roland