Gelegentlich verliert ein Rechner die Bindung an die Domäne. Bei der Anmeldung mit einem Benutzerkonto aus der jeweiligen Domäne erscheint dann, die Fehlermeldung sinngemäß „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“.
Ursachen
Die Gründe, warum das passiert, sind vielfältig.
Einige davon sind, z.B.:
* Asynchrone Zeit im Netzwerk.
* Wiederherstellung eines Rechners aus Backup/ Wiederherstellungspunkt.
* Rechner lange nicht mehr aktiv im Netzwerk angemeldet (Domänen-Standard 30 Tage).
* Die GPO ist aktiviert, dass die „Änderung von Computerkontenkennwörtern deaktiviert ist“ (…\Sicherheitsoptionen: Domänenmitglied: Änderungen von Computerkontenkennwörtern deaktivieren).
* AD-Probleme (prüfe mit dcdiag, repadmin).
* Geklonte Rechner auf denen kein Sysprep ausgeführt wurde.
Diese Liste ist (leider) nicht vollständig.
Falls das Problem allerdings gehäuft mit den immer gleichen Clients in kürzeren Zeiträumen auftritt, dann sollte man da energischer nachforschen.
Problem
Bei einem Kunden verloren jüngst innerhalb einer Woche mehrmals die gleichen Clients die Bindung zur Domäne.
Aus der angeführten Liste der Ursachen brachte nur „dcdiag“ einen interessanten Fehler zutage.
Der alte SBS-Server, der mittlerweile durch einen anderen DC abgelöst worden war und nur noch als Dateiserver sein Dasein fristete, war der Meinung, er sei noch Inhaber der FSMO-Rollen.
Sowohl über die GUI als auch über PowerShell liessen sich nicht alle Rollen transferieren.
Oder schlimmer. Der Transfer wurde als erfolgreich transferiert gemeldet und blieb trotzdem am alten SBS.
Lösung 1/2
Also habe ich das Ganze über ntdsutil durchgeführt.
Damit liessen sich drei der fünf Rollen dauerhaft verschieben. (Stichwort: transfer role)
Lediglich der Schema Master und der RID Master waren nicht dazu zu bewegen auf „freundlicher“ Art und Weise umzuziehen.
Daher habe ich in einem zweiten Schritt die Rollen mittels ntdsutil mit Nachdruck umgezogen. (Stichwort: seize role).
Lösung 2/2
Der SBS Server hielt sich anschliessend immer noch für einen Domänen Controller.
Da ein reguläres „dcpromo“ irgendwann mit Fehler abbrach, wurde mit etwas ruppigeren Methoden ein „dcpromo /forceremoval“ eingesetzt.
Der Vorgang lief ohne Schwierigkeiten durch.
Ein unschöner Nebeneffekt: der SBS fühlte sich nun nach dem Neustart nicht mehr als Domänenmitglied.
Der Domänenbeitritt was schnell erledigt.
Etwas aufwändiger waren die „Frickeleien“ in der Registry und im Dateisystem, damit der Server nicht alle 30 min herunterfährt, wenn die FSMo Rollen weg sind. (Stichwort: SBSCREXE.exe)
Danach hiess es warten.
Nach 4 und nach 8 Wochen habe ich dann einen PowerShell-Einzeiler laufen lassen. Dieser zeigte mir alle Rechner, die in den letzten 20 Tagen online waren und ihr Passwort geändert hatten. Da sich das nun regelmäßig änderte und kein Rechner mehr die Vertrauensstellung verlor, sehe ich das Problem als gelöst an.
