25.09.2017

4179

Seit IP Umstellung DC DNS Fehler

Hallo zusammen,

wir haben seit der IP-Umstellung unseres DC Probleme im DNS evtl. auch seit dem Upgrade von 2012 R2 Essentials zu 2012 R2 Standard.
Einige Tage nach dem Upgrade hat es damit angefangen das sporadisch die Internetverbindung / Netzwerk am DC ausgefallen ist. (meist in den Abendstunden)

Folgende Fehler tauchen alle paar Stunden auf haben aber komischerweise nicht immer diesen Effekt.

Fehler 1:

Die dynamische Registrierung oder das Löschen einer oder mehrerer DNS-Einträge, die mit der DNS-Domäne "DOMAIN.local." verknüpft sind, ist gescheitert. Diese Einträge werden von anderen Computern verwendet, damit diese Server entweder als Domänencontroller (wenn die angegebene Domäne eine Active Directory-Domäne ist) oder als LDAP-Server (wenn die angegebene Domäne eine Anwendungspartition ist) ermittelt werden können     

Mögliche Ursachen für den Fehler:  
- TCP/IP-Eigenschaften der Netzwerkverbindungen des Computers enthalten falsche IP-Adressen der bevorzugten und alternativen DNS-Server. 
- Die angegebenen bevorzugte und alternative DNS-Server werden nicht ausgeführt. 
- DNS-Server, die primär für die zu registrierenden Einträge vorgesehen sind, werden nicht ausgeführt. 
- Bevorzugte oder alternative DNS-Server sind mit falschen Stammhinweisen konfiguriert. 
- Übergeordnete DNS-Zone enthält falsche Delegierung auf die untergeordnete autorisierende Zone für die DNS-Einträge, bei deren Registrierung ein Fehler aufgetreten ist.  

BENUTZERAKTION  
Beheben Sie die oben angegebenen Konfigurationsfehler (sofern vorhanden), und initiieren Sie das Registrieren oder Löschen der DNS-Einträge, indem Sie "nltest.exe /dsregdns" an der Eingabeaufforderung des Domänencontrollers ausführen oder indem Sie den Anmeldedienst auf dem Domänencontroller starten.  

Fehler 2:

Die dynamische Registrierung oder das Löschen einer oder mehrerer DNS-Einträge, die mit der DNS-Domäne "DomainDnsZones.DOMAIN.local." verknüpft sind, ist gescheitert. Diese Einträge werden von anderen Computern verwendet, damit diese Server entweder als Domänencontroller (wenn die angegebene Domäne eine Active Directory-Domäne ist) oder als LDAP-Server (wenn die angegebene Domäne eine Anwendungspartition ist) ermittelt werden können     

Mögliche Ursachen für den Fehler:  
- TCP/IP-Eigenschaften der Netzwerkverbindungen des Computers enthalten falsche IP-Adressen der bevorzugten und alternativen DNS-Server. 
- Die angegebenen bevorzugte und alternative DNS-Server werden nicht ausgeführt. 
- DNS-Server, die primär für die zu registrierenden Einträge vorgesehen sind, werden nicht ausgeführt. 
- Bevorzugte oder alternative DNS-Server sind mit falschen Stammhinweisen konfiguriert. 
- Übergeordnete DNS-Zone enthält falsche Delegierung auf die untergeordnete autorisierende Zone für die DNS-Einträge, bei deren Registrierung ein Fehler aufgetreten ist.  

BENUTZERAKTION  
Beheben Sie die oben angegebenen Konfigurationsfehler (sofern vorhanden), und initiieren Sie das Registrieren oder Löschen der DNS-Einträge, indem Sie "nltest.exe /dsregdns" an der Eingabeaufforderung des Domänencontrollers ausführen oder indem Sie den Anmeldedienst auf dem Domänencontroller starten.  

Fehler 3:

Die dynamische Registrierung oder das Löschen einer oder mehrerer DNS-Einträge, die mit der DNS-Domäne "ForestDnsZones.DOMAIN.local." verknüpft sind, ist gescheitert. Diese Einträge werden von anderen Computern verwendet, damit diese Server entweder als Domänencontroller (wenn die angegebene Domäne eine Active Directory-Domäne ist) oder als LDAP-Server (wenn die angegebene Domäne eine Anwendungspartition ist) ermittelt werden können     

Mögliche Ursachen für den Fehler:  
- TCP/IP-Eigenschaften der Netzwerkverbindungen des Computers enthalten falsche IP-Adressen der bevorzugten und alternativen DNS-Server. 
- Die angegebenen bevorzugte und alternative DNS-Server werden nicht ausgeführt. 
- DNS-Server, die primär für die zu registrierenden Einträge vorgesehen sind, werden nicht ausgeführt. 
- Bevorzugte oder alternative DNS-Server sind mit falschen Stammhinweisen konfiguriert. 
- Übergeordnete DNS-Zone enthält falsche Delegierung auf die untergeordnete autorisierende Zone für die DNS-Einträge, bei deren Registrierung ein Fehler aufgetreten ist.  

BENUTZERAKTION  
Beheben Sie die oben angegebenen Konfigurationsfehler (sofern vorhanden), und initiieren Sie das Registrieren oder Löschen der DNS-Einträge, indem Sie "nltest.exe /dsregdns" an der Eingabeaufforderung des Domänencontrollers ausführen oder indem Sie den Anmeldedienst auf dem Domänencontroller starten.  

Via FQDN kommt man dann auf den Server nicht mehr nur noch via IP.

dcdiag /a gibt folgendes aus:

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = SERVER
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Starting test: Connectivity
         Der Host 89c6366f-fb16-4711-bee5-2718f35157ad._msdcs.DOMAIN.local
         konnte nicht zu einer IP-Adresse aufgelöst werden. Überprüfen Sie
         DNS-Server, DHCP, Servername, usw.
         Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie
         die Firewalleinstellungen.
         ......................... Der Test Connectivity für SERVER ist
         fehlgeschlagen.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Alle Tests werden übersprungen, da der Server SERVER nicht auf
      Anforderungen des Verzeichnisdiensts reagiert.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
            Beim Abrufen der Informationen des Querverweises
            (CN=301de651-342f-4507-9d2a-0821902646b8,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=ForestDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CheckSDRefDom für ForestDnsZones
         ist fehlgeschlagen.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=301de651-342f-4507-9d2a-0821902646b8,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=ForestDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         ForestDnsZones ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
            Beim Abrufen der Informationen des Querverweises
            (CN=b8c812c3-051c-4eb7-855a-206ab4c8bff1,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=DomainDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CheckSDRefDom für DomainDnsZones
         ist fehlgeschlagen.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=b8c812c3-051c-4eb7-855a-206ab4c8bff1,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=DomainDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         DomainDnsZones ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=Enterprise Schema,CN=Partitions,CN=Configuration,DC=DOMAIN,
DC=local)
             wurde für die Partition
            (CN=Schema,CN=Configuration,DC=DOMAIN,DC=local) der folgende
            Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für Schema ist
         fehlgeschlagen.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=EXCIP
IOGMBH,DC=local)
             wurde für die Partition (CN=Configuration,DC=DOMAIN,DC=local)
            der folgende Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         Configuration ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: DOMAIN
      Starting test: CheckSDRefDom
         ......................... DOMAIN hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=DOMAIN,CN=Partitions,CN=Configuration,DC=DOMAIN,DC=loc
al)
             wurde für die Partition (DC=DOMAIN,DC=local) der folgende
            Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für DOMAIN
         ist fehlgeschlagen.

   Unternehmenstests werden ausgeführt auf: DOMAIN.local
      Starting test: LocatorCheck
         ......................... DOMAIN.local hat den Test LocatorCheck
         bestanden.
      Starting test: Intersite
         ......................... DOMAIN.local hat den Test Intersite
         bestanden.

dcdiag /fix mach folgendes:

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = SERVER
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Starting test: Connectivity
         Der Host 89c6366f-fb16-4711-bee5-2718f35157ad._msdcs.DOMAIN.local
         konnte nicht zu einer IP-Adresse aufgelöst werden. Überprüfen Sie
         DNS-Server, DHCP, Servername, usw.
         Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie
         die Firewalleinstellungen.
         ......................... Der Test Connectivity für SERVER ist
         fehlgeschlagen.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Alle Tests werden übersprungen, da der Server SERVER nicht auf
      Anforderungen des Verzeichnisdiensts reagiert.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation
         bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DOMAIN
      Starting test: CheckSDRefDom
         ......................... DOMAIN hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... DOMAIN hat den Test CrossRefValidation
         bestanden.

   Unternehmenstests werden ausgeführt auf: DOMAIN.local
      Starting test: LocatorCheck
         ......................... DOMAIN.local hat den Test LocatorCheck
         bestanden.
      Starting test: Intersite
         ......................... DOMAIN.local hat den Test Intersite
         bestanden.

ein erneutes dcdiag /a bringt aber keine Änderung soweit ich das sehe:

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = SERVER
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Starting test: Connectivity
         Der Host 89c6366f-fb16-4711-bee5-2718f35157ad._msdcs.DOMAIN.local
         konnte nicht zu einer IP-Adresse aufgelöst werden. Überprüfen Sie
         DNS-Server, DHCP, Servername, usw.
         Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie
         die Firewalleinstellungen.
         ......................... Der Test Connectivity für SERVER ist
         fehlgeschlagen.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Alle Tests werden übersprungen, da der Server SERVER nicht auf
      Anforderungen des Verzeichnisdiensts reagiert.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
            Beim Abrufen der Informationen des Querverweises
            (CN=301de651-342f-4507-9d2a-0821902646b8,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=ForestDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CheckSDRefDom für ForestDnsZones
         ist fehlgeschlagen.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=301de651-342f-4507-9d2a-0821902646b8,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=ForestDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         ForestDnsZones ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
            Beim Abrufen der Informationen des Querverweises
            (CN=b8c812c3-051c-4eb7-855a-206ab4c8bff1,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=DomainDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CheckSDRefDom für DomainDnsZones
         ist fehlgeschlagen.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=b8c812c3-051c-4eb7-855a-206ab4c8bff1,CN=Partitions,CN=Configurat
ion,DC=DOMAIN,DC=local)
             wurde für die Partition
            (DC=DomainDnsZones,DC=DOMAIN,DC=local) der folgende Fehler
            festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         DomainDnsZones ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=Enterprise Schema,CN=Partitions,CN=Configuration,DC=DOMAIN,
DC=local)
             wurde für die Partition
            (CN=Schema,CN=Configuration,DC=DOMAIN,DC=local) der folgende
            Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für Schema ist
         fehlgeschlagen.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=EXCIP
IOGMBH,DC=local)
             wurde für die Partition (CN=Configuration,DC=DOMAIN,DC=local)
            der folgende Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für
         Configuration ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: DOMAIN
      Starting test: CheckSDRefDom
         ......................... DOMAIN hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
            Beim Abrufen der Informationen des Querverweises
            (CN=DOMAIN,CN=Partitions,CN=Configuration,DC=DOMAIN,DC=loc
al)
             wurde für die Partition (DC=DOMAIN,DC=local) der folgende
            Fehler festgestellt:
               LDAP-Fehler 0x3a (58).
         ......................... Der Test CrossRefValidation für DOMAIN
         ist fehlgeschlagen.

   Unternehmenstests werden ausgeführt auf: DOMAIN.local
      Starting test: LocatorCheck
         ......................... DOMAIN.local hat den Test LocatorCheck
         bestanden.
      Starting test: Intersite
         ......................... DOMAIN.local hat den Test Intersite
         bestanden.

Jemand eine Idee?

Danke schon mal für die Hilfe.

Viele Grüße
Yai

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 350001

Url: https://administrator.de/contentid/350001

Ausgedruckt am: 22.11.2024 um 07:11 Uhr

30 Kommentare

Neuester Kommentar

Die Rootdomain .local ist eigentlich Tabu, denn die ist fest reserviert für mDNS:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
https://support.apple.com/de-de/HT207511
Sollte man als Netzwerker eigentlich wissen und führt über kurz oder lang zu Problemen.
Hier ist es sinnvoll sowas wie .intern oder .lokal zu verwenden. Nicht aber .local !
Der Ausfall der Internet Leitung hat ja erstmal rein gar nichts mit DNS Problemen zu tun. Das sind 2 völlig verschiedene Baustellen !
Solange du noch einen "nackte" IP Adfresse wie z.B. 8.8.8.8 im Internet pingen kannst hast du keinen "Internet Ausfall" sondern dann siend deine Probleme rein DNS bedingt.
Um das sicher beurteilen zu können fehlen aber leider in der recht oberflächlichen Troubleshooting Beschreibung von oben weitere Fakten wie eben der Adress Ping Test und DNS Checks mit nslookup oder dig.
Außer DNS gibt es ja scheinbar auch noch LDAP Probleme deine Baustelle ist also noch etwas größer

@aqui
danke für deine Antwort.
Da ich weniger Netzwerker mehr Allrounder bin war mir das leider nicht bewusst zumal die bestehende Struktur nicht von mir verantwortet ist ;) Hab Sie übernommen und muss auch mit den Selbstgestrickten Fehlern erstmal leben bzw. Sie beseitigen.

Wahrscheinlich hab ich mich blöd ausgedrückt. Es sind DNS Probleme. Sobald ich die IP des DC verwende komme ich auf Ihn drauf wenn ich einen öffentlichen DNS verwende wahrscheinlich auch ohne weiteres ins Internet.
Ein nslookup auf den FQDN beim Ausfall schlägt zu keiner großen Überraschung fehl. Ebenso Ping auf FQDN.
Das LDAP Thema ist momentan nicht sonderlich akut da die beiden Maschinen(FW & Mailstore) die Abfragen funktionieren.

EDIT 10:47:
Habe mir das log nochmal angeschaut der/die DNS Fehler besteht schon länge ist aber scheinbar nie so aufgetreten wie er es jetzt tut.

Danke und Grüße
Yai

moin..

zuzüglich zu dem was aqui dazu sagt...

wir haben seit der IP-Umstellung unseres DC Probleme im DNS evtl. auch seit dem Upgrade von 2012 R2 Essentials zu 2012 R2 Standard.
Einige Tage nach dem Upgrade hat es damit angefangen das sporadisch die Internetverbindung / Netzwerk am DC ausgefallen ist. (meist in den Abendstunden)

würde ich gerne wissen was und mit "ip-umstellung" genau meinst, und wie du das gemachst hast bzw. was du genau gemacht hast.
es reicht nicht nur am server die IP zu ändern!

Frank

Hi Vision2015,

der Server wurde in ein anderes Netzsegment verschoben.
IP vorher 192.168.2.x
IP nacher 192.168.23.x

Umzug wie folgt:
2. NIC in VMWare hinzugefügt und im Server konfiguriert (Ohne Gateway)

Folgende befehle durchgeführt:
NBTSTAT -RR
IPCONFIG /Registerdns

In den Zonen in denen die alte IP Stand habe ich es dann händisch angepasst

Gateway in der 2. NIC eingetragen und die erste (alte) deaktiviert.

Da keine Windows Memberserver vorhanden ipconfig /flushdns an den Clients durchgeführt die schon online waren.

Grüße
Yai

Zitat von @Yaimael:
Umzug wie folgt:
2. NIC in VMWare hinzugefügt und im Server konfiguriert (Ohne Gateway)

Backup auf Stand vor der Umstellung einspielen und von vorne beginnen. IP-Adressumstellungen werden auf derselben Netzwerkkarte ausgeführt.

Hi,

Zitat von @chgorges:
Backup auf Stand vor der Umstellung einspielen und von vorne beginnen. IP-Adressumstellungen werden auf derselben Netzwerkkarte ausgeführt.

Diese Aussage ist genauso sinnfällig wie die Aussage "Mit einem Auto fährt man nur vorwärt."

@Yaimael
Es erschließt sich jetzt zwar auch nicht, warum dieser einfache Umzug in das anderes Netzwerk über eine zweite NIC vollzogen wurde. Ich vermute aber mal, Du wolltest das unterbrechungsfrei bewerkstelligen?

Welche IP-Adressen sind denn für den primären und sekundären DNS-Server auf dem DC eingetragen? Und ist er der einzige DC? Und der einzige interne DNS-Server?

Welche IP-Adressen sind denn für den primären und sekundären DNS-Server auf den DNS-Clients eingetragen?

E.

Und was ist die Option ohne einen Restore? -> Da die Kiste seit fast einem Monat so läuft wäre das die Wünschenswerte Variante.

Kam man den DNS nicht einfach neu schreiben lassen?

Hi,

Zitat von @aqui:
Die Rootdomain .local ist eigentlich Tabu, denn die ist fest reserviert für mDNS:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Sollte man als Netzwerker eigentlich wissen und führt über kurz oder lang zu Problemen.
Hier ist es sinnvoll sowas wie .intern oder .lokal zu verwenden. Nicht aber .local !

Ich gehe davon aus, dass es eher "über lang" sein wird und zwar "über sehr lang".
Wir setzen seit über 10 Jahren einen ".local"-Namespace ein und haben deswegen null, zero, none, nix, keine Probleme. Bislang hat mir auch noch nie jemand ein konkretes Szenario im Windows AD Umfeld gezeigt, wo das zutraf, oder ein solches auch nur skizzieren können.

Zitat von @Yaimael:

Und was ist die Option ohne einen Restore? -> Da die Kiste seit fast einem Monat so läuft wäre das die Wünschenswerte Variante.

Kam man den DNS nicht einfach neu schreiben lassen?

Kein Restore. Lass Dich nicht ablenken! Damit würdest Du alles nur noch schlimmer machen. Du hast mit höchster Wahrscheinlichkeit einen einfachen Konfigurationsfehler im DNS. Entweder am DNS-Server-Dienst oder am/an den DNS-Server-Client/s.

moin..

@emeriks hat völlig recht, vergiss die sache mit dem restore!

schau noch mal über den DNS Server, und die einträge bei den client´s

Frank

@emeriks:
Ja es sollte eine unterbrechungsfreie Versorgung des Netzwerks gewährleistet werden.

Für den DNS am DC sind zwei Linux DNS eingetragen die in einem weiteren Netzsegment laufen 192.168.200.xx

Die Clients ziehen sich nur den DC als Primären DNS-Server

@Vision2015:
Ich finde am DNS Server keinen Fehler das ist das merkwürdige. Zumindest keine die mir auffallen

Was merkwürdig ist wenn ich über einen LDAP Client nach der Alten IP-Adresse suche taucht sie an 3 Stellen noch auf:

2017-09-25 14_06_22-ldap verzeichnissuche - softerra ldap browser 4.5

Aber beim nachsehen kann ich diese nicht dort finden.

Grüße
Yai

Die Clients benutzen einen andern DNS-Server als der DC selbst?
Leitet DNS-Server für die Clients (der DC/DNS) an den DNS-Server für den DC (Linux) weiter?
Unterstützt die Zone für die interne DNS-Domäne auf den Linux-Servern dynamisch Updates?

Ja die Clients benutzen den DC als DNS nicht die Linux DNS.
Ich gehe davon aus. es sind im DNS am DC zwei FOrward-Lookupzonen (_mcdcs.DOMAIN.local + DOMAIN.local) eingetragen.
Unterstützt ja ist aber nicht aktiv.

Grüße
Yai

Du gehst davon aus?
Wenn dort die dynamischen Aktualisierungen nicht aktiviert sind, dann erklärt das die Meldungen des DC, dass er seine Records nicht aktualsieren kann.

Ich würde dem DC/DNS (der einzige DC?) sich selbst als ersten (!) DNS-Server eintragen. Den Linux als zweiten. Dem Linux eine Sekundär-Zone der Zone vom DC/DNS verpassen.
Den lokalen DNS-Dienst des DC/DNS aber "automatisch verzögert" starten. Damit solltest Du den Inseleffekt verhindern.

Hast Du die alte IP-Adresse von der deaktivierten NIC entfernt? Wenn nein, mach mal.
Der DNS-Server-Dienst ist an die neue Adresse gebunden? (oder an alle)

Wie gesagt ich habe das System übernommen und bisher nicht viel geändert.

Entschuldige ja es ist der einzige DC (bisher), es soll im laufe der nächsten Monate eine weite Windows VM kommen die ADS und DNS repliziert als Fail-Over.
Das mit den Sekundär-Zonen werde ich morgen mal einrichten und schauen was passiert.

Die alte NIC ist von der VM entfernt worden, aber ja ich hatte nach deaktivieren die IP Konfiguration aus der NIC entfernt.
Wo kann ich das nachschauen? Wenn ich in den DNS-Server-Dienst schaue sehe ich keine Adresse für die NIC.

Was ich eben beim durchschauen der Forward-Lookupzonen noch gesehen hab, ist das unter _mcdcs.DOMAIN.local bei gc im Host (A) Eintrag noch die Alte IP stand.
Warum weiß ich nicht. Hab das jetzt mal geändert.

Grüße
Yai

Wo kann ich das nachschauen? Wenn ich in den DNS-Server-Dienst schaue sehe ich keine Adresse für die NIC.

Unter Bindungen.

Was ich eben beim durchschauen der Forward-Lookupzonen noch gesehen hab, ist das unter _mcdcs.DOMAIN.local bei gc im Host (A) Eintrag noch die Alte IP stand.

Wozu DAS gut ist, habe ich noch nirgends nachlesen können. Solange wie das keine eigene Zone ist sollte das eigentlich egal sein. Aber gut, dass Du das auch noch ausgemerzt hast.
Viel wichtiger ist aber, dass die SRV unter _tcp.gc._mcdcs.DOMAIN.local und _sites.gc._mcdcs.DOMAIN.local auf den korrekten FQDN verweisen.

Dein Problem ist aber auch nicht dort zu vermuten. Du hast bereits in Deiner Eigangsfrage geschrieben, dass der FQDN des DC am Client nicht aufgelöst werden kann, wenn das Problem auftritt. Klar, dass dann auch die ganzen anderen Dienste, welche auf diese SRV angewiesen sind, nicht funktionieren bzw. nicht erreichbar sind.
Die Frage die zu klären ist: Wieso verschwindet der A-Record des DC immer wieder aus der Zone?

Zitat von @emeriks:

Wo kann ich das nachschauen? Wenn ich in den DNS-Server-Dienst schaue sehe ich keine Adresse für die NIC.

Unter Bindungen.

Also entweder bin ich blind, doof oder beides.
Ich finde den Punkt Bindungen einfach nicht

Zitat von @emeriks:

Was ich eben beim durchschauen der Forward-Lookupzonen noch gesehen hab, ist das unter _mcdcs.DOMAIN.local bei gc im Host (A) Eintrag noch die Alte IP stand.

Soweit ich das einschätzen kann steht hier der FQDN sauber drin. Konnte zumindest keine Abweichung finden.

Vielleicht hilft es wenn ich die Änderungen an den DNS Einstellungen am DC gemacht habe die du weiter oben schon beschrieben hast.
Ich gebe morgen/übermorgen mal Feedback dazu.

Was ich gerade noch gesehen habe, in den DNS-Ereignissen des DNS-Manager kommt die folgende Fehlermeldung kurz bevor der DNS wieder funktioniert:

Die Beschreibung für Ereignis-ID ( 408 ) in Quelle ( Microsoft-Windows-DNS-Server-Service ) wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren, oder den Computerhersteller nach einer neueren Version fragen.

Wenn das Ereignis von einem anderen Computer gespeichert oder von einem Remotecomputer weitergeleitet wurde, müssen Sie den Ereignissen mögliche 192.168.23.xx.

Die Fehler tragen die ID 407/408/404/408 und treten in dieser Reihenfolge mit dem Identischen Text auf.

Grüße
Yai

Also entweder bin ich blind, doof oder beides.
Ich finde den Punkt Bindungen einfach nicht

DNS-Server - Eigenschaften - Reiter "Schnittstellen"

Ok ich war doof ;)
Im DNS-Manager hab ich natürlich nicht geschaut. Unter Schnittstellen ist angehackt das er von allen IP-Adressen abhört:

2017-09-26 08_50_20-msdomain - remotedesktopverbindung

Was mir in dem Zuge jetzt auffällt, ich habe zwei DNS Server drin einmal mit FQDN und einmal nur mit dem Hostname.
Könnte das zu meinem Problem beitragen?
Ich befürchte ein ja.
Kann es sein das er den zweiten angelegt hat als ich die zweite NIC in VMware eingerichtet habe?

Grüße
Yai

Was mir in dem Zuge jetzt auffällt, ich habe zwei DNS Server drin einmal mit FQDN und einmal nur mit dem Hostname.

Wo hast Du 2 DNS-Server drin?

Im DNS-Manager stehen zwei drin einmal HOSTNAME mit Konfiguration drunter und einmal FQDN (des gleichen Servers) mit Konfiguration drunter.

Oh ja, dass ist eng!
Farbfoto vom Auto. SW-Foto vom Auto. Beide hängen in der Garage. Könnte das der Grund sein, warum die Karre nicht mehr fährt?

Zitat von @emeriks:

Wir setzen seit über 10 Jahren einen ".local"-Namespace ein und haben deswegen null, zero, none, nix, keine Probleme. Bislang hat mir auch noch nie jemand ein konkretes Szenario im Windows AD Umfeld gezeigt, wo das zutraf, oder ein solches auch nur skizzieren können.

Die TLD .local ist bereits für die Verwendung reserviert. Nur weil heute alles damit scheinbar problemlos läuft, heißt das nicht, dass das auch morgen auch noch der Fall ist. Es muss nur ein weiterer Hersteller neben Apple der Meinung sein, .local für den vorgesehen Zweck zu benutzen und schon sind die Probleme da.

Hier dein konkretes Szenario im Windows AD Umfeld: https://support.apple.com/de-de/HT207511

MfG

Zitat von @emeriks:

Oh ja, dass ist eng!
Farbfoto vom Auto. SW-Foto vom Auto. Beide hängen in der Garage. Könnte das der Grund sein, warum die Karre nicht mehr fährt?

Wie kommt es dann das beim SW Foto andere Konfigs drin sind als beim Farbfoto?!

Das kann bloß am Admin liegen. Es ist egal, ob man den DNS-Serverdienst per IP-Adresse oder per FQDN oder per NetBIOS-Name in die MMC aufnimmt. Es ist immer dieselbe Instanz, welche da angezeigt wird. Wenn da bei Dir unterschiedliche Konfigurationen angezeigt werden, dann sind die einzigen logischen Schlüsse, welche mir gerade einfallen:

Ansicht aktualisieren (F5)
Der FQDN wird in eine andere IP-Adresse aufgelöst als der Admin annimmt. Das kann man überprüfen.

Zitat von @runasservice:
Hier dein konkretes Szenario im Windows AD Umfeld: https://support.apple.com/de-de/HT207511

Das ist genau das, was ich meine. Es ist kein konkretes Beispiel. Es ist nur Angstmachen vor dem "Schwarzen Mann". "Es kann sein", "möglicherweise", "so Trump will".

Zitat von @emeriks:

Zitat von @runasservice:
Hier dein konkretes Szenario im Windows AD Umfeld: https://support.apple.com/de-de/HT207511

Das ist genau das, was ich meine. Es ist kein konkretes Beispiel. Es ist nur Angstmachen vor dem "Schwarzen Mann". "Es kann sein", "möglicherweise", "so Trump will".

Hmm, der Apple-Support macht seinen Anwendern Angst vor den "Schwarzen Mann", alles klar! Du stellst damit steile These auf. Gut, bringt nichts, Du hast natürlich recht, wer traut denn schon den Apple-Support, mit Ihren Fake-News.....

MfG

@runasservice
Bitte den Ausgangspunkt nicht vergessen: Jemand fragt hier irgendwas und erwähnt nebenbei, dass man eine .local-Domäne hat. Man kann die Sekunden zählen, bis sich jemand meldet: "Local-Domänen sind aber nicht mehr erlaubt...", Zusammenhang in den Sternen.

Zitat von @emeriks:

@runasservice
Bitte den Ausgangspunkt nicht vergessen: Jemand fragt hier irgendwas und erwähnt nebenbei, dass man eine .local-Domäne hat. Man kann die Sekunden zählen, bis sich jemand meldet: "Local-Domänen sind aber nicht mehr erlaubt...", Zusammenhang in den Sternen.

Ok, da bin ich ganz bei dir! Kommentare zur .local Domain helfen dann niemanden weiter!

Asche auf mein Haupt.....

Also die Fehler tauchen im Ereignisprotokoll nicht mehr auf.
dcdiag /a bringt auch keine Fehler mehr:

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = HOST
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\HOST
      Starting test: Connectivity
         ......................... HOST hat den Test Connectivity
         bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\HOST
      Starting test: Advertising
         ......................... HOST hat den Test Advertising bestanden.
      Starting test: FrsEvent
         ......................... HOST hat den Test FrsEvent bestanden.
      Starting test: DFSREvent
         ......................... HOST hat den Test DFSREvent bestanden.
      Starting test: SysVolCheck
         ......................... HOST hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... HOST hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... HOST hat den Test KnowsOfRoleHolders
         bestanden.
      Starting test: MachineAccount
         ......................... HOST hat den Test MachineAccount
         bestanden.
      Starting test: NCSecDesc
         ......................... HOST hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         ......................... HOST hat den Test NetLogons bestanden.
      Starting test: ObjectsReplicated
         ......................... HOST hat den Test ObjectsReplicated
         bestanden.
      Starting test: Replications
         ......................... HOST hat den Test Replications
         bestanden.
      Starting test: RidManager
         ......................... HOST hat den Test RidManager bestanden.
      Starting test: Services
         ......................... HOST hat den Test Services bestanden.
      Starting test: SystemLog
         ......................... HOST hat den Test SystemLog bestanden.
      Starting test: VerifyReferences
         ......................... HOST hat den Test VerifyReferences
         bestanden.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation
         bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test
         CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DOMAIN
      Starting test: CheckSDRefDom
         ......................... DOMAIN hat den Test CheckSDRefDom
         bestanden.
      Starting test: CrossRefValidation
         ......................... DOMAIN hat den Test CrossRefValidation
         bestanden.

   Unternehmenstests werden ausgeführt auf: DOMAIN.local
      Starting test: LocatorCheck
         ......................... DOMAIN.local hat den Test LocatorCheck
         bestanden.
      Starting test: Intersite
         ......................... DOMAIN.local hat den Test Intersite
         bestanden.

Des Fehlers Lösung waren zwei Dinge:
1. In den Forward-Lookupzonen unter _mcdcs.DOMAIN.local bei gc im Host (A) Eintrag noch die Alte IP stand.
2. Der DC nicht sich selbst als DNS drin hatte.

Danke an @emeriks für die Hilfe (wenn auch manchmal etwas bissig :P)

Grüße
Yai

Noch eine Anmerkung:
Die DNS Fehler hatten wohl doch nichts mit dem Ausfall des Netzwerk zu tun da der Fehler nach Beseitigung heute trotzdem aufgetreten ist.
Vielleicht folgt hierzu nochmal ein separates Thema.

gelöst Frage Microsoft Windows Server

Mehr von Yaimael

Client und SoftwareinventarisierungYaimael - 11 Kommentare

Zuweisen von Gruppenrichtlinien über Sicherheitsgruppen funktioniert nichtYaimael - 10 Kommentare

Heiß diskutiert