Fragensteller
Netwerkidentifikation bleibt auf "identifying"

Allgemeine Diskussion
-
Hallo,
ich habe hin und wieder ein Problem mit der Network Location Awareness (NLA) im Domänennetzwerk.
Kurz zu meiner Umgebung:
Client - Betriebssystem ist Windows 8.1 Professional
Domaincontroller laufen (noch) unter Windows Server 2003 R2 und die AD Struktur ist ebenfalls auf 2003.
Als Client Hardware werden Lenovo Thinkpads der T - Serie eingesetzt.Zum Problem:
Wenn ich meinen Client neu starte (per LAN Kabel mit Domänennetzwerk verbunden) und mich anmelde, kommt es hin und wieder vor, dass die Netzwerkidentifikation im Status "identifying" bleibt.
Betonung liegt hier auf "hin und wieder": Von 10 Neustarts wird die Domäne 5x sofort erkannt, 5x bleibt der Status auf "identifying"
Interessant dabei ist, dass sobald ich den Netzwerkadapter aus- und wieder einschalte, die Domäne sofort erkannt wird.
Noch interessanter ist, dass ich auch einen bliebig anderen verfügbaren Adapter aktivieren kann und die Domäne auch dann sofort erkannt wird.
Versuche ich, den Dienst für die NLA neu zu starten, passiert garnichts, der Status bleibt weiterhin auf "identifying".Kann mir hier bitte jemand erklären, wo das Problem liegt bzw. mir sagen, ob es dazu irgendwo Logfiles gibt die ich auswerten kann? Bis jetzt konnte ich weder im Eventviewer noch sonst wo aufschlussreiche Logs finden.
Der Dienst wird benötigt, da sich bei erkanntem Domänennetzwerk die Windows Firewall deaktivieren soll.
Wenn das nicht zuverlässig funktioniert, habe ich hier ein großes Problem.Im Internet finde ich zu dem Problem immer wieder Links und Hinweise auf Windows Vista, das scheinbar das selbe Problem hatte, welches aber mit einer KB gefixed wurde.
Vielen Dank schonmal!
Schöne Grüße,
Michael- Bearbeitet Michael.David Montag, 24. Februar 2014 12:08
- Typ geändert Alex Pitulice Montag, 17. März 2014 14:57 Warten auf Feedback
Montag, 24. Februar 2014 12:07
Alle Antworten
-
Hi,
Am 24.02.2014 13:07, schrieb Michael.David:
[...]passiert garnichts, der Status bleibt weiterhin auf "identifying".
Definiere die Netzwerkzuordnung über die Netzwerklisten-Manager-Richtlinien in der Gruppenrichtlinie unterhalb der Sicherheitseinstellungen der Computerkonfiguration.
Das eigene Domänen netzwerk wird autom. angegeben, alle anderen sind "public" sowohl während der Erkennung, als auch Neuerkennung.
Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: http://www.gruppenrichtlinien.de - deutsch
GPO Tool: http://www.reg2xml.com - Registry Export File ConverterMontag, 24. Februar 2014 13:52 -
Hallo Mark,
Danke, ich werde das bei Gelegenheit versuchen. Aber kannst du mir erklären, warum es ohne diese Konfiguration zeitweise funktioniert und dann wieder nicht?
Ich habe inzwischen rausgefunden, dass wenn ich den NLA Service auf "delayed Startup" stelle, es zu 99% funktioniert und die Domäne erkannt wird.
Montag, 24. Februar 2014 14:04 -
Am 24.02.2014 15:04, schrieb Michael.David:
Ich habe inzwischen rausgefunden, dass wenn ich den NLA Service auf
"delayed Startup" stelle, es zu 99% funktioniert und die Domäne
erkannt wird.... immer auf das Netzwerk warten ... ist aktiviert?
Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: http://www.gruppenrichtlinien.de - deutsch
GPO Tool: http://www.reg2xml.com - Registry Export File ConverterMontag, 24. Februar 2014 14:35 -
Inzwischen musste ich leider feststellen, dass das mit dem "delayed startup" ein Reinfall war. Auf meinem Testgerät hat es den Anschein gemacht als würde es funktionieren, auf allen anderen Geräten hat's leider nicht funktioniert.
Die Einstellungen in den Netzwerklisten-Manager-Richtlinien haben leider auch nichts gebracht. Ich kann dort zwar den Namen der Domäne angeben und sagen, wohin er unidentifizierte Netzwerke schieben soll bzw. in welchem Status sich im Moment zu identifizierende Netzwerke befinden sollen, aber das scheint alles nichts zu bringen.
Montag, 24. Februar 2014 15:56 -
Am 24.02.2014 schrieb Michael.David:
Inzwischen musste ich leider feststellen, dass das mit dem "delayed startup" ein Reinfall war. Auf meinem Testgerät hat es den Anschein gemacht als würde es funktionieren, auf allen anderen Geräten hat's leider nicht funktioniert.
Hast Du diese beiden Einstellungen gesetzt?
http://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/
Mark hat ja schon danach gefragt. ;)
Servus
Winfried
Gruppenrichtlinien
WSUS Package Publisher
HowTos zum WSUS Package Publisher
NNTP-Bridge für MS-ForenMontag, 24. Februar 2014 18:36 -
Hallo Winfried, Hallo Mark.
Ja, die Einstellung ist zumindest gesetzt. Zumindest die Erste, die Zweite für die Logon Scripts scheint mir hier nicht von Relevanz zu sein.
Leider hat auch diese Einstellung nicht geholfen.
Als Workaround deaktiviere und aktiviere ich jetzt einfach den Netzwerkadapter beim Logon.
Das ist zwar alles Andere als sauber, aber es funktioniert.Dienstag, 25. Februar 2014 06:32 -
Hi,
Am 25.02.2014 07:32, schrieb Michael.David:
Als Workaround deaktiviere und aktiviere ich jetzt einfach den Netzwerkadapter beim Logon.
Hängt der Client an einem Switch mit VLAN?
Mit fällt gerade der Begriff nicht ein, aber damit hatte ich schon PRobleme :-)Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: http://www.gruppenrichtlinien.de - deutsch
GPO Tool: http://www.reg2xml.com - Registry Export File ConverterDienstag, 25. Februar 2014 09:48 -
Am 25.02.2014 10:53, schrieb Michael.David:
Ja, der Client hängt in einem VLAN.
Wenn du dich jetzt noch erinnern könntest, wie du es gelöst hast, wär's super :)Ich habs ja nicht gelöst :-) Sondern der Kunde. Ich habe von Hardware keine Ahnung mehr. Es war aber etwas in der Konfiguration des VLANs.
Diese Clients hatten schon Probleme bei "immer auf das Netzwerk warten", daß die DHCP Adresse extrem verspätet kam, nachdem zuerst eine APIPA vergeben wurde. Der Request also ins Leere lief. Aber nur beim Start ...Ich meine es war etwas mit dem Spannung Tree Protokoll, aber da würde ich mich jetzt zu weit aus dem Fenster lehnen.
Du kannst ja trotzdem mal schauen, ob du an dem VLAN etwas ändern kannst und ob sich das Verhalten dann ändert.
Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: http://www.gruppenrichtlinien.de - deutsch
GPO Tool: http://www.reg2xml.com - Registry Export File ConverterDienstag, 25. Februar 2014 10:13 -
Hi,
ich hatte (habe) das gleiche Problem. Das Problem taucht auch auf, wenn im Netz ohne VLAN's gearbeitet und Client im gleichen Subnetz wie der DC ist. Da würde ich auch erst einmal ansetzen um aus zu schließen, dass irgend eine Netzwerkkomponente mit am Fehlerbild beteiligt ist.
In der Fehleranalyse konnte ich (auch unter Windows 8.19 sehr schön das Verhalten beobachten, welches Mark schon in seinem Link beschrieben hat.
Beheben konnte ich das Problem mit einem aktuellen Treiber der Netzwerkkarte. Der war zwar vom Notebook Hersteller nicht freigegeben, aber vom Netzwerkkarten Hersteller.
Vielleicht ein Lösungsansatz, der Dir hilft.
Grüße
KlausDienstag, 25. Februar 2014 11:53 -
Hallo Michael,
bist Du weitergekommen? Hast Du die Netzwerkkarte Treiber aktualisiert, wie Klaus erwähnt hat?
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.Freitag, 28. Februar 2014 12:25 -
Am 25.02.2014 11:20, schrieb Michael.David:
Schade ;-)
Ich meine es war etwas rund ums Thema Spanning Tree.
Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: http://www.gruppenrichtlinien.de - deutsch
GPO Tool: http://www.reg2xml.com - Registry Export File ConverterFreitag, 28. Februar 2014 12:30 -
Hallo Zusammen,
Nein, bin hier leider nicht weitergekommen.
Ich habe die aktuellen Netzwerkkartentreiber ausprobiert, aber auch hier tritt das Problem auf.
Mit unseren VLANs scheint auch alles in Ordnung zu sein. Habe das Thema "Spanning Tree" an unsere Netzwerkler weitergegeben, aber sie konnten beim besten Willen nichts finden.
Es scheinen auch keine Fehlermeldungen auf den Switches auf.Habe als Workaround versucht, die Netzwerkkarte per Script beim Logon neu zu starten. Das hat das Problem zwar behoben, allerdings hat es, wie man sich denken kann, andere Probleme verursacht.
Was jetzt zu funktionieren scheint, ist, beim Logon den NLA Service neu zu starten. Und zwar so lange, bis das Netzwerk erfolgreich erkannt wurde. (1x neu starten reicht scheinbar nicht).
Habe das ebenfalls mit einem Powershell Script realisiertSg,
MichaelFreitag, 28. Februar 2014 14:18 -
Hallo Zusammen!
@Klaus: Die statische IP Adresse hat leider auch keine Besserung gebracht.
Nichtsdestotrotz konnte ich den Problemverursacher mittlerweile identifizieren.
Und zwar wird das Problem durch den Sophos Antivirus (bei uns in Version 10.3) verursacht, genauer gesagt vom Service "Sophos Anti-Virus".Sobald ich diesen Service deaktiviere, funktioniert alles wunderbar.
Ich werde den Hersteller jetzt kontaktieren.
Sollte ich eine Lösung für das Problem erhalten, werde ich sie selbstverständlich hier posten.Sg,
MichaelDonnerstag, 20. März 2014 10:25 -
Hallo Michael,
vielen Dank für das Update zum Thema. Halte uns bitte auf den Laufenden ! :)
Gruss,Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.Donnerstag, 20. März 2014 11:50