Fragensteller
Lange Anmeldezeiten bei Ausfall der LAN/WAN-Verbindung zu Standort

Allgemeine Diskussion
-
Hallo zusammen,
haben eine Liegenschaft, die im AD als Standort abgebildet ist.
Eigenes Subnet, eigender Fileserver, eigener Printserver und eigener DC im Standort, DC als Bridgeheadserver und GC, staatische IP-Adressvergabe, alle primeren DNS-Servereinträger in den NIC's der Server/Clients verweisen auf den DC, der die Rolle DNS Server installiert hat.
Die Replication bei bestehender Verbindung zur Mutti (also zum PDC und den anderen DFS-R Replicationspartnern funktioniert).
DC repliziert sich ausschließlich mit dem PDC - also mit dem Server der die FSMO-Rolle PDC-Emulator innehat. Dieser Server hat gleichzeit alle anderen FSMO-Rollen inne.Es ist noch keine Server-Priorisierung im DNS eingestellt. Auch ist noch keine GPO/GPP-Einstellung definiert, die den Anmeldeverkehr auf den Server im Standort ein- bzw. beschränkt.
Bei bestehender LAN/WAN-Verbindung zum Subnet, in dem der PDC steht, haben wir super Anmeldezeiten und alles ist gut.
Da es sich bei der Verbindung zum Subnet, in dem der PDC steht, um eine Funkverbindung handelt, kommt es schon mal zu Ausfallzeiten.
Tritt dieser Fall ein, dann klagen die User in dem Standort, der nun nicht mehr erreichbar ist, über mega lange Anmeldezeiten, bis "der Desktop angezeigt" wird. (richtig müsste es hier heißen: Bis alle Richtlinien abgearbeiten werden - konkret dauert es schon "ewig", bis die Anzeige "Warten auf Benutzerprofildienst" in die nächste Anzeige der abzuarbeitenden Richtlinien wechselt)
Ich rede hier von Zeiten bis 7 Minuten, bis irgendwas am Rechner in Sachen Desktop passiert.Ich könnte mir nun vorstellen, dass dies an dem fehlenden bzw. temporär nicht erreichbaren PDC liegt.
Nun die Fragen:
Aber es muss doch möglich sein, diesen Standort so zu betreiben (User und Computer/MemberServer in einer OU innerhalb einer Domäne einer Gesamtstruktur) dass eine temp. Nichterreichbarkeit der anderen DC's bzw. des PDC's zeitlich bei der Anmeldung nicht bemerkt wird!?Hat hier jemand einen Tipp? Manchmal sieht man ja vor Bäumen den Wald nicht mehr...
Vielen Dank von einem MCITP EA...
MfG Harald
- Bearbeitet H.Haas Sonntag, 27. November 2011 10:27
- Typ geändert Raul TalmaciuMicrosoft contingent staff Montag, 5. Dezember 2011 07:49 Warten auf Feedback
Alle Antworten
-
Hello H.Haas,Du solltest auf dem Standort DC ebenfalls die DNS Serverrolle installierenund die Maschinen als primären DNS diesen eintragen, den "Mutti" DC-DNS alssekundären DNS Server benutzen.Best regardsMeinolf WeberDisclaimer: This posting is provided "AS IS" with no warranties, and confersno rights.** Please do NOT email, only reply to the Forum** Send from Omea Reader 2.2
Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. -
Hallo Meinolf,
dann hatte ich mich undeutlich ausgedrückt. Das ist geschehen. DNS Rolle wurde vor der AD-Rolle installiert und Zonen sind vollständig repliziert.
Alle NIC-DNS-Servereinträge der Clients verweisen auf den DC im Standort.
Namensauflösung scheint auch zu klappen, sonst könnten bei Funkstreckenausfall ja so Geräte wie Terminalserver per DNS-namen ja nicht erreicht werden.
MfG Harald -
Am 27.11.2011 12:08, schrieb H.Haas:
DNS Rolle wurde vor der AD-Rolle installiert
Ist der DC auch ein Global Catalog Server? Sollte er sein ...
Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
GPO Tool: www.reg2xml.com - Registry Export File Converter
NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm -
Hallo Mark,
der DC ist ein GC.
Das ist ja mein Dilemma - eigentlcih scheint alles so zu sein, wie gelernt bzw. wie es sein sollte aber trotzdem scheint etwas zu fehlen oder nicht vollständig konfiguriert, wenn die Funkverbindung mal weg ist.
MfG Harald -
Schau Dir mal das Gruppenrichtlinien-Eventlog an - da findest Du Infos,was wie lange gedauert hat, und dort findest Du auch den DC, der für dieVerarbeitung verwendet wurde.Und dann kannst Du das ganze per Site-GPO auch ein wenig steuern -Computerkonfig - Richtlinien - Administrative Vorlagen - System -Netzwerkanmeldung - Domänencontrollerlocator-DNS-Einträge.mfg Martin
A bissle "Experience", a bissle GMV... -
Hallo Martin,
zwar kann im event-log der GPO-verarbeitung ein Fehler zum Zeitpunkt der fehlenden Konnektivität nachvollzogen werden aber einen Hinweis darauf, weswegen genau die Anmeldezeiten so hoch werden, erkenne ich hier nicht.
Event-Eintrag:
Bei der Verarbeitung der Gruppenrichtlinie ist aufgrund fehlender Netzwerkkonnektivität mit einem Domänencontroller ein Fehler aufgetreten. Dies kann eine vorübergehende Bedingung sein. Es wird eine Erfolgsmeldung generiert, wenn die Verbindung des Computers mit dem Domänencontroller wiederhergestellt wurde und wenn die Gruppenrichtlinie erfolgreich verarbeitet wurde. Falls für mehrere Stunden keine Erfolgsmeldung angezeigt wird, wenden Sie sich an den Administrator.Fehlereinträge in den Anwendungs- und Dienstprotokollen für die GroupPolicys lassen sich nicht erkennen.
Über die entsprechenden GPO Einträge einer GPO, welche nur auf den Standort wirkt, teste ich nun mal, ob es Verbesserungen zu melden gibt!
MfG Harald -
Hallo Raul,
derzeit läauft die Funkstrecke stabil, soll heißen, ich kam noch nicht dazu, diese "vorsätzlich" zu trennen, um das Anmeldeverhalten neu zu testen.
Die von Martin angeregten GPO Einstellungen unter Computerkonfig - Richtlinien - Administrative Vorlagen - System - Netzwerkanmeldung - Domänencontrollerlocator-DNS-Einträge haben sich bei Vorhandensein der LAN/WAN Verbindung zu mindestens nicht negativ ausgewirkt.ich melde mich, sobald ich was sagen kann...
MfG Harald