Problembehandlung für DIE DNS-Ereignis-ID 4013 (Der DNS-Server konnte keine AD-integrierten DNS-Zonen laden)
In diesem Artikel wird die Ereignis-ID 4013 aufgelöst, die nach dem Start von Windows im DNS-Ereignisprotokoll von Domänencontrollern protokolliert wird, die die DNS-Serverrolle hosten.
Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 2001093
Symptome
Auf einem Windows-basierten Computer, der Active Directory-Domänencontroller hostet, reagieren die DNS-Serverrollen für 15 bis 25 Minuten nicht mehr. Dieses Problem tritt auf, nachdem die Meldung Netzwerkverbindungen vorbereiten und vor der Windows-Anmeldeaufforderung (STRG+ALT+ENTF) angezeigt wird.
Die folgende DNS-Ereignis-ID 4013 wird nach dem Start von Windows im DNS-Ereignisprotokoll von Domänencontrollern protokolliert, die die DNS-Serverrolle hosten:
Event Type: Warning Event Source: DNS Event Category: None Event ID: 4013 Date: Date Time: Time User: N/A Computer: ComputerName Description: The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start. For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp. Data: 0000: <%status code%>In diesem Protokolleintrag werden die Werte von <%Statuscode%> möglicherweise nicht protokolliert. Oder sie enthalten die folgenden Werte, sind aber nicht auf die folgenden Werte beschränkt:
Hex Byte Dezimal Symbolische Fehlerzeichenfolge 000025f5 f5 25 00 00 9717 DNS_ERROR_DS_UNAVAILABLE Der Verzeichnisdienst ist nicht verfügbar. 0000232d 2D 23 00 00 9005 DNS_ERROR_RCODE_REFUSED DER DNS-Vorgang wurde abgelehnt. 0000232a 2a 23 00 00 9002 DNS_ERROR_RCODE_SERVER_FAILURE DNS-Serverfehler.
Kundenbeispielszenarien
Mehrere Domänencontroller an einem Active Directory-Standort, die gleichzeitig neu gestartet werden.
- Eine Domäne mit zwei Domänencontrollern wird im selben Rechenzentrum bereitgestellt.
- Die DNS-Serverrolle ist auf beiden Domänencontrollern installiert und hostet AD-integrierte Kopien der _msdcs.<Gesamtstruktur-Stammdomäne> und Active Directory-Domänenzonen.
- DC1 ist für die Verwendung von DC2 für bevorzugtes DNS und selbst für alternatives DNS konfiguriert.
- DC2 ist für die Verwendung von DC1 für bevorzugtes DNS und für alternatives DNS konfiguriert.
- Alle Domänencontroller verfügen über unterbrechungsfreie Stromversorgungen (USV) und elektrische Generatorsicherungen.
- Im Rechenzentrum gibt es häufige Stromausfälle von 2 bis 10 Stunden. USV-Geräte halten die Domänencontroller so lange im Betrieb, bis die Generatoren Strom liefern, aber sie können das HVAC-System nicht ausführen. Der in Computer der Serverklasse integrierte Temperaturschutz fährt die Domänencontroller herunter, wenn die internen Temperaturen die Herstellergrenzen erreichen.
- Wenn die Stromversorgung schließlich wiederhergestellt wird, hängen die Domänencontroller 20 Minuten lang. Dieses Problem tritt auf, nachdem Netzwerkverbindungen vorbereiten angezeigt wird und bevor die Anmeldeaufforderung angezeigt wird.
- Die DNS-Ereignis-ID 4013 wird im DNS-Ereignisprotokoll protokolliert.
Öffnen des DNS-Verwaltungskonsole (DNSMGMT. MSC) schlägt fehl und generiert die folgende Fehlermeldung:
Der Servercomputername <> konnte nicht kontaktiert werden. Fehler: Der Server ist nicht verfügbar. Möchten Sie es trotzdem hinzufügen?
Öffnen des Active Directory-Benutzer und -Computer-Snap-Ins (DSA. MSC) generiert die folgende Fehlermeldung:
Benennungsinformationen konnten nicht gefunden werden
Einzelne Domänencontroller an einem Active Directory-Standort
Ein Domänencontroller wird an einem Standort bereitgestellt.
Die DNS-Serverrolle ist installiert und hostet AD-integrierte Kopien der _msdcs.<Gesamtstruktur-Stammdomäne> und Active Directory-Domänenzonen.
Der Domänencontroller verweist auf sich selbst für das bevorzugte DNS.
Auf dem Domänencontroller ist kein alternativer DNS-Server angegeben oder verweist über eine WAN-Verbindung (Wide Area Network) auf einen Domänencontroller.
Der Domänencontroller wird aufgrund eines Stromausfalls neu gestartet.
Während des Neustarts ist die WAN-Verbindung möglicherweise nicht betriebsbereit.
Wenn der Domänencontroller gestartet wird, kann er 20 Minuten lang hängen bleiben. Dieses Problem tritt auf, nachdem Netzwerkverbindungen vorbereiten angezeigt wird und bevor die Anmeldeaufforderung angezeigt wird.
Die DNS-Ereignis-ID 4013 wird im DNS-Ereignisprotokoll protokolliert.
Öffnen des DNS-Verwaltungskonsole (DNSMGMT. MSC) schlägt fehl und generiert die folgende Fehlermeldung:
Der Servercomputername <> konnte nicht kontaktiert werden. Fehler: Der Server ist nicht verfügbar. Möchten Sie es trotzdem hinzufügen?
Öffnen des Active Directory-Benutzer und -Computer-Snap-Ins (DSA. MSC) generiert die folgende Fehlermeldung:
Die Benennungsinformationen konnten nicht gefunden werden.
Ursache
Die Kopie von Active Directory in einigen Domänencontrollern enthält Verweise auf andere Domänencontroller in der Gesamtstruktur. Diese Domänencontroller versuchen, alle lokal gehaltenen Verzeichnispartitionen während des Windows-Starts im Rahmen einer erstsynchronisierung oder Initialisierungssynchronisierung eingehender zu replizieren.
Bei dem Versuch, mit den neuesten DNS-Zoneninhalten zu starten, verzögern Microsoft-DNS-Server, die AD-integrierte Kopien von DNS-Zonen hosten, den Start des DNS-Diensts um einige Minuten nach dem Start von Windows. Die Verzögerung tritt nicht auf, wenn Active Directory die anfängliche Synchronisierung während des Windows-Starts abgeschlossen hat. In der Zwischenzeit wird Active Directory aufgrund der eingehenden Replikation von Verzeichnispartitionen verzögert. Die Replikation wird verzögert, bis die CNAME-GUID des Quelldomänencontrollers auf den DNS-Servern, die vom Zieldomänencontroller für die Namensauflösung verwendet werden, in eine IP-Adresse aufgelöst werden kann. Die Dauer des Anhaltens beim Vorbereiten von Netzwerkverbindungen hängt von der Anzahl der lokal gehaltenen Verzeichnispartitionen ab, die sich in der Active Directory-Kopie eines Domänencontrollers befinden. Die meisten Domänencontroller verfügen über mindestens die folgenden fünf Partitionen:
- Schema
- Konfiguration
- domain
- Gesamtstrukturweite DNS-Anwendungspartition
- Domänenweite DNS-Anwendungspartition
Bei diesen Domänencontrollern kann es zu einer Startverzögerung von 15 bis 20 Minuten kommen. Das Vorhandensein zusätzlicher Partitionen erhöht die Startverzögerung.
Die DNS-Ereignis-ID 4013 im DNS-Ereignisprotokoll gibt an, dass der Start des DNS-Diensts verzögert wurde. Dies liegt daran, dass die eingehende Replikation von Active Directory-Partitionen nicht stattgefunden hat.
Mehrere Bedingungen können die folgenden Probleme verschärfen:
- Langsamer Windows-Start
- Die Protokollierung des DNS-Ereignisses 4013 auf DNS-Servern, die für das Hosten von AD-integrierten Zonen konfiguriert sind, die sich implizit auf Computern befinden, die als Domänencontroller fungieren.
Zu diesen Bedingungen gehören:
- Konfigurieren eines DNS-Servers, der AD-integrierte DNS-Zonen hosten. Die Kopie von Active Directory enthält Kenntnisse über andere Domänencontroller in der Gesamtstruktur, die ausschließlich für die DNS-Namensauflösung auf sich verweisen.
- Konfigurieren eines DNS-Servers, der AD-integrierte DNS-Zonen hosten. Die Kopie von Active Directory enthält Informationen zu anderen Domänencontrollern in der Gesamtstruktur, um DNS-Server zu verweisen, die entweder nicht vorhanden sind, derzeit offline sind, nicht im Netzwerk zugänglich sind oder nicht die erforderlichen Zonen und Datensätze hosten, die für die eingehende Replikation von Active Directory benötigt werden. Beispiele hierfür sind der CNAME-GUID-Eintrag des Domänencontrollers und der zugehörige Host-A- oder AAAA-Eintrag potenzieller Quelldomänencontroller.
- Starten eines Domänencontrollers und DNS-Servers, der AD-integrierte DNS-Zonen hostet. Die Kopie von Active Directory enthält Informationen zu anderen Domänencontrollern in einem eigentlich isolierten Netzwerk aus folgenden Gründen:
- Der Netzwerkadapter oder Netzwerkstapel auf dem Aufrufer oder Zielcomputer ist entweder deaktiviert oder nicht funktionsfähig.
- Der Domänencontroller wurde in einem isolierten Netzwerk gestartet.
- Die Kopie von Active Directory des lokalen Domänencontrollers enthält Verweise auf veraltete Domänencontroller, die nicht mehr im Netzwerk vorhanden sind.
- Die Active Directory-Kopie des lokalen Domänencontrollers enthält Verweise auf andere Domänencontroller, die derzeit deaktiviert sind.
- Es liegt ein Problem auf dem Quelldomänencontroller, dem Zieldomänencontroller oder der DNS- oder Netzwerkinfrastruktur vor. Daher enthält die Kopie von Active Directory des lokalen Domänencontrollers Verweise auf andere Domänencontroller, die online und zugänglich sind, aber nicht erfolgreich von repliziert werden können.
In Windows Server 2003 und Windows 2000 Server SP3 oder höher müssen die Domänencontroller, die Vorgänge master Rollen hosten, auch eingehende Änderungen an der Verzeichnispartition erfolgreich replizieren, die die Vorgänge master Status der Rolle verwaltet. Eine erfolgreiche Replikation muss erfolgen, bevor FSMO-abhängige Vorgänge ausgeführt werden können. Solche Erstsynchronisierungen wurden hinzugefügt, um sicherzustellen, dass sich Domänencontroller über den Besitz und den Rollenstatus der FSMO-Rolle einig waren. Die anfänglichen Synchronisierungsanforderungen, die für die Inbetriebnahme von FSMO-Rollen erforderlich sind, unterscheiden sich von der in diesem Artikel erläuterten ersten Synchronisierung, bei der Active Directory eingehende Replikationen ausführen muss, um den DNS-Serverdienst sofort zu starten.
Lösung
Einige Microsoft- und externe Inhalte haben empfohlen, den Registrierungswert Repl Perform Initial Synchronizations auf 0 festzulegen, um die Anforderungen an die anfängliche Synchronisierung in Active Directory zu umgehen. Der spezifische Registrierungsunterschlüssel und die Werte für diese Einstellung sind wie folgt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Wertname: Repl: Erste Synchronisierungen ausführen
Werttyp: REG_DWORD
Wertdaten: 0
Diese Konfigurationsänderung wird nicht für die Verwendung in Produktionsumgebungen oder in einer umgebung auf fortlaufender Basis empfohlen. Die Verwendung von Repl Perform Initial Synchronizations sollte nur in kritischen Situationen verwendet werden, um temporäre und spezifische Probleme zu lösen. Die Standardeinstellung sollte wiederhergestellt werden, nachdem solche Probleme behoben wurden.
Weitere mögliche Optionen sind:
Entfernen Sie Verweise auf veraltete Domänencontroller.
Offline- oder nicht funktionsfähige Domänencontroller betriebsbereit machen.
Domänencontroller, die AD-integrierte DNS-Zonen hosten, sollten nicht auf einen einzelnen Domänencontroller verweisen und insbesondere nur auf sich selbst als bevorzugtes DNS für die Namensauflösung.
Dns-Namensregistrierung und Namensauflösung für Domänencontroller ist ein relativ einfacher Vorgang, der von DNS-Clients und -Servern stark zwischengespeichert wird.
Das Konfigurieren von Domänencontrollern, die auf die IP-Adresse eines einzelnen DNS-Servers verweisen, einschließlich der Loopbackadresse 127.0.0.1, stellt einen Single Point of Failure dar. Diese Einstellung ist in einer Gesamtstruktur mit nur einem Domänencontroller tolerierbar, jedoch nicht in Gesamtstrukturen mit mehreren Domänencontrollern.
Hubstandortdomänencontroller sollten auf DNS-Server am selben Standort verweisen wie sie als bevorzugter und alternativer DNS-Server und schließlich auf sich selbst als ein anderer alternativer DNS-Server.
Domänencontroller des Zweigstellenstandorts sollten die bevorzugte DNS-Server-IP-Adresse so konfigurieren, dass sie auf einen DNS-Server des Hubstandorts verweist, die alternative IP-Adresse des DNS-Servers, die auf einen DNS-Server vor Ort oder einen am nächstgelegenen verfügbaren Standort verweist, und schließlich auf sich selbst mithilfe der Loopbackadresse 127.0.0.1 oder der aktuellen statischen IP-Adresse.
Wenn Sie auf DNS-Server des Hubstandorts verweisen, verringert sich die Anzahl der Hops, die erforderlich sind, um kritische Domänencontroller-SRV- und HOST-Einträge vollständig zu registrieren. Domänencontroller innerhalb des Hubstandorts erhalten in der Regel die meiste administrative Aufmerksamkeit und verfügen in der Regel über die größte Sammlung von Domänencontrollern am gleichen Standort. Da sie sich am selben Standort befinden, treten Änderungen untereinander auf:
- alle 15 Sekunden in Windows Server 2003 oder höher
- alle fünf Minuten in Windows 2000 Server
Dieses Verhalten macht solche DNS-Einträge bekannt.
Dynamische Domänencontroller-SRV und Host-A- und AAAA-Eintragsregistrierungen sind möglicherweise nicht off-box, wenn der registrierende Domänencontroller an einem Zweigstellenstandort keine ausgehende Replikation durchführen kann.
Mitgliedscomputer und -server sollten weiterhin als bevorzugtes DNS auf standortoptimale DNS-Server verweisen. Außerdem verweisen sie möglicherweise auf externe DNS-Server, um zusätzliche Fehlertoleranz zu erzielen.
Ihr letztendliches Ziel ist es, zu verhindern, dass alles zu einem Denial-of-Service führt, während Kosten, Risiken und Netzwerknutzung ausgeglichen werden, z. B.:
- Replikationslatenz und Replikationsfehler
- Hardwarefehler, Softwarefehler
- Betriebspraktiken
- kurz- und langfristige Stromausfälle
- Feuer, Diebstahl, Überschwemmungen und Erdbeben
- Terroristische Ereignisse
Stellen Sie sicher, dass Zieldomänencontroller Quelldomänencontroller mithilfe von DNS auflösen können (z. B. Fallback vermeiden).
Sie sollten sicherstellen, dass Domänencontroller die geführten CNAME-Einträge erfolgreich auflösen können, um Datensätze von aktuellen und potenziellen Quelldomänencontrollern zu hosten. Dadurch kann eine hohe Latenz vermieden werden, die durch die Fallbacklogik für die Namensauflösung eingeführt wird.
Domänencontroller sollten auf DNS-Server verweisen, die:
- Sind unter Windows-Start verfügbar.
- Hosten, Weiterleiten oder Delegieren des _msdcs.<Gesamtstruktur-Stammdomäne> und primäre DNS-Suffixzonen für aktuelle und potenzielle Quelldomänencontroller.
- Kann die aktuellen CNAME-GUID-Einträge (z. B
dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com. ) und Hostdatensätze der aktuellen und potenziellen Quelldomänencontroller auflösen.
Fehlende, doppelte oder veraltete CNAME- und Hostdatensätze tragen zu diesem Problem bei. Das Scavenging ist auf Microsoft DNS-Servern standardmäßig nicht aktiviert, wodurch die Wahrscheinlichkeit veralteter Hostdatensätze erhöht wird. Gleichzeitig kann das DNS-Scavenging zu aggressiv konfiguriert werden, sodass gültige Datensätze vorzeitig aus DNS-Zonen gelöscht werden.
Optimieren Sie Domänencontroller für fallbacks bei der Namensauflösung.
Die Unfähigkeit, DNS ordnungsgemäß zu konfigurieren, sodass Domänencontroller die CNAME-GUID-Einträge des Domänencontrollers auflösen konnten, um Einträge in DNS zu hosten, war üblich. Um die End-to-End-Replikation von Active Directory-Partitionen sicherzustellen, wurden Windows Server 2003 SP1 und höher-Domänencontroller so geändert, dass ein Fallback für die Namensauflösung durchgeführt wird:
- von der CNAME-GUID des Domänencontrollers zum vollqualifizierten Hostnamen.
- vom vollqualifizierten Hostnamen zum NetBIOS-Computernamen.
Die NTDS-Replikationsereignis-IDs 2087 und 2088 in den Verzeichnisdienst-Ereignisprotokollen geben Folgendes an:
- Ein Zieldomänencontroller konnte den CNAME-GUID-Eintrag des Domänencontrollers nicht in einen Hostdatensatz auflösen.
- Fallback für die Namensauflösung tritt auf.
WINS-, HOST- und LMHOST-Dateien können konfiguriert werden. Zieldomänencontroller können also die Namen der aktuellen und potenziellen Quelldomänencontroller auflösen. Von den drei Lösungen ist die Verwendung von WINS besser skalierbar, da WINS dynamische Updates unterstützt.
Die IP-Adressen und Namen für Computer werden unweigerlich veralten. Dieses Problem führt dazu, dass statische Einträge in HOST- und LMHOST-Dateien im Laufe der Zeit ungültig werden. Wenn dieses Problem auftritt, werden Abfragen für einen Domänencontroller möglicherweise fälschlicherweise auf einen anderen Domänencontroller aufgelöst. Außerdem wird keine Namensabfrage in einer Netzwerkablaufverfolgung beobachtet.
Ändern Sie den Startwert für den DNS-Serverdienst in manuell, wenn sie in einer bekannten fehlerhaften Konfiguration gestartet wird.
Wenn Sie einen Domänencontroller in einer bekannten fehlerhaften Konfiguration starten, die in diesem Artikel beschrieben wird, führen Sie die folgenden Schritte aus:
- Legen Sie den Startwert des DNS-Serverdiensts auf manuell fest.
- Starten Sie neu, warten Sie, bis der Domänencontroller angekündigt wurde.
- Starten Sie den DNS-Serverdienst neu.
Wenn der Dienststartwert für den DNS-Serverdienst auf manuell festgelegt ist, wartet Active Directory nicht auf den Start des DNS-Serverdiensts.
Zusätzliche Überlegungen
Vermeiden Sie Single Points of Failure.
Beispiele für Single Points of Failure sind:
- Konfigurieren eines Domänencontrollers zum Verweisen auf eine EINZELNE DNS-Server-IP-Adresse
- Platzieren aller DNS-Server auf virtuellen Gastcomputern auf demselben physischen Hostcomputer
- Platzieren aller DNS-Server am gleichen physischen Standort
- Einschränken der Netzwerkkonnektivität, sodass Zieldomänencontroller nur über einen einzelnen Netzwerkpfad für den Zugriff auf einen KDC- oder DNS-Server verfügen
Installieren Sie genügend DNS-Server für lokale, regionale und unternehmensweite Redundanzleistung, aber nicht so viele, dass die Verwaltung zu einer Belastung wird. DNS ist in der Regel ein einfacher Vorgang, der von DNS-Clients und DNS-Servern in hohem Maße zwischengespeichert wird.
Jeder Microsoft DNS-Server, der auf moderner Hardware ausgeführt wird, kann 10.000 bis 20.000 Clients pro Server erfüllen. Die Installation der DNS-Rolle auf jedem Domänencontroller kann zu einer übermäßigen Anzahl von DNS-Servern in Ihrem Unternehmen führen. Dies erhöht die Kosten.
Staffeln Sie die Neustarts von DNS-Servern in Ihrem Unternehmen, wenn möglich.
- Die Installation einiger Hotfixes, Service Packs und Anwendungen erfordert möglicherweise einen Neustart.
- Einige Kunden starten Domänencontroller nach einem zeitplanmäßigen Neustart (alle sieben Tage, alle 30 Tage).
- Planen Sie Neustarts und die Installation von Software, die einen Neustart erfordert, auf intelligente Weise. Dadurch wird verhindert, dass der einzige DNS-Server oder potenzielle Quellreplikationspartner, auf den ein Zieldomänencontroller zur Namensauflösung verweist, gleichzeitig neu gestartet wird.
Wenn Windows Update- oder Verwaltungssoftware Software installiert, die einen Neustart erfordert, staffeln Sie die Installationen auf den Zieldomänencontrollern, sodass die Hälfte der verfügbaren DNS-Server, auf die Domänencontroller zum Neustart der Namensauflösung verweisen, gleichzeitig angezeigt wird.
Installieren Sie USV-Geräte an strategischen Stellen, um die DNS-Verfügbarkeit bei kurzfristigen Stromausfällen sicherzustellen.
Erweitern Sie Ihre UPS-gestützten DNS-Server mit Vor-Ort-Generatoren.
Um erweiterte Ausfälle zu bewältigen, haben einige Kunden vor Ort Stromgeneratoren eingesetzt, um wichtige Server online zu halten. Einige Kunden haben festgestellt, dass Generatoren Server im Rechenzentrum, aber nicht im HVAC vor Ort mit Strom versorgen können. Das Fehlen einer Klimaanlage kann dazu führen, dass lokale Server heruntergefahren werden, wenn die internen Computertemperaturen einen bestimmten Schwellenwert erreichen.
Weitere Informationen
10. Mai 2010: Tests durch das Active Directory-Entwicklungsteam:
DNS wartet auf NTDS und kann erst gestartet werden, wenn die erste Replikation des Verzeichnisses abgeschlossen ist. Dies liegt daran, dass aktuelle DNS-Daten möglicherweise noch nicht auf dem Domänencontroller repliziert wurden. Andererseits benötigt NTDS DNS, um die IP-Adresse des Quelldomänencontrollers für die Replikation aufzulösen. Angenommen, DC1 verweist auf DC2 als DNS-Server und DC2 auf DC1 als DNS-Server. Wenn DC1 und DC2 gleichzeitig neu gestartet werden, kommt es aufgrund dieser gegenseitigen Abhängigkeit zu einem langsamen Start. Die Grundursache für diesen langsamen Start ist DNSQueryTimeouts.
Wenn der DNS-Serverdienst beim Starten von NTDS gut ausgeführt wird, benötigt NTDS nur zwei DNS-Abfragen, um die IP-Adresse des Quelldomänencontrollers aufzulösen:
- eine für IPv4
- die andere für IPv6
Und diese DNS-Abfragen geben fast sofort zurück.
Wenn der DNS-Serverdienst beim Starten von NTDS nicht verfügbar ist, muss NTDS 10 DNS-Abfragen senden, um die IP-Adresse aufzulösen:
- vier für GUID-basierter Name
- vier für vollqualifizierten Namen
- zwei für Name mit einer Bezeichnung
Die Latenz für jede DNS-Abfrage wird durch DNSQueryTimeouts gesteuert. Standardmäßig ist DNSQueryTimeouts auf 1 1 2 4 4 festgelegt. Dies bedeutet, dass der DNS-Client 12 (1 + 1 + 2 + 4 + 4) Sekunden auf die DNS-Serverantwort wartet. Jede Namenskontextquelle benötigt 120 Sekunden, um die IP-Adresse aufzulösen. Angenommen, es gibt fünf Benennungskontexte (Konfiguration, Schema, Domäne, ForestDnsZones, DomainDnsZones) und eine einzelne Replikationsquelle. In diesem Szenario dauert es 850 (170 x 5) Sekunden oder länger als 14 Minuten, bis NTDS die erste Replikation abgeschlossen hat.
Es wurden mehrere Tests durchgeführt, um das oben genannte Verhalten zu überprüfen.
Starten Sie den Domänencontroller neu, wenn der DNS-Server ein dritter Domänencontroller ist, der online ist. Für jeden Benennungskontext für jede Quelle gibt es zwei DNS-Abfragen, die fast sofort abgeschlossen wurden:
in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com in resolveDnsAddressWithFallback GUID based DNS name in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:31:40.534 end GetAddrInfoW: 22:31:40.534 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:31:40.534 end GetAddrInfoW: 22:31:40.534Starten Sie DC1 und DC2 gleichzeitig neu. DC1 verwendet DC2 für DNS DC2 verwendet DC1 für DNS. Für jeden Benennungskontext jeder Quelle haben wir 10 DNS-Abfragen, und jede Abfrage dauert etwa 12 Sekunden:
in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com in resolveDnsAddressWithFallback GUID based DNS name in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:37:43.066 end GetAddrInfoW: 22:37:55.113 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:37:55.113 end GetAddrInfoW: 22:38:07.131 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:07.131 end GetAddrInfoW: 22:38:19.161 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:19.176 end GetAddrInfoW: 22:38:31.185 FQDN in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:31.200 end GetAddrInfoW: 22:38:43.182 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:43.182 end GetAddrInfoW: 22:38:55.191 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:55.191 end GetAddrInfoW: 22:39:07.216 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:39:07.216 end GetAddrInfoW: 22:39:19.286 NetBios in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:39:19.286 end GetAddrInfoW: 22:39:31.308d in GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:39:31.308 end GetAddrInfoW: 22:39:43.324Um die Beziehung zwischen DNSQueryTimeouts und dem langsamen Start weiter zu untersuchen, wurden DNSQueryTimeouts auf 1 1 2 4 4 festgelegt, damit der DNS-Client 31 (1 + 1 + 2 + 4 + 4 ) Sekunden warten kann. In diesem Test wurden 31 Sekunden gewartet:
in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com in resolveDnsAddressWithFallback GUID based DNS name in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:06:48.143 end GetAddrInfoW: 18:07:19.158 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:07:19.158 end GetAddrInfoW: 18:07:50.162 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:07:50.162 end GetAddrInfoW: 18:08:21.161 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:08:21.161 end GetAddrInfoW: 18:08:52.158 FQDN in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:08:52.221 end GetAddrInfoW: 18:09:23.231 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:09:23.231 end GetAddrInfoW: 18:09:54.243 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:09:54.243 end GetAddrInfoW: 18:10:25.239 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:10:25.239 end GetAddrInfoW: 18:10:56.243 NetBios in GetIpVxAddrByDnsNameW in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:10:56.243 end GetAddrInfoW: 18:11:27.244 in GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:11:27.244 end GetAddrInfoW: 18:11:58.265
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für