Jump to content
Sign in to follow this  
cjmatsel

Loginscript von verschiedenen DCs

Recommended Posts

Hi,

 

ich habe vor einiger Zeit Folgendes gelernt: Wenn man ein Active-Direktory mit mehreren Standorten hat und in jedem Standort ein DC steht, dann holen sich normalerweise die Clients das Loginscript aus dem DC des eigenen Standortes, sofern am DNS nichts geändert wurde (Stichwort: Netzwerkmaskenanforderung). Mein Problem: Ich habe hier einen Windows-7-Client, welcher partout nicht darauf hören will! Er holt sich das Loginscript von wo er will! Sogar einfach von anderen Standorten. Was könnte die Ursache dafür sein und wie kann ich da tiefer in die Materie steigen?

 

cu,

cjmatsel

Share this post


Link to post
Share on other sites

Moin,

 

prüfe die Konfiguration der AD-Standorte und der zugewiesenen Subnets, die Zuordnung der DCs zu den Standorten sowie die IP-Adresse des Clients.

 

Gruß, Nils

Share this post


Link to post
Share on other sites

Hab ich schon, danke NilsK für den Tip! Die Standorte und die jeweiligen DCs und Subnetze sind alle richtig und sauber zugewiesen; die Clients landen je nach DHCP-Server auch im richtigen Standort (steht m.E. in der Ereignisanzeige). Trotzdem scheinen einige Clients von anderen Servern die Loginscripte zu nehmen... Kann ich noch weitere Details prüfen?

 

Aufgefallen ist mir das nachdem ich das Loginscript geändert habe und die sysvol-Synchronisation zwischen den Standorten erst nach der eingestellten Zeit (normalerweise 1h; bei mir 15min) die Änderungen replizierte...

 

Kann ich da vielleicht noch etwas prüfen?

Share this post


Link to post
Share on other sites
....Trotzdem scheinen einige Clients von anderen Servern die Loginscripte zu nehmen... Kann ich noch weitere Details prüfen?

 

Moin,

 

ich meine, es ist anzeigbar mit echo %logonserver%.

Edited by lefg

Share this post


Link to post
Share on other sites

Hi,

 

tatsächlich war das ein guter tip, lefg: Ich habe gerade einen PC erwischt welcher als Logonserver einen Server aus einer Filiale gezogen hat. Im Ereignisprotokoll ist zudem zwar die Meldung, zu welchem Standort der PC gehört; gleichzeitig soll der Standort einem gültigen DNS-Namen entsprechen. Das tut er wohl nicht, daher der Fehler in der Ereignisanzeige... Wie meint die Meldung das? edit: netlogon 5779

@GuentherH: Ich hatte am Script was geändert und die PCs hätten die Änderung im Standort sofort ziehen müssen. Das taten sie längere Zeit nicht; daher kam die Vermutung auf dass PCs Loginscripte von anderen Servern ziehen...

Share this post


Link to post
Share on other sites

Hi,

 

ich habe festgestellt, dass im DNS immer der Standort "-----" eingetragen wird und die Server dort zugewiesen werden, obwohl unter AD-Standorte und Dienste alles richtig ist: Standort mit Subnetz, GC und DC. Ich habe jetzt mal folgendes gemacht: DNS-Zone nicht mehr als AD-integriert. DNS-Textdatei bearbeitet und inkrement-Eintrag hochgesetzt. DNS-Zone neu geladen und AD-Integration wieder aktiviert. Jetzt sind die Standorte im DNS auch sauber drin; trotzdem wird der Standort "-----" zusätzlich eingetragen. Aber dcdiag und netdiag melden erstmal keine Fehler mehr und ich muss jetzt warten bis das repliziert wurde...

 

Das kann doch aber nicht die Lösung sein, oder? Wie bekommt man den Standort "-----" weg? Ich beobachte weiter und schaue mir jetzt mal ein paar Clients an...

 

cu,

cjmatsel

Share this post


Link to post
Share on other sites

Mist! Windows hat natürlich die Manipulation erkannt und zurückgesetzt... Also war mein Ansatz zwar richtig, aber es muss einen anderen Lösungsweg geben!

:-(

 

Any Idea?

Share this post


Link to post
Share on other sites

Moin,

 

um dir hier sinnvoll helfen zu können, benötigen wir strukturierte und ausführliche Informationen. Mit der bisherigen eher intuitiven Stichwortsammlung können wir kaum nachvollziehen, was da falsch laufen könnte.

 

Gruß, Nils

Share this post


Link to post
Share on other sites

was brauchst Du genau?

 

3 Standorte, 4 DCs. Im Hauptstandort sind 2 DCs, in jedem anderen nur jeweils einer. Unter AD-Standorte und Dienste die jeweiligen Subnetze eingetragen, Standorte erstellt und DCs zugewiesen. Jeder DC macht gleichzeitig DNS; in den Neben-Standorten auch DHCP. DNS-Zone auf AD-integriert gestellt und wird repliziert. Replikation von sysvol ohne Probleme, dcdiag und netdiag auch soweit fehlerfrei...

 

Clients meldem im Ereignisporotokoll aber, dass sie einem Standort zugewisen worden wären den es im DNS nicht gibt (Fehler: 5779, Quelle netlogon; ich schreib das ja nicht zum Spaß hin)...

 

Schaut man ins DNS, gibts dort drin weitere Standorte neben dem Hauptstandort, aber sie tragen als Namen "-----" und "------".

 

Was brauchst Du für weitere Infos bzw. was fehlt Dir dabei? Ich muss es nur wissen, damit ich es liefern kann... :-)

 

cu,

cjmatsel

Frage: Was ist das Problem und wie bekommt man es gelöst?

Share this post


Link to post
Share on other sites

Moin,

 

wie heißen die Standorte? Welche Subnets sind wie zugewiesen? Von welchen Einträgen sprichst du im DNS (DNS kennt keine Standorte)? Welche Standortangabe steht bei den 5779-Meldungen?

 

Melden alle Clients Fehler oder nur manche? Gibt es Gemeinsamkeiten bei diesen Clients? Wie ist die IP-Konfiguration dieser Clients?

 

Wie ist die Replikationsstruktur des AD aufgebaut?

 

Gibt es weitere Fehler in den Eventlogs der Server und Clients, die evtl. damit zusammenhängen könnten? (Und wenn ja: Bitte Nummer und Text angeben, denn erstens ersparst du uns dann die Nachrecherche, zweitens kann eine Nummer durchaus unterschiedliche Texte haben.)

 

Und, und, und. Oder wie ich anderswo schon mal sagte: Halt die Grundlagen des Troubleshootings.

 

Gruß, Nils

Share this post


Link to post
Share on other sites

@NilsK: DNS kennt vielleicht keine Standorte, aber Sites. Diese sieht man auch unter der jeweiligen Zone und dann "Sites". Zusätzlich sieht man diese noch unter domaindnszones, forestdnszones und weitere... Einer meiner Standorte heißt "300580" und dem Standort is ein Subnetz zugewiesen. Nennen wir es 10.0.144.0/255. Einer meiner Clients hat als Fehlermeldung im Ereignisprokotoll Folgendes zu diesem Eintrag stehen: Der Standortname dieses Computers ist "300580". Dieser Standortname ist ungültig. Ein Standortname muss eine gültige DNS-Bezeichnung sein. Geben Sie dem Standort einen gültigen Namen.

 

BTW: Google bringt zu diesem Fehlercode eine ganze Menge Suchergebnisse, nichts verwertbares jedoch zum Thema DNS-Sites...

 

Ich habe es leider aus Zeitgründen nicht geschafft alle meine über 100 Clients durchzusehen und hoffe daher dass ein Client reicht... Alle Clients sind gleich aufgebaut und beziehen Ihre Daten per DHCP. Als DNS-Server kommt der jew. des Standorts zum Tragen; die Zone stimmt ebenfalls.

 

Wie ich schon schrieb: Weitere Fehler existieren bisher nicht; weder auf den Clients noch auf den Servern... Allerdings weißt Du ja auch dass einige Fehler u.U. erst nach einer bestimmten Zeit oder Aktionen auftreten können...

 

Die Replikationsstruktur wurde nicht weiter von Standart geändert; lediglich als Transport IP statt RPC und es wurde ein Intersite Transport "schnell" benutzt, welcher auf IP basiert und nach 15 Minuten mit Kosten von 50 genutzt werden kann. Diesem Transport sind alle Standorte eingetragen...

 

Reicht das erstmal oder fehlt da noch was?

 

cu,

cjmatsel

Share this post


Link to post
Share on other sites

Hi,

 

mittlerweile gibts tatsächlich in einem meiner Haupt-DCs eine neue Fehlermeldung: netlogon, 5607 mit folgendem Text: Während der letzten 4,05 Stunden gab es 15 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden. Der Standort eines Clients wird bestimmt durch die Zuordnung seines Subnetzes zu einem existierenden Standort. Erstellen Sie Subnetzobjekte, die die oben angegeben IP-Adressen abdecken und die einem existierenden Standort zugeordnet sind, um die oben angegebenen Client einem der Standort zuzuordnen. Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte. Die Protokoller enthalten möglicherweise zusätzliche Debuginformationen. Suchen Sie nach Zeilen, die folgenden Text enthalten: "NO_CLIENT_SITE:", um die erforderlichen Informationen herauszufiltern. Das erste Wort, das auf dieser Zeichenkette folgt, ist der Clientname und das zweite Wort ist die IP-Adresse des Clients. Die maximale Größe der Protokolle wird durch folgenden DWORD-Wert in der Registrierung festgelegt: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize". Der Standardwert beträgt 20000000 Bytes. Die aktuelle maximale Größe beträgt 20000000 Bytes. Erstellen Sie den obigen Registrierungswert, und legen Sie gewünschte maximale Größe in Bytes fest, um die maximale Größe zu verändern.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

Share this post


Link to post
Share on other sites

Moin,

 

cjmatsel schrieb:

@NilsK: DNS kennt vielleicht keine Standorte, aber Sites.

nein, auch die kennt DNS nicht.

cjmatsel schrieb:

Zusätzlich sieht man diese noch unter domaindnszones, forestdnszones und weitere...

 

Siehst du, und genau deshalb frage ich, von welchen Einträgen du wann redest.

 

Also, wo genau stehen die "---"-Einträge?

cjmatsel schrieb:

Einer meiner Clients hat als Fehlermeldung im Ereignisprokotoll Folgendes zu diesem Eintrag stehen:

Gibt es an dem AD-Standort Clients, die diesen Fehler nicht haben?

 

Eigentlich sollte es keinen Grund geben, warum dieser Name ungültig wäre.

cjmatsel schrieb:

nichts verwertbares jedoch zum Thema DNS-Sites...

Was einfach daran liegen könnte, dass es "DNS-Sites" nicht gibt.

cjmatsel schrieb:

Ich habe es leider aus Zeitgründen nicht geschafft alle meine über 100 Clients durchzusehen und hoffe daher dass ein Client reicht...

Nein, in solchen Situationen wäre es schon sinnvoll zu wissen, wie sich das Problem nun wirklich darstellt, u.a. um Zusammenhänge oder Unterschiede zu identifizieren. Das Eventlog kann man ja auch auswerten, ohne Clients einzeln abzuklappern.

cjmatsel schrieb:

Alle Clients sind gleich aufgebaut und beziehen Ihre Daten per DHCP. Als DNS-Server kommt der jew. des Standorts zum Tragen; die Zone stimmt ebenfalls.

OK. Ist das stichprobenartig überprüft an den Clients, die Fehler melden?

cjmatsel schrieb:

Allerdings weißt Du ja auch dass einige Fehler u.U. erst nach einer bestimmten Zeit oder Aktionen auftreten können...

Klar. Ebenso wie Fehler, die man erst sieht, wenn man noch mal genau hinsieht. ;)

cjmatsel schrieb:

als Transport IP statt RPC

Wie meinen? IP steht doch für RPC.

cjmatsel schrieb:
und es wurde ein Intersite Transport "schnell" benutzt, welcher auf IP basiert und nach 15 Minuten mit Kosten von 50 genutzt werden kann. Diesem Transport sind alle Standorte eingetragen...

 

Äh ... also parallel zum Default IP Site Link habt ihr ein Objekt "schnell" angelegt und dort alle Standorte eingetragen - so richtig? Sind die dann aus dem Default entfernt? (Das dürfte zwar für das Problem irrelevant sein, aber gerade an dieser Stelle wäre es wichtig, von derselben Sache zu reden.)

Gibt repadmin Hinweise auf Fehler?

Gruß, Nils

Share this post


Link to post
Share on other sites

Moin,

 

Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte.

 

aha. Das war durchaus erwartet. Ich frage ja nicht zum Spaß. :cool:

 

Und, was steht in den Dateien?

 

Gruß, Nils

Share this post


Link to post
Share on other sites
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...