DNS-Namensauflösung schlägt fehl: vom Client über den Resolver bis in die Zone
Warum nslookup und Resolve-DnsName Verschiedenes zeigen, woran du einen veralteten Eintrag erkennst und an welcher Stelle die Suche wirklich beginnt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ping geht, die Anwendung nicht
Die Meldung, mit der ein solcher Vorfall anfängt, ist fast nie präzise. Ein Laufwerk verbindet sich nicht mehr, eine Anwendung meldet, der Server sei nicht erreichbar, oder ein Anmeldevorgang dauert plötzlich eine Minute statt zwei Sekunden. Dass DNS dahintersteckt, stellt sich meist erst heraus, nachdem jemand die IP-Adresse direkt ausprobiert hat und es damit funktioniert. Von diesem Punkt an beginnt die eigentliche Arbeit, und sie geht schief, wenn man einfach anfängt, Dinge auszuprobieren.
Der häufigste Irrweg führt über nslookup. Das Werkzeug fragt den DNS-Server direkt und antwortet mit dem, was in der Zone steht. Der Client aber, der das Problem hat, geht einen anderen Weg: Er sieht zuerst in seinem eigenen Cache nach, in den auch Einträge aus der hosts-Datei geladen werden, und er kann im Rückfall Antworten aus LLMNR oder NetBIOS annehmen, die gar nicht vom DNS-Server stammen. Genau deshalb kann nslookup ein sauberes Ergebnis liefern, während die Anwendung auf demselben Rechner an derselben Stelle scheitert.
Die zweite Falle ist der Cache, und zwar auf beiden Seiten. Der Client merkt sich Antworten für die Gültigkeitsdauer des Eintrags, der DNS-Server merkt sich die Antworten, die er selbst von außen geholt hat. Wenn ihr also eine Adresse ändert und danach messt, ob der Fehler weg ist, messt ihr unter Umständen nur, wie alt der jeweilige Cache ist. Eine Fehlersuche, die diese beiden Schichten nicht auseinanderhält, führt zu Ergebnissen, die sich nicht reproduzieren lassen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Sechs Fehlerbilder und was wirklich dahintersteckt
Die folgenden Fälle decken den größten Teil dessen ab, was in einem Windows-Netz als Namensauflösungsproblem gemeldet wird. Jeder Fall beginnt mit dem Bild, das die Meldung erzeugt, und endet mit dem Weg, der die Ursache belegt.
Symptom
Ein einzelner Arbeitsplatz erreicht interne Server nicht mehr, alle anderen im selben Netz funktionieren. Der Ping auf die IP-Adresse geht durch, der Ping auf den Namen nicht.
Ursache
Am Adapter dieses Rechners stehen die falschen DNS-Server. Das passiert, wenn jemand für einen Test einen öffentlichen Resolver eingetragen und danach vergessen hat, oder wenn ein zweiter Adapter aktiv ist, etwa eine VPN-Verbindung oder ein virtueller Switch, dessen Einträge Vorrang bekommen. Ein öffentlicher Resolver kennt eure interne Zone nicht und antwortet deshalb mit einem negativen Ergebnis, nicht mit einem Fehler.
Lösung
Mit Get-DnsClientServerAddress alle Adapter auflisten, nicht nur den aktiven, und mit Get-NetIPInterface die Metrik dazu ansehen, denn sie bestimmt die Reihenfolge. Interne Zonen gehören ausschließlich auf interne Server. Steht dort ein öffentlicher Resolver, entfernst du ihn und setzt den Adapter zurück auf den Bezug über DHCP, damit die Einstellung nicht beim nächsten Mal wieder abweicht. Zum Gegenprüfen reicht Resolve-DnsName -Server mit der Adresse eures internen Servers.
Symptom
Ein Name löst auf eine Adresse auf, die es seit dem Umzug des Servers nicht mehr gibt. Auf manchen Rechnern stimmt die Adresse, auf anderen nicht, und nach einiger Zeit dreht sich das Bild.
Ursache
Ein veralteter Eintrag, und zwar auf einer von drei Ebenen: im Cache des Clients, im Cache des DNS-Servers oder als Datensatz in der Zone selbst. Der dritte Fall ist der hartnäckigste. Er entsteht, wenn ein Server seine Adresse wechselt, der alte Eintrag aber bestehen bleibt, weil die Zone keine Alterung eingeschaltet hat oder weil der Datensatz statisch angelegt wurde und deshalb den Zeitstempel 0 trägt.
Lösung
In dieser Reihenfolge vorgehen: ipconfig /displaydns auf dem Client, dann Resolve-DnsName mit und ohne -CacheOnly, dann dieselbe Abfrage mit -Server gegen jeden internen DNS-Server. Bleibt die falsche Adresse auf dem Server bestehen, siehst du in der DNS-Konsole unter Ansicht und Erweitert den Zeitstempel des Datensatzes. Steht dort 0, wird dieser Eintrag nie abgeräumt und muss von Hand entfernt werden. Für die Zukunft hilft Alterung und Aufräumen auf der Zone, aber vorsichtig eingeführt, weil dabei gelöscht wird.
Symptom
Der Kurzname funktioniert, der vollständige Name nicht, oder umgekehrt. Manche Anwendungen finden den Server, andere melden ihn als unbekannt.
Ursache
Kurznamen sind für DNS keine Namen, sondern eine Aufgabe für den Client. Er hängt die Suffixe aus seiner Suchliste an und probiert die entstehenden vollständigen Namen der Reihe nach. Scheitert das, greifen die Rückfallwege LLMNR und NetBIOS, die im selben Netzsegment eine Antwort liefern können, ohne dass DNS je gefragt wurde. Anwendungen, die den vollständigen Namen verlangen, gehen diesen Weg nicht mit und melden deshalb einen Fehler, während der Ping funktioniert.
Lösung
Beide Varianten gezielt gegenprüfen: Resolve-DnsName mit dem Kurznamen und einmal mit dem vollständigen Namen, jeweils zusätzlich mit -DnsOnly, damit LLMNR und NetBIOS ausgeschlossen sind. Zeigt sich, dass der Kurzname nur über den Rückfall funktioniert, gehört er entweder als Eintrag in die passende Zone oder das fehlende Suffix in die Suchliste der Clients. Für die wenigen unternehmensweit gültigen Kurznamen ist die GlobalNames-Zone der von Microsoft vorgesehene Weg, mit statischen CNAME-Einträgen.
Symptom
Interne Namen lösen sauber auf, externe Namen nicht oder nur sehr langsam. Betroffen sind alle Clients gleichzeitig, und der Zeitpunkt fällt mit einer Änderung an der Firewall zusammen.
Ursache
Der interne DNS-Server beantwortet Anfragen für eure eigenen Zonen aus eigener Kraft. Für alles andere muss er entweder selbst rekursiv auflösen, wofür er die Root-Server erreichen können muss, oder die Frage an eine Weiterleitung abgeben. Wird der ausgehende Verkehr auf Port 53 gesperrt oder fällt die eingetragene Weiterleitung aus, kippt genau dieser Teil weg. Der Zeitablauf, bis der Server aufgibt, ist die Erklärung für die Verzögerung.
Lösung
Auf dem DNS-Server selbst prüfen, ob die eingetragenen Weiterleitungen erreichbar sind, und die Abfrage von dort aus wiederholen. Get-DnsServerForwarder zeigt die Konfiguration, eine Abfrage mit Resolve-DnsName -Server gegen die Weiterleitung zeigt, ob sie antwortet. Danach den Cache des Servers mit Clear-DnsServerCache leeren, weil dort sonst negative Antworten aus der Störungszeit stehen bleiben und den Erfolg der Reparatur verdecken.
Symptom
Anmeldungen dauern lange, Gruppenrichtlinien werden nicht angewendet, in den Protokollen tauchen Replikationsfehler auf. Der Ping auf den Domain Controller funktioniert dabei problemlos.
Ursache
Domänenanmeldung, Richtlinien und Replikation suchen ihre Ziele nicht über Hostnamen, sondern über SRV-Einträge unterhalb von _msdcs. Diese Einträge werden vom Domain Controller selbst registriert. Zeigt ein Domain Controller in seinen eigenen Netzwerkeinstellungen auf einen DNS-Server, der die Zone nicht kennt, oder wurde ein alter Controller nicht sauber entfernt, bleiben dort Einträge stehen, die ins Leere führen. Der reine Hostname löst währenddessen weiterhin korrekt auf, weshalb die Ursache lange unentdeckt bleibt.
Lösung
Die Diensteinträge gezielt abfragen, etwa mit Resolve-DnsName -Type SRV für _ldap._tcp.dc._msdcs gefolgt von eurem Domänennamen, und die zurückgegebenen Ziele mit der Liste der tatsächlich vorhandenen Domain Controller abgleichen. Zusätzlich prüfen, welchen DNS-Server jeder Domain Controller selbst eingetragen hat. Für eine umfassende Prüfung ist dcdiag mit dem DNS-Test das passende Werkzeug, weil es genau diese Abhängigkeiten zusammen auswertet.
Symptom
Die Auflösung funktioniert, aber sie ist mal sofort da und mal erst nach mehreren Sekunden. Ein Muster ist nicht erkennbar, und der Fehler lässt sich nicht gezielt herbeiführen.
Ursache
Von den mehreren eingetragenen DNS-Servern antwortet einer nicht mehr oder nur unzuverlässig. Der Client fragt zuerst den ersten in seiner Liste und wechselt erst nach Ablauf einer Wartezeit zum nächsten. Ob du in die Verzögerung läufst, hängt davon ab, ob die Antwort noch im Cache liegt. Genau daher kommt das sprunghafte Bild. Dieselbe Wirkung entsteht, wenn ein Server zwar antwortet, aber für die gefragte Zone keine Daten mehr hat, etwa nach einer misslungenen Replikation.
Lösung
Dieselbe Abfrage nacheinander mit Resolve-DnsName -Server gegen jeden einzelnen eingetragenen Server richten und die Antwortzeiten vergleichen. Der Schalter -QuickTimeout kürzt die Wartezeit ab und macht einen ausgefallenen Server sofort sichtbar, statt die Abfrage hängen zu lassen. Fällt ein Server auf, prüfst du dort, ob der DNS-Dienst läuft und ob die Zone geladen ist, denn ein Server ohne geladene Zone antwortet mit einem negativen Ergebnis statt mit einem Fehler.
Fünf Fragen, und der Fehler liegt auf einer Schicht
- 01 Wen fragt der Client überhaupt? Reihenfolge und Vollständigkeit der eingetragenen Server.
- 02 Kommt die Antwort aus dem Cache? Vergleich mit und ohne -CacheOnly.
- 03 Kommt sie überhaupt über DNS? Gegenprobe mit -DnsOnly und -NoHostsFile.
- 04 Antworten alle Server gleich? Dieselbe Frage einzeln an jeden Server richten.
- 05 Geht es um einen Kurznamen? Dann zählt die Suffix-Suchliste und nicht die Zone.
Die Reihenfolge, die dich zuverlässig zur Ursache führt
Statt Vermutungen abzuarbeiten, gehst du dieselben Schichten durch, die auch der Client durchläuft. Fünf bis sieben gezielte Abfragen reichen fast immer, um den Fehler auf eine Schicht einzugrenzen.
Erst feststellen, wen der Client überhaupt fragt
Bevor du irgendetwas an Zonen anfasst, prüfst du mit Get-DnsClientServerAddress oder ipconfig /all, welche DNS-Server am betroffenen Adapter eingetragen sind und in welcher Reihenfolge. In einer Domäne gehören dort ausschließlich die internen Server hin. Ein öffentlicher Resolver als zweiter Eintrag ist einer der häufigsten Funde und erzeugt genau das sprunghafte Verhalten, das eine Fehlersuche so mühsam macht.
Den Cache des Clients aus dem Weg räumen
Mit ipconfig /displaydns siehst du, was der Client gerade glaubt, und mit ipconfig /flushdns wirfst du es weg. Für einen gezielten Vergleich ist Resolve-DnsName das bessere Werkzeug: Mit -CacheOnly fragst du ausschließlich den Cache, ohne den Schalter geht die Anfrage den vollen Weg. Der Unterschied zwischen beiden Antworten sagt dir sofort, ob der Cache die Ursache ist.
Die Rückfallwege ausdrücklich abschalten
Resolve-DnsName -DnsOnly stellt sicher, dass nur das DNS-Protokoll benutzt wird und weder LLMNR noch NetBIOS zum Einsatz kommen. Mit -NoHostsFile überspringst du zusätzlich die hosts-Datei. Wenn eine Abfrage mit diesen Schaltern scheitert und ohne sie funktioniert, hast du die Antwort: Der Name wird gar nicht über DNS aufgelöst, sondern über einen Rückfallweg, auf den du dich nicht verlassen kannst.
Jeden DNS-Server einzeln befragen
Mit Resolve-DnsName -Server richtest du dieselbe Frage nacheinander an jeden eingetragenen Server. Antwortet einer anders als die übrigen, liegt entweder ein Replikationsproblem vor oder auf diesem Server steht noch ein alter Eintrag. Antwortet einer gar nicht, erklärt das die sporadischen Verzögerungen, denn der Client wartet in diesem Fall auf einen Zeitablauf, bevor er den nächsten Server fragt.
Zwischen Zonendaten und Cache des Servers unterscheiden
Auf dem DNS-Server selbst gibt es zwei Quellen: die Zone, für die er zuständig ist, und den Cache mit Antworten, die er von woanders geholt hat. Get-DnsServerResourceRecord zeigt dir die erste, Get-DnsServerCache und Clear-DnsServerCache betreffen die zweite. Für einen internen Namen ist der Cache irrelevant, für einen externen Namen ist er oft die ganze Erklärung.
Kurznamen getrennt vom vollständigen Namen prüfen
Ein einzelnes Wort ohne Punkt ist für DNS kein vollständiger Name. Der Client hängt die Suffixe aus seiner Suchliste an und probiert der Reihe nach. Prüfe deshalb immer beides: den Kurznamen und den vollständig ausgeschriebenen Namen. Wenn nur der Kurzname scheitert, liegt der Fehler in der Suffixkonfiguration und nicht in der Zone.
Bei Anmelde- und Richtlinienproblemen die Diensteinträge abfragen
Domänenanmeldung, Gruppenrichtlinien und Replikation finden ihre Ziele nicht über Hostnamen, sondern über SRV-Einträge unterhalb von _msdcs. Mit Resolve-DnsName -Type SRV fragst du diese Einträge gezielt ab. Fehlen sie oder zeigen sie auf einen Server, den es nicht mehr gibt, ist das Fehlerbild bunt und der Ping auf den Dateiserver trotzdem erfolgreich.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Reihenfolge, in der Windows einen Namen auflöst
Wenn eine Anwendung unter Windows nach einem Namen fragt, landet die Frage beim DNS-Client-Dienst, und der arbeitet mehrere Quellen ab. Zuerst kommt sein eigener Cache, in den beim Start auch die Einträge aus der hosts-Datei geladen werden. Ein Eintrag in dieser Datei verhält sich deshalb wie eine Antwort aus dem Cache und lässt sich mit ipconfig /displaydns sichtbar machen. Erst wenn dort nichts steht, gehen Anfragen an die eingetragenen DNS-Server, und zwar in der Reihenfolge, die sich aus den Adaptern und ihren Metriken ergibt.
Handelt es sich um einen Kurznamen ohne Punkt, kommt vorher noch ein Schritt dazu. Der Client hängt die Suffixe aus seiner Suchliste an und fragt die dabei entstehenden vollständigen Namen der Reihe nach ab. Die Suchliste stammt aus dem primären DNS-Suffix des Rechners, aus den verbindungsbezogenen Suffixen der Adapter oder aus einer per Gruppenrichtlinie gesetzten Liste. Das ist der Grund, warum ein Kurzname auf zwei Rechnern im selben Netz unterschiedlich reagieren kann, obwohl beide dieselben DNS-Server benutzen.
Bleibt auch das ohne Ergebnis, greifen die Rückfallwege. LLMNR fragt per Multicast im lokalen Segment, NetBIOS über TCP/IP per Broadcast oder über einen WINS-Server. Diese Wege liefern Antworten, ohne dass ein DNS-Server beteiligt war, und sie sind der Grund für viele Fehlerbilder, die sich nicht reproduzieren lassen. Für die Fehlersuche gibt es dafür einen sehr nützlichen Schalter: Resolve-DnsName -DnsOnly löst ausdrücklich nur über das DNS-Protokoll auf und stellt weder LLMNR- noch NetBIOS-Anfragen. Was damit scheitert, hat in einem sauber aufgeräumten Netz auch vorher nicht über DNS funktioniert.
Warum nslookup und Resolve-DnsName Verschiedenes zeigen
nslookup ist ein Werkzeug, das den DNS-Server direkt anspricht. Es benutzt nicht den DNS-Client-Dienst von Windows, sondern baut seine Anfrage selbst und schickt sie an den Server. Der Cache des Clients, die hosts-Datei und die Rückfallwege spielen dabei keine Rolle. Genau das macht nslookup nützlich, wenn du wissen willst, was in der Zone steht, und irreführend, wenn du wissen willst, warum ein bestimmter Rechner ein Problem hat.
Resolve-DnsName geht standardmäßig den Weg, den auch eine Anwendung geht, und lässt sich über Schalter genau einschränken. Mit -CacheOnly wird ausschließlich der lokale Cache befragt, mit -DnsOnly ausschließlich das DNS-Protokoll, mit -NoHostsFile wird die hosts-Datei übersprungen, und mit -Server richtest du die Frage an einen bestimmten Server. Diese vier Schalter zusammen ergeben ein Vorgehen, mit dem du die Schichten einzeln ansprichst, statt sie alle gleichzeitig zu bewegen.
In der Praxis lohnt es sich, die Gegenprobe immer paarweise zu machen: einmal mit dem Schalter, einmal ohne. Der Unterschied zwischen beiden Antworten ist die eigentliche Information. Sind sie gleich, ist die betreffende Schicht nicht die Ursache, und du kannst sie abhaken. Sind sie verschieden, hast du gefunden, wonach du suchst, und musst nicht weiter raten. Damit lässt sich ein Fehlerbild, das sich vorher nicht fassen ließ, in wenigen Minuten auf eine Schicht zurückführen.
Wie veraltete Einträge entstehen und was Aufräumen kostet
Windows-Clients tragen sich selbst in DNS ein und erneuern diesen Eintrag regelmäßig. Solange ein Rechner läuft, ist das unauffällig. Interessant wird es, wenn ein Rechner ausgemustert wird oder wenn ein Server seine Adresse wechselt: Der alte Eintrag verschwindet nicht von allein. Für dieses Aufräumen gibt es Alterung und Aufräumen, im Englischen Aging und Scavenging, und diese Funktion ist absichtlich mit mehreren Sicherungen versehen, weil sie löscht.
Die Mechanik besteht aus zwei Zeiträumen. Im Nicht-Aktualisierungsintervall darf der Zeitstempel eines Datensatzes nicht aufgefrischt werden, was Replikationsverkehr spart. Danach beginnt das Aktualisierungsintervall, in dem der Client seinen Eintrag erneuern darf. Erst wenn beide Zeiträume verstrichen sind, ohne dass sich jemand gemeldet hat, gilt der Datensatz als veraltet und darf entfernt werden. Zusätzlich muss die Zone dafür freigegeben sein und mindestens ein Server muss das Aufräumen tatsächlich ausführen. Microsoft empfiehlt ausdrücklich, das auf genau einem Server einzuschalten, damit es im Zweifel nur eine Protokollquelle gibt.
Zwei Punkte verdienen dabei besondere Aufmerksamkeit. Statische Datensätze tragen den Zeitstempel 0 und werden nie abgeräumt, was gewollt ist. Der Befehl dnscmd /ageallrecords setzt allerdings für alle Datensätze einer Zone einen Zeitstempel, auch für die statischen, und macht sie damit angreifbar für das Aufräumen. Und Microsoft weist darauf hin, dass die Einführung auf einer bestehenden Zone mit den Voreinstellungen vier bis fünf Wochen dauern kann, wenn man sie sicher machen will. Wer diese Geduld nicht mitbringt, löscht am Ende Datensätze, die noch gebraucht werden.
Weiterleitung, bedingte Weiterleitung und die Root-Server
Ein interner DNS-Server beantwortet Anfragen für seine eigenen Zonen aus den Daten, die er hält. Für alles andere braucht er einen Weg nach draußen, und dafür gibt es drei Möglichkeiten. Ohne weitere Konfiguration arbeitet er rekursiv über die Root-Server und hangelt sich von der obersten Ebene bis zum zuständigen Server durch. Mit einer Weiterleitung gibt er stattdessen alle unbekannten Anfragen an einen anderen Server ab, meist den des Providers oder einen im eigenen Haus. Und mit einer bedingten Weiterleitung tut er das nur für bestimmte Namensräume.
Bedingte Weiterleitungen sind das Mittel der Wahl, wenn ihr mit einer zweiten Umgebung zusammenarbeitet, etwa mit einer Partnerdomäne, einem Tochterunternehmen oder einer Umgebung aus einer Übernahme. Sie halten die Zuordnung an einer Stelle und vermeiden, dass ihr fremde Zonen bei euch nachbaut. Der wiederkehrende Fehler dabei ist, dass die Gegenstelle ihre Server umzieht und niemand die Weiterleitung nachzieht. Das Fehlerbild ist dann sehr eng begrenzt und deshalb schwer zu erkennen: Nur ein einzelner Namensraum ist betroffen, alles andere funktioniert.
Für die Fehlersuche ist wichtig, wo die Antwort herkommt. Ein interner Name kommt aus der Zone, ein externer Name aus dem Cache des Servers, und dieser Cache hält auch negative Antworten fest. Wenn ihr also eine Störung an der Weiterleitung behoben habt und danach immer noch nichts geht, ist die Reparatur oft schon in Ordnung, und es fehlt nur ein Clear-DnsServerCache. Diese Reihenfolge, erst reparieren, dann leeren, dann messen, erspart eine ganze Runde ergebnisloser Fehlersuche.
Dazu passende Kurse
Wenn Namensauflösung und Verzeichnisdienst bei euch dieselben Personen betreuen, bringen Windows-Server-Kurse mit Schwerpunkt auf DNS und Verzeichnisdienst beide Themen in einen Zusammenhang.
Wer die Schichten unterhalb von DNS mitlesen können muss, findet dafür in Systemadministrationskurse für die Fehlersuche im Netz den passenden Einstieg.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Warum funktioniert nslookup, die Anwendung aber nicht?
Wie finde ich heraus, ob ein Name über LLMNR oder NetBIOS aufgelöst wird?
Wann muss ich den Cache auf dem Server leeren und nicht auf dem Client?
Sollen wir Alterung und Aufräumen einschalten?
Warum hilft es nicht, einen öffentlichen Resolver als zweiten DNS-Server einzutragen?
Der Ping auf den Domain Controller geht, die Anmeldung hakt trotzdem. Woran liegt das?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Fehlersuche im Netz einmal systematisch lernen
Bei cmt arbeitest du in den Netzwerk- und Windows-Server-Kursen an aufgebauten Fehlerbildern: Du siehst die Meldung, grenzt Schicht für Schicht ein und lernst dabei die Befehle, die du im Ernstfall parat haben musst.
Passt dazu
- DHCP ausfallsicher betreiben: Failover-Beziehung statt geteilter Bereiche
- WINS ablösen: NetBIOS-Namen geordnet auf DNS umstellen
- Active-Directory-Replikation hängt: mit repadmin und dcdiag zur Ursache
- Neuen Domain Controller in eine bestehende Domäne aufnehmen