Wenn es nach der gestrigen intensiven Google-Suche meinerseits geht, ist das gestern aufgetretene (berufliche) Problem bei einem Kunden mehr als selten. Informationen hierzu waren spärlich, wenn nicht sogar armseelig. Anscheinend taucht es niemals auf – obwohl es das tut. Was war passiert? Ich versuch es so ausführlich wie möglich, aber bedenkt – ich mach es aus dem Kopf, da ich die Fehlermeldungen nicht mehr vorliegen habe.
Die genauen Hintergründe sind mir selbst verborgen. Anfangs lag der Verdacht auf ein fehlerhaftes Update eines Antiviren-Programmes, welches ich aber nach erster Recherche beim Kunden vor Ort ausschließen konnte. Nach Start des Servers (hier ein MS 2003 Server Standard), war eine Anmeldung nicht möglich, da ein Fehler im Verzeichnisdienst (Active Directory) aufgetreten ist. Um es mit einfachen Worten zu sagen, die Active Directory Informationen waren im Anus.
Im Verzeichnisdienstwiederherstellungsmodus war es mir nicht möglich die ntds.dit-Datei (welche die AD-Informationen beinhaltet) mit den üblichen Tools, wie ntdsutil oder esentutl zu reparieren. Ich hatte an dieser Stelle fast aufgegeben, da eine aktuelle Sicherung nicht vorhanden war. Der Server pfiff eh schon auf dem letzten Loch und die Datensicherung war genauso zuverlässig und glaubwürdig, wie Backsteine in der Luft schweben können.
Die Betonung lag hier auf “aktuelle” Sicherung. Ich hatte noch Zugriff auf eine Sicherung von 2006. Also relativ zeitnah möchte ich anmerken. Aus dieser holte ich im Modus Verzeichnisdienstwiederherstellung die ntds.dit und überschrieb die Originale (nach händischer Sicherung) im Ordner C:\WINDOWS\NTDS. Die Prüfungsmechanismen mittels ntdsutil verliefen fehlerfrei und ich startete den Server durch. Ich konnte mich daraufhin anmelden aber das nächste Problem folgte – der DNS Server. Es handelte sich um eine AD mit integriertem DNS und die rückgesicherte ntds.dit war einfach viel zu alt, sodass der DNS Server dies nicht akzeptierte. Ich konnte den DNS Server nicht konfigurieren oder eine neue Zone erstellen – beides wurde mit einer Meldung in der Art “konnte nicht in Active Directory (null) schreiben”. Ebenso war es mir nicht möglich, mit den mir verständlichen Mitteln den DNS Server zu deinstallieren und blanko zu installieren. Es schlug jeder Eingriff fehl.
Somit konnten auch die Clients keine Namensauflösung mehr machen, geschweige denn sich an der Domäne anmelden. Intern, wie auch extern war der Zugriff auf DNS-Namen nicht möglich. Ein Glück, dass der Kunde mittels HTTP-Proxy surfte. Zumindest war der Server via \\IP-Adresse erreichbar. Eine Konstellation, die dem Kunden “erst einmal ausreichte”. Ich versprach mich darum zu kümmern, denn völlig mich einer Neuinstallation hingeben lag mir fern. Ich recherchierte gestern über 5 Stunden zu Hause und stieß auf den für mich letzten besaglichen Strohhalm.
Heute beim Kunden angekommen, habe ich das auch gleich umgesetzt, Daumen gedrückt, weggesehen und … es lief! Einzig allein die wenigen Arbeitsstationen musste ich aus der “alten” Domäne austreten und in die “neue” Domäne eintreten lassen und alles funktionierte, wie es sollte. Und für alle die, die ungeduldig warten, was ich getan habe, hier eine “Kurzanleitung” am Hauptserver (DC+DNS).
- Deinstallation des DNS-Servers (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
- Löschen (vorher sicherheitshalber sichern) der Dateien netlogon.dns und netlogon.dnb (hier unter C:\WINDOWS\SYSTEM32\CONFIG)
- Löschen (vorher sichern) des kompletten Ordners DNS (unter C:\WINDOWS\SYSTEM32)
- wenn noch nicht vorhanden, die Support Tools von M$ installieren
- CMD starten und folgenden Befehl eingeben (vom Support Tools Installationspfad aus): netdom resetpwd /server:SERVERNAME /userd:SERVERNAME\Administrator /passwordd:*
- es wird nun nach dem Kennwort gefragt: hier kann einfach das alte Administratorkennwort eingegeben werden
- DNS Server installieren (Systemsteuerung->Software->Windowskomponenten hinzufügen/entfernen)
- Sicherstellen, dass die oben entfernten Dateien und Ordner wieder erzeugt wurden
- CMD starten und netdiag /fix ausführen
- Restarbeiten (Aus- & Eintritt der Client-PCs in die Domäne)
- Feierabend machen
Mindestens durch die alte ntds.dit Datei, wenn nicht durch einen Fehler in der DNS Konfiguration oder anderen Ursachen, wurde das Kerberos-Passwort des Administrators zurückgesetzt. Mittels netdom wird dieses “aufgefrischt” und dann sollten in dieser Hinsicht diese Probleme beseitigt sein.
Hoffe es hilft Einem – dem Kunden für sein Geschäft und mir für das “Wissen” auf jeden Fall.
Ich dachte ich guck nicht richtig, als ich das links stehende Bild in meinem Browser erblicken musste. Wie kommt es, dass T-Online bzw. Telekom meine HTTP-Anfragen und ergo die zugrunde liegenden DNS Abfragen manipuliert, ohne eine AGB-Änderung anzumelden bzw. den Kunden (respektive mich) zu kontaktieren. Ich finde das eine derbe Frechheit das Ganze noch als “Feature” zu verkaufen.
Und dann muss ich persönlich auch noch aktiv werden, damit ich das Ganze abschalten kann. Netterweise haben die ja auf deren “Oops – Seite nicht gefunden”-Seite ja einen Link in das Kundencenter, um die “geile” T-Online Navigationshilfe abschalten zu können.