steur114 0 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Hallo zusammen, wir haben in unserem Betrieb eine Domäne mit 2 Domänencontrollern. Der Hauptserver (alle Masterrollen laufen hier) ist eine physikalische Maschine. Der zweite Server ist eine virtuelle Maschine und ist Backup gedacht. Wegen Wartungsarbeiten am Host-Server wurde der virtuelle Server heruntergefahren. Daraufhin war kein Zugriff auf Freigaben mehr möglich. Sobald der virtuelle Server wieder online war lief alles ohne Probleme. Das sollte meiner Ansicht nicht so sein und ich bin seit einer Weile erfolglos auf der Suche nach der Ursache bzw. einer Lösung für dieses Problem. Bei der Suche im Forum/Internet habe ich keine zielführenden Ansätze gefunden (oder mit den falschen Schlagworten gesucht). Hat jemand eine Idee, woran das liegen kann bzw. wie ich das Problem weiter eingrenzen kann? Vielen Dank für Eure Zeit Folgende Infos habe ich bereits zusammengetragen: SERVER01 (physikalisch, alle Masterrollen) IP-Adresse: 192.168.0.3 Subnetzmaske: 255.255.255.0 DNS 1: 192.168.0.24 DNS 2: 127.0.0.1 VDC2 (virtuell) IP-Adresse: 192.168.0.24 Subnetzmaske: 255.255.255.0 DNS 1: 192.168.0.3 DNS 2: 127.0.0.1 Masterrollen C:\Windows\system32>netdom query fsmo Schemamaster SERVER01.pgbmuc.local Domänennamen-Master SERVER01.pgbmuc.local PDC SERVER01.pgbmuc.local RID-Pool-Manager SERVER01.pgbmuc.local Infrastrukturmaster SERVER01.pgbmuc.local Der Befehl wurde ausgeführt. Prüfung mit nltest C:\Windows\system32>nltest /dnsgetdc:pgbmuc.local Liste der Domänencontroller in pseudozufälliger Reihenfolge unter Berücksichtigung von SRV-Prioritäten und -Gewichtungen: Nicht standortspezifisch: server01.pgbmuc.local 192.168.0.3 vdc2.pgbmuc.local ::1 192.168.0.24 Der Befehl wurde ausgeführt. C:\Windows\system32>nltest /dclist:pgbmuc.local Liste der Domänencontroller (DCs) in Domäne 'pgbmuc.local' von '\\VDC2.pgbmuc.local' abrufen. VDC2.pgbmuc.local [DS] Standort: PGB SERVER01.pgbmuc.local [PDC] [DS] Standort: PGB Der Befehl wurde ausgeführt. Ergebnisse von dcdiag habe ich angehängt. dcdiag_SERVER01.txt dcdiag_VDC2.txt Zitieren Link zu diesem Kommentar
Vinc211 1 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Um was für Freigaben handelt es sich? Laufwerke die per GPO gemapped wurden oder hast du es direkt versucht mit \\192.168.0.22 oder \\hostname.domain.local ? Durch deine DNS Einstellungen schaffst du eine Abhängigkeit zwischen den DC's. Ich würde die IP Adressen umdrehen. Ich bin mir nicht sicher, aber ich glaube du läufst in einen DNS Timeout. Wenn dein DHCP die 192.168.0.3 als ersten DNS angibt und SERVER01 dann bei SERVER02 anfragt und dieser nicht antwortet ist die Zeit die dort gewartet wird schon länger als Windows versucht die Freigabe zu öffnen -> Timeout. Das ist meine Idee. Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Kennen denn die Clients auch beide DNS-Server? Wenn man einen DC herunterfährt, ist auch dessen DNS wech, Zitieren Link zu diesem Kommentar
NilsK 2.958 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Moin, Durch deine DNS Einstellungen schaffst du eine Abhängigkeit zwischen den DC's. Ich würde die IP Adressen umdrehen. nö, das ist so schon Best Practice. [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net]https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Kennen denn die Clients auch beide DNS-Server? Wenn man einen DC herunterfährt, ist auch dessen DNS wech, Das wäre auch mein Tipp. Gruß, Nils Zitieren Link zu diesem Kommentar
steur114 0 Geschrieben 3. Mai 2017 Autor Melden Teilen Geschrieben 3. Mai 2017 Hallo zusammen, vielen Dank Eure schnellen Antworten. Die Clients kennen tatsächlich nur einen DNS (das werde ich ändern), allerdings ist der bei den Clients eingetragene DNS der 192.168.0.3, also der DC, der nicht abgestellt wurde. Anbei ein Beispiel für einen Client: Verbindungsspezifisches DNS-Suffix: pgbmuc.localBeschreibung: Intel® Centrino® Advanced-N 6205Physische Adresse: A0-88-B4-77-BE-7CDHCP-aktiviert: JaIPv4-Adresse: 192.168.0.166IPv4-Subnetzmaske: 255.255.255.0Lease erhalten: Freitag, 28. April 2017 11:01:17Lease läuft ab: Donnerstag, 11. Mai 2017 07:39:17IPv4-Standardgateway: 192.168.0.1IPv4-DHCP-Server: 192.168.0.3IPv4-DNS-Server: 192.168.0.3IPv4-WINS-Server:NetBIOS über TCPIP aktiviert: Ja Die Laufwerke werden über GPO gemappt (\\Domäne\DFS-Knoten\Freigabe). Ich werde versuchen herauszufinden, ob die Namensauflösung am Client möglich ist, nachdem der VDC2 offline ist. Allerdings muss ich das außerhalb der Geschäftszeiten machen, sonst laufen mir die Kollegen Amok. Falls jemand einen Tipp hat, wie ich etwas heruasfinden kann, ohne den Server offline zu nehmen, nehme ich den gerne auf. Schönen Tag derweil Zitieren Link zu diesem Kommentar
NilsK 2.958 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 (bearbeitet) Moin, Testclient?! Quatsch. Hab ich nicht mitgedacht. Gruß, Nils bearbeitet 3. Mai 2017 von NilsK Zitieren Link zu diesem Kommentar
steur114 0 Geschrieben 3. Mai 2017 Autor Melden Teilen Geschrieben 3. Mai 2017 Nach weiteren Tests bin ich auf Folgendes gestossen: C:\Windows\system32>nltest /server:server01 /dsquerydnsKennzeichen: 0Verbindung Status = 0 0x0 NERR_SuccessKein Fehler bei der letzten Aktualisierung für alle DC-spezifischen DNS-Datensätze.Der Befehl wurde ausgeführt.C:\Windows\system32>nltest /server:vdc2 /dsquerydnsKennzeichen: 0Verbindung Status = 1311 0x51f ERROR_NO_LOGON_SERVERSKein Fehler bei der letzten Aktualisierung für alle DC-spezifischen DNS-Datensätze.Der Befehl wurde ausgeführt. Hilft das bei der Eingrenzung des Problems weiter? Schönen Tag Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Ist die DNS-Zone im AD integriert? Wenn nicht: Nachholen. Zitieren Link zu diesem Kommentar
steur114 0 Geschrieben 3. Mai 2017 Autor Melden Teilen Geschrieben 3. Mai 2017 Die Zone ist im AD integriert, anbei ein Screenshot aus der DNS-Verwaltung. Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 - Wozu ist die Zone _msdcs.xxx gut? Die hat da nichts zu suchen. - Nur "sichere Updates" erlauben hat ein paar Seiteneffekte. Du musst auch auf die korrekte Config achten: https://technet.microsoft.com/en-us/library/cc961412.aspx Prüfen einfach mal auf beiden DNS-Servern, ob alle AD-Einträge im DNS vorhanden und auf allen DCs identisch sind: Zitieren Link zu diesem Kommentar
Beste Lösung Doso 77 Geschrieben 3. Mai 2017 Beste Lösung Melden Teilen Geschrieben 3. Mai 2017 Lass mich raten. DFS Namespaces im Einsatz, diese liegen auf den DCs und ihr habt nur einen DC dort konfiguriert. Zitieren Link zu diesem Kommentar
steur114 0 Geschrieben 3. Mai 2017 Autor Melden Teilen Geschrieben 3. Mai 2017 Guten Abend beisammen, tatsächlich war die Namespace-Konfiguration fehlerhaft. Es war noch ein ehem. DC eingetragen und der SERVER01 eben nicht. Ich habe die Konfiguration geändert und werde das morgen noch im Betrieb testen. Ich berichte dann von Ergebnissen. Auf jeden Fall vielen Dank an alle P.S.: Die Zone _msdcs.pgbmuc.local wurde bei uns, soweit ich weiß, von Anfang an so angelegt. Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 _msdcs ist auch Standard beim Active Directory: https://standalonelabs.wordpress.com/2011/05/08/what-is-the-_msdcs-subdomain/ Zitieren Link zu diesem Kommentar
NilsK 2.958 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 Moin, - Wozu ist die Zone _msdcs.xxx gut? Die hat da nichts zu suchen. falsch. Das ist seit Windows Server 2003 Standard. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 Gut, ist bei uns nicht da. Domäne wurde unter 2000 erstmalig eingerichtet. Geht auch ohne ?! Wozu genau ist die Zone gut? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.