Anmeldung über VPN dauert lange

[Leuchtkondom 17]

Guten Morgen.

 

Ich hoffe ihr könnt mir helfen. Und zwar arbeiten bei uns alle Außenstellen auf dem zentralen TS. In den Außenstellen sind jedoch Fat-Clients welche auch in der Domain sind. Zwischen der Zentrale und den Außenstellen bestehen VPN Verbindung welche jeglichen Traffic durchlassen.

 

Soweit funktioniert das auch wunderbar, das Problem ist aber das grade beim Hochfahren der PCs die Rechner echt lange bei "Computereinstellungen werden übernommen" hängen.

Ich habe schon eine Computerrichtlinie konfiguriert, in welcher die Ausführlichen im Vergleich zu normalen Meldungen aktiviert worden. Deswegen sehe ich auch an den PCs das nach Computereinstellungen werden übernommen auch Richtlinien wie "Group Policy Files" usw. durchlaufen.

 

Die Frage ist werden bei Computereinstellungen werden übernommen auch schon Richtlinien "durchgangen", es jedoch so nur nicht angezeigt? Oder wo könnte ich noch "drehen" um den Vorgang zu beschleunigen?

 

Wäre dankbar für eure Hilfe ..

[Leuchtkondom 17]

Okay ich habe vielleicht den Fehler gefunden, obwohl ich nicht verstehe was ich falsch habe.

 

Von einem Client ein Ping auf Domäne.local ergibt auch manchmal DC´s, die von dem Außenstandort nicht erreichbar sind. Wenn ich ipconfig /flushdns mache, und dann den Ping erneut ausführe wird ein andere DC genommen. Allerdings sind von den Außenstellen nur 2 von ca. 20 DCs erreichbar.

 

Warum nimmt der Client nicht den DC des im zugeordneten Standortes?

Und Standorte und Dienste sind alle Subnetzte eingepflegt und dem entsprechenden Standort zugewiesen.

 

In der Registry des Clients steht auch der korrekte Standort drin ... warum löst dann ping domäne.local immer einen anderen Server auf? Ich dneke das könnte auch im Zusammenhang mit dem teilweise längeren Hochfahren stehen oder?

[Leuchtkondom 17]

mmm also mit echo %logonserver% wird schon der entsprechende DC´s des Standortes angezeigt, aber sollte ping domäne.local dann nicht auch immer den passenden DC liefern?

[djmaker 95]

Eventuell hilft der Artikel weiter.

 

January 2010 - Posts - AD and Exchange Quantum Singularity

[Leuchtkondom 17]

Hallo djmaker,

 

vielen Dank für den Artikel. So wirklich weiter bin ich noch nicht.

Also ich habe jetzt mal ein paar Tests gemacht.

 

Dazu habe ich an unserem TEST ADSL Anschluss (6 Mbit) eine VPN Verbindung zum Hauptstandort, sowie zum Standort wo die EDV Abteilung sitzt hergestellt (So wie es in allen Außenstellen ist).

 

Dann habe ich einen frischen, neuen Win7-Notebook genommen und mal die Zeit gemessen die er benötigt, um bis zum Desktop zu booten (keine Domaine, normale Arbeitsgruppe): Bis zum Desktop waren es ab dem Einschalten 1:03.

 

Dann habe ich der Zentrale das Subnetz der Zentrale zugewiesen, sowie eine DNS-REverse Zone eingerichtet und den Notebook in die Domain genommen, jedoch in eine OU geschoben, wo nur 2 Richtlinien wirken. Die Default Domain Policy und die Richtlinie "aufs Netzwerk warten". Mehr nicht. Dann ein Boot vom Einschalten bis zum Strg+Alt+Entf waren beim 1. mal 1:50, beim 2. mal dann 2:50 und beim 3. mal 2:34.

 

Wie gesagt, da liegen aber keinerlei Richtlinien hinter der OU und der DSL Anschluss war komplett "frei" weil an diesem Anschluss nur der TEST Client selber hing.

 

Die Zentrale hat übrigens einen 20 MBit SDSL, und der Standort wo die EDV Sitzt (also wir) haben einen 10 MBit SDSL. An beiden Standorten stehen Server, auch DC´s. Die Außenstellen sind allen der richtigen Zentrale zugewiesen und Standort und Dienste.

 

Wenn ich jetzt den Notebook ohne LAN Kabel Booten lasse, braucht er als Domainmitglied bis zu Strg+Alt+Entf grade mal 0:47.

 

Mir ist klar, dass das länger dauert als ein nicht-Domain Mitglied, zwecks Richtlinien usw. Jedoch war der Client in einer OU ohne Richtlinien sowie an einen "relativ" schnellen DSL der komplett "frei" war.

Demzufolge warten die Außenstellen schon mal 3 - 5 Minuten bis Sie nur beim Strg+Alt+Entf sind, da dort meißt die DSL´er nicht so schnell geschalten werden können und auch einige Richtlinien drauf liegen (kleine Dateien vom Server nach lokal kopieren, Skripte, etc.)

 

An was kann das denn liegen das es so lange dauert?

Was mich wie gesagt wundert ist folgender Sachverhalt:

 

gebe ich auf meinen Client, der an einen Serverstandort steht, ping domain.local an, kommt IMMER eine Antwort vom DC des Standortes. Auch nach ipconfig /flushdns.

 

In einer Außenstellen, wird immer auf ping Domain.local ein anderer Server aufgelöst nach ipconfig /flushdns. Nur haben die Außenstellen nur zu 2 von ca. 20 Servern eine Verbindung.

[Leuchtkondom 17]

ein echo %logonserver% ergibt immer den korrekten Server, dem auch das entsprechende Subnetz zugewiesen ist.

 

In der Ereignissanzeige sind keine Fehler vorhanden auf dem Client.

In der Registry ist der korrekte Standort eingetragen

[Leuchtkondom 17]

mmm ich bin mir nicht sicher ob ich meine Fragen zu kompliziert stelle oder keiner das weiß, was ich allerdings nicht glauben kann, bei den Leuten die sich hier im Board rumtummeln :-)

 

Okay vielleicht die 1. Frage. Wer hat mehrere Standorte, mit mehreren DC´s und auch Standorte ohne DCs, dieses ohne DC Subnetz einen Standort zugewiesen (sodass der mehrere Subnetze hat) und kann mal von dort einen Ping auf domain.local durchführen? Wird immer nur der DC des jeweiligen Standortes ausgegeben? Auch nach ipconfig /flushdns?

[Leuchtkondom 17]

so ich habe mal eine Testdomain aufgesetzt und einen Client und diesen via VPN in die Testdomain aufgenommen. Da funktioniert es super schnell das hochfahren, also muss ein Problem vorliegen.

 

Oder kann es an der Anzahl der GPO´s liegen? Schaut der Client beim Hochfahren alle GPO Ordner durch ob "da was für ihn dabei ist"?

Was mich wie gesagt noch wundert ist das ping domain.local das da trotz Standorten immer ein anderer Server angezeigt wird.

Vielleicht kann dazu jemand was sagen? :-(