In den letzten 14 Tagen ist nur ein neues Management Pack von Microsoft veröffentlicht worden. Dies aber gleich mit mehreren Sprachpaketen. Es handelt sich Dabei um das Überwachugnspaket für den Active Directory Rights Managemetn Server 2008 (RMS) und 2008 R2.
Neue Management Packs im Zeitraum zwischen 17.07.2011 und 28.07.2011
DFS ermöglicht nicht nur eine einheitliche Sicht bzw. Einstiegspunkt auf die Dateien im Unternehmen, sondern ermöglicht auch ein transparentes Umziehen der Dateien von einem Server auf einen anderen.
Dabei wird zuerst eine Replikation zwischen alten und neuem Fileserver mittels DFSR eingerichtet. DFSR ist trotz des Namens unabhängig von DFS, d.h. hierfür müssen die Fileserver nicht als Ziel eines DFS Zweiges eingerichtet sein.
Sobald die Initiale Replikation abgeschlossen ist, kann der neue Fileserver als weiteres Ziel in den DFS eingehängt werden. Das alte Ziel kann dann entfernt werden (eventuell vorher ein vollständiges Backup auf dem neuen Fileserver abwarten?). Offene Dateien von Benutzern liegen immer noch auf dem alten Share und können erst repliziert werden, wenn sie die Dateien geschlossen oder sich abgemeldet haben. Daher sollte die Replikation erst gestoppt werden, wenn alle offenen Dateien geschlossen sind.
Eine mögliche Ergänzung ist es, den neuen Fileserver zuerst als Read-Only Replikat (erst ab Windows 2008 R2) laufen zu lassen, so wird sicher gestellt, dass nicht versehentlich auf dem neuen Fileserver Dateien gelöscht oder geändert werden und diese somit wieder zurück repliziert werden. Eine Änderung dieses Status bedeutet leider eine neue Initiale Replikation, d.h. DFSR kontrolliert erneut alle Dateien, ob sie sich in der Quelle oder im Ziel geändert haben. Dies bedeutet eine entsprechende Last und Verzögerung. Aus Erfahrung würde ich daher auf dieses Feature bei einer Migration verzichten.
Um die Initiale Replikation zu beschleunigen, kann man auch die Dateien zuerst auf einem anderen Weg übertragen. Hier bietet sich ein Backup oder Robocopy an. Dies hat den Vorteil, dass man das kopieren z.B. in der Nacht oder am Wochenende anstoßen und die volle Bandbreite nutzen kann. DFSR verwendet immer nur den gerade freien Anteil.
Eine Beschreibung wie die Initiale Replikation funktioniert ist hier zu finden:
Die passenden Kommandozeilen für Robocopy sind in diesem Artikel beschrieben:
ACHTUNG: Auf jeden Fall die aktuellste Robocopy Version (z.B. http://support.microsoft.com/kb/979808/en-us) verwenden und möglichst auf einem Windows 2008 R2 Server kopieren. Auch die aktuellsten Hotfixe für DFSR können nicht schaden (eine Liste mit aktuellen Hofixen unter http://support.microsoft.com/kb/968429/en-us).
Gerade im AD-Umfeld finde ich die Tools von Joe Richards (http://joeware.net) immer wieder großartig. Mit ihnen lassen sich durch geschickte Verkettungen sehr schnell Aufgaben lösen. Dabei ist der Ansatz ähnlich wie bei Unix, d.h. ein Tool hat ein Aufgabenspektrum (z.B. finden, ändern, löschen, …) – die Tools wiederum können über die Std-out Ausgabe gekoppelt werden. Wer also nicht immer gleich die Power Shell starten will, sollte sich diese Programm verlinken.
Ein Beispiel, um die Anzahl der Mitglieder einer Gruppe zu zählen:
adfind -f "samaccountname=GRUPPENNAME" member -list | adfind -c
AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010
Using server: dc01:389
Directory: Windows Server 2008
201 Objects returned
In Worten: Suche ein Objekt mit dem NT4-Namen GRUPPENNAME und gibt das Attribut member als Liste aus. Die Rückgabe wird erneut an adfind gegeben, das die Anzahl zählt.
Probembeschreibung: In einigen sichereren Umgebungen sollen servergespeicherte Profile beim Abmelden gelöscht werden. Nach einem Upgrade auf IE8 war dies bei einem Kunden nicht mehr der Fall. Es blieben immer Reste von Anwendungsdateien zurück. Im Speziellen fiel dabei die index.dat vom IE8 auf.
Fehleranalyse: Um der Ursache auf den Grund zu gehen, wurde das Debugging bei der Profilverarbeitung erhöht: Aktivieren des Environment Debug Loggings von Winlogon (http://support.microsoft.com/kb/221833/en-us). Die dabei im Log gefundenen Fehler wurde an Google übergeben 
Ursache: Ursache ist ein Fehler im IE8 mit einer speziellen Gruppenrichtlinieneinstellung (Hinzufügen von Trusted Domains per GPO). Das Problem ist hier beschrieben: http://support.microsoft.com/kb/974277/en-us
Der darin beschriebene Workraround mit einer manuellen Registryeinstellung wurde getestet und war erfolgreich. Folgende Einstellung muss durchgeführt werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_USE_IETLDLIST_FOR_DOMAIN_DETERMINATION]
"winlogon.exe"=dword:00000000
Diese Einstellung ist natürlich auch per GPO verteilbar.
Sometimes you have to debug group policy preferences (gpp) and don’t want to activate the debugging with another group policy.
You can simpe activate the debugging with two registry entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}]
"LogLevel"=dword:00000003
"TraceLevel"=dword:00000002
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
)
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
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…
Ich habe mal mit Wink die Installation eines W2k8 R2 DCs aufgezeichnet. Das Vorgehen ist denkbar einfach:
Und das alles in einem kurzen Film:
[video filename=/wp-content/uploads/2010/03/Core-DC-Install.swf height=800 width=600 /]
Lessons learned: Immer die Auflösung runterdrehen
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 
Ich arbeite als Systemingenieur in diversen Kundenprojekten bei der TechniData IT Service GmbH, die u.a. Standorte in Karlsruhe und Markdorf unterhält.
[...]