Trotz entsprechender gesetzter GPO wartet Windows 7 nicht aufs Netzwerk

[stefan_k 10]

Hallo zusammen,

 

ich habe hier einen Windows 7 Client (Test-Laptop), der trotz korrekt gesetzter und gezogener GPO nicht auf das Netzwerk wartet nach einem Neustart. Entsprechend wird auch das Anmeldeskript nicht abgearbeitet, da das Netzwerk halt noch gar nicht verfügbar ist. Warte ich hingegen einige Zeit (also mind. ne Minute), wird das Skript korrekt abgearbeitet. Ausloggen/Einloggen - keine Probleme.

 

Diese 2 Einstellungen sind gesetzt:

Computerkonfiguration - Administrative Vorlagen - System -

Anmelden - "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten"

Skripts - "Anmeldeskripts gleichzeitig ausführen"

 

Dass diese Richtlinien gezogen werden, habe ich sowohl mit gpresult /r auf dem Client überprüft als auch mit rsop.msc

 

Wenn ich mir die Ereignisanzeige anschaue, finde ich da folgende hierfür vielleicht relevante Einträge:

 

10:24:34 e1cexpress, "Netzwerkverbindung mit 100 MBit/s hergestellt"
10:24:42 Service Control Manager, "Dienst Gruppenrichtlinienclient Ausgeführt"
10:24:49, Service Control Manager, "Dhcp-Client Ausgeführt"
10:24:50 NETLOGON, 5719, "Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne XYZ aufgrund der folgenden Ursache nicht einrichten: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. ..."
10:24:52 GroupPolicy, 1129, 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. ..."
10:24:56 Time-Service, 129, "Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. ..."
10:24:59 Winlogon, 7001, "Benutzeranmeldebenachrichtigung..."
10:25:00 GroupPolicy, 1129, s.o.
10:25:03 Service Control Manager, "Netzwerkverbindungen Ausgeführt."
10:25:22 Time-Service, 37, "NtpClient empfängt derzeit gültige Zeitdaten von dc1.XYZ.de"
10:26:22 GroupPolicy, 1501, "Die Gruppenrichtlinieneinstellungen für den Benutzer wurden erfolgreich verarbeitet. Es wurden keine Änderungen seit der letzten erfolgreichen Gruppenrichtlinienverarbeitung erkannt."
10:26:22 GroupPolicy, 1500, "dasselbe mit "Computer" statt "Benutzer""

 

Sieht für mich so aus, als hätte ich mich um 10:24:59 eingeloggt und das Netzwerk stand aber erst einige Sekunden später zur Verfügung, wie z.B. an den Ntp-Geschichten zu sehen.

 

gpresult /r meint ferner:

Computereinstellungen:

Letzte Gruppenrichtlinienanwendung: um 10:24:46

Gruppenrichtlinienanwendung von: dc1.XYZ.de

 

Benutzereinstellungen:

Letzte Gruppenrichtlinienanwendung: um 10:24:59

Gruppenrichtlinienanwendung von: dc2.XYZ.de

 

Aber laut Ereignisanzeige ja keinesfalls erfolgreich?! :shock:

 

Client ist ein Windows 7 Enterprise, SP 1

Domänentyp: Windows 2000

Auf die Domäne selbst habe ich keinen Zugriff, nur auf unsere OU etc. Mein Benutzeraccount hat lokale Administratorrechte, aber mit einem anderen Test-Account ohne Admin-Rechte ist es genau das gleiche Verhalten.

UAC ist aktiv

 

Das Anmeldeskript ist über eine GPO eingebunden und besteht aus zwei Teilen: 1. Batch-Datei, in GPO eingebunden (Sysvol-Policy-Verzeichnis), 2. KIX-Datei, welche ich bei mir auf einer W2k8R2-Server-Freigabe (Memberserver) abgespeichert habe.

Testweise habe ich die Batch-Datei nun angewiesen, vor und nach Aufruf des KIX-Skriptes eine TXT-Datei zu erstellen, um auszuschließen, dass es ein reines Kix-Problem ist. Letzteres kann ich aber ausschließen, da bei Logon direkt nach Neustart keine Textdatei erstellt wird.

 

So, und nun bin ich mit meinem Latein leider am Ende und hoffe, ihr habt einen Tipp oder einen Ansatzpunkt für mich? :(

 

Besten Dank, schöne Grüße und schöne Ostern

Stefan

[Sunny61 296]

Setz den Eintrag doch lokal via GPEDIT.MSC. Neustart. Wird jetzt auf das Netzwerk gewartet?

[stefan_k 10]

Hallo sunny,

 

vielen Dank für Deine Antwort und sorry wegen der der verspäteten Rückmeldung.

 

Nein, auch wenn ich die beiden Einträge lokal via gpedit.msc setze, und mehrfach neustarte, wartet er nicht aufs Netzwerk.

 

Gleiches Verhalten auch, wenn nur "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" gesetzt ist.

 

Nach ein paar Sekunden verwchwindet der Anmeldebildschirm und der Windows-Hintergrund taucht auf. Unten rechts kann man dann schön sehen, wie zunächst Ladezustands-Anzeige und Sophos und Lautstärke-Einstellung auftauchen und dann das Icon für das Netzwerk erscheint. Und hier dann zuerst mit drehendem Kringel während die Netzwerkidentifizierung läuft, dann kurz gelbes Dreieck und dann ist das Netzwerk da.

Aber das System auch längst schon (weitestgehend zumindest) geladen und meine Kontroll-txt-Dateien von dem Anmelde-Skript sind natürlich nicht da. Grmpf!

 

Schöne Grüße

Stefan

[olc 18]

Hi Stefan,

 

Deine Interpretation von der Einstellung "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" ist nicht ganz korrekt :) :

 

Es heißt nicht, daß auf eine IP-Adresse oder auf eine Domänenverbindung gewartet wird. Es wird schlichtweg auf das Netzwerk Subsystem (Treiber usw.) gewartet - und der Treiber und damit die NIC ist laut Deinem Log oben ja recht schnell "online".

 

Prüf einmal den folgenden Hotfix: Teste die Installation einmal, auch wenn kein DHCP Relay Agent im Einsatz ist: Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

 

Wenn das nicht hilft, verändere einmal den Wert der folgenden Richtlinie: Group Policy Search

60 Sekunden sind für den Beginn vermutlich ein guter Testwert.

 

Viele Grüße

olc

[pdietrich 10]

Bei uns wird das Netzwerk nachdem der Rechner (Anmeldescript) schon Verbindungen zum Server aufbauen konnte wieder kurz (bis zu 2 Minuten) durch den Virenscanner "McAfee" getrennt.

Wir warten jetzt einige Zeit und wenn wir dann die MAC lesen können geht es weiter. Mir ist leider noch nichts besseres eingefallen.

mfg

Peter

[stefan_k 10]

Hallo zusammen,

 

sorry, dass ich mich erst jetzt wieder melde. Ich habe in der Zwischenzeit weitere Einstellungen getestet und auch mal mit anderen Rechnern getestet. Dabei ist mir folgendes - für mich sehr seltsames Verhalten - aufgefallen:

 

Wenn der Client "direkt" am Netzwerk hängt (soll heißen Patchkabel zur Wanddose und diese hängt am Etagen-Switch (Bezeichnung lässt auf einen Catalyst 2900 schließen)), dann kommt es zu den Problemen.

 

Wenn dagegen noch ein kleiner billiger 4-Port-Switch dazwischen hängt, dann gibt es keine Probleme! :shock:

 

Ich habe dann mal zwei Laptops nebeneinander gestellt, den einen direkt angeschlossen (Laptop1) und den anderen an den 4-Port-Switch (Laptop2). Beide gestartet und jeweils versucht, sobald die STRG+ALT+ENTF-Anzeige kam, mich so schnell wie möglich einzuloggen. Und dann anhand der Ereignisanzeige die Startvorgänge verglichen :

Laptop1      Laptop2
13:35:30      13:37:44
+9       +9       ec1express: Netzverbindung mit 100 MBit/s Vollduplex hergestellt
+22               Netlogon-Fehler 5719
+30/+32           Ntp-Fehler 129
+33/+40           GroupPolicy-Fehler 1129
+39      +29      Winlogon 7001
        +35      Ntp empfängt... 37
        +50      Ntp snchronisiert... 35
+43      +70      Dienst "Netzwerkverbindungen" jetzt im Status Ausgeführt
        +53      DNS Client Events 1014 "Zeitüberschreitung bei der Namensauflösung für den Namen _ldap._tcp.MEINEDOMÄNE._sites.spb.meinedomäne.de, nachdem keiner der konfigurierten Server geantwortet hat."

 

Der Netlogon-Fehler, kommt nur auf dem Client, der direkt am Netz hängt - warum?

- Hat der zu dem Zeitpunkt bereits ne IP-Adresse? Aber dann sollte er den DC eigentlich finden können...

- Hat der noch keine IP-Adresse? Das müsste für den Client am 4er-Switch doch auch gelten?!

 

Der DNS-Fehler hingegen kommt nur auf Laptop2 - obwohl da ansonsten alles in bester Ordnung ist und zu dem Zeitpunkt ja auch längst Netzwerkverbindung existieren muss, siehe Ntp...

Und worauf deutet das überhaupt hin, was ist das für ne Anfrage? _sites.spb. ? Google hilft mir da auch nicht.

 

Und sonst habe ich natürlich die Hinweise von olc ausprobiert:

Prüf einmal den folgenden Hotfix: Teste die Installation einmal, auch wenn kein DHCP Relay Agent im Einsatz ist: Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

hat leider nicht geholfen

 

Wenn das nicht hilft, verändere einmal den Wert der folgenden Richtlinie: Group Policy Search

60 Sekunden sind für den Beginn vermutlich ein guter Testwert.

Danke olc, das hilft! :) Allerdings dauert der Startvorgang dadurch einiges (bislang nur gefühlt, noch nicht gemessen) länger! :(

13:02:56 OS gestartet
+8  e1cexpress, Netz mit 100 MBit
+20 NETLOGON-Fehler 5719
+ 26/+27/+46 Ntp-Fehler 129
+47 Ntp empfängt (37)
+52 Winlogon 7001
+58 Ntp synchronisiert (35)
+85 Dienst "Netzwerkverbindungen" jetzt im Status Ausgeführt

 

Habt ihr eine Erklärung für dieses Verhalten?

 

Danke und schöne Grüße

Stefan

[olc 18]

Hi,

 

schalte am "teuren" Switch einmal die "Portfast" Option ab (falls möglich und getestet) und deaktivieren am Client die "media sense" Funktion, sprich setze die Verbindungsgeschwindigkeit einmal auf den jeweiligen Wert (etwa 100Mbit/s oder 1Gbit/s).

 

Und miß doch einmal nach, um wie viel Zeitverzug es sich tatsächlich handelt mit der o.g. Option (einfach vorher / nachher Vergleich). :)

 

Viele Grüße

olc

[stefan_k 10]

Hallo,

 

nach krankheitsbedingter Pause nun endlich eine Rückmeldung.

 

Auf den "teuren" Switch habe ich keinen Zugriff, der wird zentral vom Rechenzentrum der Uni gemanagt...

 

Wenn ich am Client das "DHCP Media Sense" auf Disabled setze, erreiche ich immerhin, dass das Anmeldeskript verarbeitet wird (also die User-GPOs). Die Computer-GPOs werden hingegen beim Start nicht verarbeitet (Fehler im Event-Log), aber nach ca. 2 Minuten kommt dann eine Erfolgsmeldung im Event-Log, dass sie jetzt verarbeitet seien. Außerdem taucht der NETLOGON-Fehler weiterhin auf (btw: Hat der eigentlich irgendwelche Konsequenzen?)

Leider dauert der Start aber auch zwischen 20 und 25 Sekunden länger als der normale Client am billigen 4-Port-Switch, der sauber durchläuft! Kein NETLOGON-Fehler, Computer- und User-GPOs werden sofort abgearbeitet... :rolleyes:

 

Ferner habe ich den Startvorgang verglichen, wenn ich die Wartezeit auf die Gruppenrichtlinienverarbeitung (Group Policy Search) hochsetze auf bspw. 45 Sekunden. Der Start läuft dann durch (Computer- und User-GPOs werden abgearbeitet), aber der NETLOGON-Fehler tritt auf...

Und es dauert ziemlich genau 25 Sekunden länger! :cry:

 

Der ominöse DNS-Fehler ist übrigens verschwunden. Keine Ahnung warum.

 

Hat noch jemand einen Ansatzpunkt?

--> jeden Raum mit nem billigen kleinen Switch ausstatten... :D

 

Ist das irgendwie dramatisch, wenn der NETLOGON-Fehler auftaucht? Ist es schlimm, wenn die Computer-GPOs erst 2 Minuten später abgearbeitet werden?

 

Danke und schöne Grüße

Stefan

[olc 18]

Hi,

 

kann, vielleicht, unter Umständen ;) - das bringt Dich nicht weiter. :)

 

Du solltest auf die Netzwerkabteilung zugehen und nach der Portfast Option Fragen oder ob es "auf der Leitung" Probleme gibt. Das sollte sich Port-bezogen nachvollziehen lassen.

 

Erst danach hat es Sinn weiter zu suchen - denn Dein Test mit dem "billig-Switch" zeigt ja recht deutlich, daß es in diese Richtung zu gehen scheint.

 

Viele Grüße

olc

[stefan_k 10]

Lieber olc,

 

Hi,

 

kann, vielleicht, unter Umständen ;) - das bringt Dich nicht weiter. :)

 

Du solltest auf die Netzwerkabteilung zugehen und nach der Portfast Option Fragen oder ob es "auf der Leitung" Probleme gibt. Das sollte sich Port-bezogen nachvollziehen lassen.

 

Erst danach hat es Sinn weiter zu suchen - denn Dein Test mit dem "billig-Switch" zeigt ja recht deutlich, daß es in diese Richtung zu gehen scheint.

 

Viele Grüße

olc

 

Vielen herzlichen Dank für Dein Insistieren, das mit dem NOC-Team abzuklären! :)

 

Des Rätsels Lösung? Portfast war gar nicht aktiviert. Und seit es aktiviert ist, sind die Probleme auch zack *hastenichtgesehn* verschwunden. :cool:

 

Warum bloß hatte ich angenommen, dass die Jungs vom NOC-Team das selbstverständlich standardmäßig aktiviert haben?! :cry:

 

Aber egal, jedenfalls habe ich jetzt endlich dank Deiner Hilfe die Lösung gefunden und die Anmeldeskript-Probleme haben sich erübrigt und der Thread ist erledigt! :D

 

Schöne Grüße

Stefan

 

PS: Kann man den Beitrag hier irgendwie als Gelöst markieren?

bearbeitet 30. April 2012 von stefan_k
PS ergänzt

[olc 18]

Hi Stefan,

 

ah - ok. Also genau anders herum. Umso besser. :D

 

Schön, daß es geklappt hat und danke für Deine Rückmeldung. :)

 

P.S.: Nein, ein "gelöst" gibt es nicht.

 

Viele Grüße

olc

[triebwerk 10]

Der Eintrag ist schon etwas älter aber mich hätte interessiert um welche Policy es sich bei dem Tipp gehandelt hat?

 

Wenn das nicht hilft, verändere einmal den Wert der folgenden Richtlinie: Group Policy Search
60 Sekunden sind für den Beginn vermutlich ein guter Testwert.
 

 

 

Danke!

[olc 18]

Hi,

 

die URL der Group Policy Search hat sich geändert, hier findest Du die Einstellung wieder: http://gpsearch.azurewebsites.net/Default.aspx?PolicyID=319

 

Viele Grüße

olc

[WinfriedHH 10]

Hallo zusammen,

wir haben auch ein Problem mit dem Warten auf das Netzwerk. Nach Hochfahren des Rechners erfolgt eine automatische Anmeldung an der Domäne. Leider ist das Netzwerk zu dem Zeitpunkt noch nicht bereit, so daß nicht das servergespeicherte Profil, sondern dessen lokale Kopie geladen wird. "Portfast" ist an unseren Switches nicht aktiv, da das Feature "Spanning Tree" nicht aktiviert ist. Hier hat auh keiner Ahnung, was es damit auf sich hat - auch nach der Lektüre des (deutschsprachigen) Wikipedia-Artikels nicht. Ich bin Windows-Admin, kein Netzwerktechniker - daher sind mir die Grundlagen zum Verständnis solcher Switch-Features fremd.

 

Könnten wir aber eventuell die genannte Richtlinie:

 

http://gpsearch.azurewebsites.net/Default.aspx?PolicyID=319

 
einsetzen, um die Rechner zu veranlassen, sich erst anzumelden, wenn das Netzwerk wirklich verfügbar ist bzw. der DC erreichbar ist? Leider habe ich die englischsprachige Beschreibung nicht im Detail verstanden. Außerdem müßte ich wissen, wie diese Richtlinie auf einem deutschen Server 2008 R2 heißt. Ich habe in dem angegebenen Pfad mal gesucht, aber nichts gefunden, was dem zu entsprechen schien. Oder muß man dafür erst aktualisierte ADM-Templates importieren?

 

 

 

Danke,

Winfried

bearbeitet 9. August 2013 von WinfriedHH

[Sunny61 296]

Die beiden Einstellungen aktivieren, die in diesem Artikel genannt sind: http://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/ Zweimal den Rechner neu starten, anschließend sollten die Einstellungen übernommen worden sein.