Immer wieder kommt es vor, dass Clients die Verzeichnisse Sysvol und Netlogon nicht erreichen können. Dieses hat zur Folge, dass Skripte und Gruppenrichtlinien nicht abgearbeitet bzw. angewendet werden. Meist kann man dann mit einer manuellen Aktualisierung diesen Umstand abschalten. Jedoch wäre eine dauerhafte Lösung deutlich besser. Auch wenn man den Debug Modus bei der Verarbeitung der GPO aktiviert findet man keine schlüssige Erklärung für Problem. Im Eventlog steht immer ein Fehler, dass LSASS einen Herunterstufungsangriff verhindert hat. Hat man es mit einem Hacker zu tun? Ist ein Anwender ein böser Junge?

Nein! Kein Panik. Die meisten Server die dieses betrifft werden als virtuelles System betrieben. Meist kommt hier die Enterpise Lösung ESX Server von VM Ware zum Einsatz. Dadurch sind dann natürlich die VM Tools in den Guest Systemen installiert. Werden die Tool mit der Option Standard installiert, dann wird auch die Option Shared Folder aktiviert. Die Funktion ist nur interessant, wenn man z.b. einen VM Server einsetzt. (ich weiß, dass man VM Server nicht produktiv einsetzt, nur ist diese Info noch nicht bei allen Admins angekommen ). Bei einem ESX Server gibt es keine Host Verzeichnisse, auf die man zugreifen kann. Über die Systemsteuerung/Software/Ändern kann man die Funktion deinstallieren und dann ist auch der Angriff aus dem Eventlog weg. Also immer brav die Tools mit benutzerdefinierten Einstellungen installieren.

 

ADMT ist ein schönes Tool. Wenn ich es mir oft genug einrede, dann glaub ich es auch bald!!!! Zur Migration von Computerkonten gehört es, dass man lokale Profile konvertiert. Bis hierher keine Probleme. Die Konvertierung führt man in der Quelldomäne durch bevor die Computerkonten wandern. Alles klar. Bei knapp 9000 Konten sicher keine Aufgabe für die GUI, also muss ein Skript her. Das Skript liest brav die Konten aus dem AD aus, erzeugt die Include Dateien. Option Datei und schreibt die Batches, um Los weise die Konten zu konvertieren und dann zu migrieren. Fertig – Go!

Error! Das angegebene Computerkonto konnte in der “Zieldomäne” nicht gefunden werden! Wie auch, ich will es ja erst migrieren. Kontrolle der Dateien keine Fehler. Hm, zu oft habe ich die Überraschung erlebt, dass es gravierende Unterschiede zwischen ADMT GUI und ADMT Skript gibt. Also das ganze mal mit der GUI gemacht. Zuerst unter Angabe der Include Datei und der Option Datei. Gleicher Fehler. Nur Option Datei – geht! Hä! Nur Include Datei – geht nicht. Ok, das Tool sucht also Streit. Es muss also einen Unterschied geben, wie der Aufruf der Computerkonten über das Tool erfolgt. Der ADMT Guide ist nicht wirklich eine große Hilfe bei der Skriptsteuerung von ADMT mit Include- und Option Datei.

Lösung:

Im Gegensatz zu allen anderen Include-Dateien benötigt die Datei für die Konvertierung von lokalen Konten einen etwas anderen Inhalt. Zeilenweise muss man das Format wie folgt wählen:

Quelldomäne\Name

Die Quelldomäne muss dabei mit dem NetBIOS Namen angegeben werden, dann klappt auch die skriptgesteuerte Konvertierung der lokalen Profile.

 

Wenn nach der Migration des Druckservers nicht alle Drucker im AD veröffentlich werden, dann müssen diese mit dem Skript prncfg.vbs aus dem Resource Kit 2003 nachträglich veröffentlicht werden. Der Aufruf des Skripts sieht folgendermaßen aus: cscript prncfg.vbs -s -b \\Server\PrinterName +published Damit das Skript ausgeführt werden kann, muss aus dem Resource Kit die prnadmin.dll registriert werden. Dieses erfolgt mit dem Kommandozeilentool regsvr32 Registrierung: Regsvr32 prnadmin.dll Ansonsten bricht das Skript mit einem Fehler ab. Dieses Phaenomen tritt auf, wenn der Druckserver eine große Menge an Druckern hostet. Bei mir waren es ca. 300 Stueck.
 

Wieder eine kleine Merkwürdigkeit, die mich doch etwas verwundert. ADMT ist ja ein beliebtes Tool für die Migration, denn dazu ist es ja gedacht. Also wollte ich das Tool seiner Bestimmung nach einsetzen und wir standen vor der Aufgabe ca. 20000 Objekte zu migrieren.

ADMT 3.1 fällt durch das Raster, weil wir keinen Server 2008 zum DC machen wollten und auch nicht dürfen. Die Version 3.0 ist ja auch kein Prima. Best Practise für ADMT ist es ja Los weise mit 100 Objekten zu arbeiten. Ok, machen wir! Um eine saubere Migration zu gewährleisten, werden die Objekte mit SID History migriert, um den Zugriff auf die andere Domäne und die Ressourcen zu ermöglichen. Bei der existierenden Vertrauensstellung wird schnell mit netdom …/quarantine:no die SID Filterung deaktiviert.

Nun kommt aber der Hammer! Um das Verfahren etwas bequemer zu machen, soll ADMT per Skript arbeiten und dazu die generierten Includ-Dateien nutzen. Allerdings kann man diesen gewählten Weg nur nutzen, wenn ADMT direkt auf dem DC installiert wird! Ist ADMT auf irgendeinem anderen System installiert (Admin Workstation), dann werden alle Objekte OHNE SID History migriert. Besser gesagt, man kann dieses Feature nicht auswählen. Wenn man bei dem gleichen System das MMC von ADMT aufruft, dann funktioniert auch die Migration mit SID History. Da es hier um eine Sruktur mit ca. 2500 Globalen Gruppen und ca 1000 OUs geht, ist dieses manuelle Verfahren ausgeschieden.Denn bei der GUI muss man jeder OU einzeln aufrufen.  Also muss ADMT auf einem DC installiert werden, damit die skriptgesteuerte Migration funktionieren kann.

Leider ist mir keine Erklärung eingefallen, warum dieses so ist.

 

Es ist wie aus dem Bilderbuch. Kaum macht man ein paar kleinere Arbeiten am System schon sind alle Fehler auf diesen Punkt zurückzuführen! Nach einen Schmeaupdate auf die Version 44 (Server 2008) tauchen im Eventlog sporadisch Fehlermeldungen auf.

Event ID: 11 Source: KCC DS_Service_Principal_Name Was bedeuten soll, dass es bei einem Server doppelt registrierte SPNs geben soll. Ok, ich konnte mir zwar nicht vorstellen was mein Schemaupdate mit dem SPN zu tun hat, aber egal: der Consultant ist immer Schuld!

Ich machte mich mit den üblichen Tools auf die Suche, um den Server zu suchen der diesen SPN doppelt hat!

Setspn –L <Server> zeigt nicht wirklich was Ok!

ldifde –f SPN.txt –t 3268 –d “DC=Domain,DC=Suffix” –l ServicePrincipalName –r “(ServicePrincipalName=*)”  -p subtree um alle Server abzufragen, auch nichts?

ADSIEdit und dort alle ServicePricipalName Einträge von Hand kontrolliert… auch ok?

Und nun die Auflösung:

Wenn man einen Server installiert und diesen von einer in die andere Domäne bringt, dann sollte man auch das Computerkonto löschen oder  wenigsten deaktivieren

Nur gut, dass der Server kundenseitig zur Verfügung gestellt (installiert) wurde