Markus Bäker » Active Directory Domain Service

Massenhafte Anpassung von DHCP Optionen

markus — Tue, 01 Jun 2010 17:25:25 +0000

Möchte man auf die schnelle bei einem Windows 2008 DHCP Server in jedem Scope DHCP Options anpassen, so lässt sich dies mit ein paar Zeilen Batchcode erledigen:

for /f "usebackq skip=4" %%a in (`netsh dhcp server \\DHCPSERVER show scope`) do (

netsh dhcp server \\DHCPSERVER scope %%a set optionvalue 006 IPADDRESS ip.des.dns.servers ip.des.zweiten.dns

netsh dhcp server \\DHCPSERVER scope %%a set optionvalue 015 STRING dns.name

)

DC isolieren bei Schema Update?

markus — Mon, 10 May 2010 18:00:17 +0000

Ich habs nie gemacht und auch nicht für sinnvoll gehalten (oder war ich nur zu faul?).

Jetzt gibt es dazu eine konkrete Aussage von Microsoft:

Is there a way to isolate a DC in order to do an AD Schema upgrade? I cannot find any documentation on how to do this.

Answer

Isolating the Schema Master for ADPREP /FORESTPREP is unsupported (i.e. "not tested by the Product Group") and not recommended*; we intentionally try to block you from this scenario starting in Win2003 SP1.

Quelle und Begründung: Dritte Frage auf http://blogs.technet.com/askds/archive/2010/04/16/friday-mail-sack-i-live-again-edition.aspx

Versteckte Windows Features Part IV

markus — Tue, 06 Apr 2010 18:30:48 +0000

Migriert man einen Druckserver in eine neue Domäne, so gibt es häufig Probleme mit dem Publizieren der Drucker im Active Directory (ADS). Bei einzelnen Druckern hilft es den Hacken im AD veröffentlich zu entfernen, übernehmen und wieder zu setzen. Gerade bei vielen Druckern macht dies natürlichen keinen Spaß. Und IT soll ja Spaß machen

Daher hat Microsoft auch hier eine Komandozeilenalternative bereitgestellt: setprinter

Den Status der Veröffentlichung (unpublished, published oder published pending) kann man mittels setprinter -show \\druckservername 7 anzeigen lassen.

Um das Publizieren aller Drucker eines Druckservers zu erzwingen, bietet sich der Befehl setprinter \\druckservername 7 “dwAction=publish” an.

Die Ausgabe sieht dann wie folgt aus:

Und wo findet man das Tool? Im Resourcekit…

Flash: Wie installiere ich einen Windows 2008 R2 Core Domänen Controller

markus — Sat, 13 Mar 2010 18:41:24 +0000

Ich habe mal mit Wink die Installation eines W2k8 R2 DCs aufgezeichnet. Das Vorgehen ist denkbar einfach:

W2k8 R2 Core installieren (von DVD booten)
Mittels sconfig.cmd den Rechner umbenennen
Eine unattend.ini erstellen. Details dazu unter http://support.microsoft.com/kb/947034 (Ergänzung Forest/Domainlevel 4 ist Windows 2008 R2)
In der unattend.ini muss das recovery Passwort hinterlegt werden (im Flash mittels * dargestellt, muss aber eine höhere Komplexität haben)
dcpromo /unattend:unattend.ini aufrufen
Neustarten

Und das alles in einem kurzen Film:
Flash: Wie installiere ich einen Windows 2008 R2 Core Domänen Controller
Lessons learned: Immer die Auflösung runterdrehen

ADDS: Nicht suchen, sondern finden!

markus — Tue, 23 Feb 2010 21:00:08 +0000

Mir begegnen regelmäßig Situationen, in dem im ADDS und Eventlog bestimmte Dinge nachgeschaut werden müssen. Dabei gehen viele direkt ins Eventlog und suchen nach dem Namen des gesperrten Users oder ähnliches. Gerade in größeren Umgebungen ist diese Vorgehensweise sehr ineffizient und auch nicht präzise, da andere Ereignisse die Suchergebnisse beeinträchtigen können.

Daher sollte die Devise sein: Zuerst Zeitpunkt und Ort herausfinden und dann im Eventlog nachschauen.

Solange am Objekt nichts geändert wurde, ist der letzte Änderungszeitpunkt und Ort eigenschaftsgenau kontrollierbar.

Dazu ein kleines Beispiel: Ein Anwender beschwert sich, dass sein Konto ständig gesperrt wird. Er hat vor einigen Stunden sein Kennwort geändert.

Bevor das Konto zurückgesetzt wird, werden noch schnell wichtige Eigenschaften mittels repadmin extrahiert:

repadmin /showobjmeta * "CN=User1,OU=Benutzer,,DC=temp,DC=local" > user.txt

Dabei werden die Metadaten des per DN angegebenen Objektes (CN=…) auf allen Domänenkontrollern (*) ausgelesen und in eine Textdatei gespeichert.

In der Textdatei steht jetzt pro Domänencontroller eine Liste aller Attribute des Objektes und weitere wesentliche Parameter. Für dieses Beispiel relevant ist die LockoutTime:

153243532 Standardname-des-ersten-Standorts\dc1 1100175 2010-11-23 11:11:11 37 lockoutTime

Dieser Eintrag zeigt deutlich, dass das Attribut lockoutTime (also wann das Konto gesperrt wurde) auf dem Domänencontroller dc1 um 11:11 geändert wurde.

Somit kann man direkt diese Daten nutzen und ins Securitylog vom dc1 um 11:11 schauen.

Ereignistyp:    Fehlerüberw.

Ereignisquelle: Security

Ereigniskategorie:      (9)

Ereigniskennung:        675

Datum:          23.11.2010

Zeit:           11:11:11

Benutzer:               NT-AUTORITÄT\SYSTEM

Computer:       dc1

Beschreibung:

Fehlgeschlagene Vorbestätigung:

         Benutzername:   user1

         Benutzerkennung:                TEMP\user1

         Dienstname:     krbtgt/TEMP.LOCAL

         Vorauthentifizierungstyp:       0×2

         Fehlercode:     0×18

         Clientadresse: 192.2.0.10

Die Sperrung ging als vom Client 192.2.0.10 aus. Eine Rückfrage beim User ergibt direkt, dass er das Kennwort an einem anderen Client geändert hat, aber an dem oben angegebenen Client schon länger angemeldet ist.

Aufwand: 5 Minuten. Wilde Sucherei: Minimal. Präzision: Hoch