5
Gruppenrichtlinienverarbeitung eines VPN-Standorts schlägt fehl, sobald WMI-Filter eingesetzt werden
Hallo zusammen,
wie der Betreff schon verrät: ich habe ein Problem mit einem Remote-Standort und der Gruppenrichtlinienverarbeitung, sobald ein WMI-Filter eingesetzt wird.
Problembeschreibung
Es handelt sich um einen kleinen Standort mit gerade mal 3 Rechnern. An allen tritt das Problem auf, dass beim Starten von Windows der Anmeldebildschirm ca. 10 - 15 Minuten bei "Bitte warten..." hängt. Wenn sich dann endlich der User anmelden kann, dauert es erneut 10 - 15 Minuten, ehe der Desktop erscheint. Im Anwendungs-Eventlog werden folgende Warnmeldungen aufgeführt, die auf ein Problem mit der Gruppenrichtlinienverarbeitung schließen lassen:
ID 6005, Quelle Winlogon, Meldung: Der Anmeldebenachrichtigungsabonnent <GPClient> benötigt einige Zeit, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten.
ID 6006, Quelle Winlogon, Meldung: Der Anmeldebenachrichtigungsabonnent <GPClient> hat 914 Sekunden benötigt, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten.
Infrastruktur
Bevor ich euch erzähle, welche Analysen und Lösungsversuche ich durchgeführt habe, zunächst ein paar Infos über die Infrastruktur - ich denke das ist wichtig zu wissen, um das Problem besser einschätzen zu können. Wir befinden uns in einer reinen, heterogenen Microsoft AD-Domäne. Die Remotestandorte sind über Site-2-Site VPN-Verbindungen mit der Zentrale verbunden. Das Subnetz des Standortes, der Probleme macht, ist in "Active Directory-Standorte und -Dienste" dem Standort der Zentrale zugewiesen, da in der Außenstelle kein separater DC bereitgestellt wurde. Die Verbindung (und damit auch die Namensauflösung) vom Remotestandort zur Zentrale funktioniert einwandfrei, die User können über Outlook auf den Mailserver zugreifen, Netzlaufwerke werden verbunden - alles läuft problemlos, nur nicht die Verarbeitung der Gruppenrichtlinien.
Durchgeführte Analysen und Lösungsversuche
Natürlich habe ich gegoogled, sogar unseren Support-Partner zur Rate gezogen, der uns bei Problemen, die wir nicht lösen können, sonst sehr kompetent unterstützt. Wir sind zu dem Ergebnis gekommen: sobald eine Gruppenrichtlinie mit einem WMI-Filter verknüpft wird, tritt dieses Phänomen auf. Insgesamt existieren zwei solcher GPO's, einmal für Computer, einmal für Benutzer, was erklärt, warum vor und nach der Useranmeldung mehrere Minuten gewartet werden muss. Die WMI-Filter lauten wie folgt:
Computerpolicy: Select * From Win32_OperatingSystem Where ProductType="2" or ProductType="3"
Benutzerpolicy: Select * From Win32_OperatingSystem Where ProductType="1"
Die Computerpolicy soll nur auf Server-Systemen greifen, während die User-Policy nur auf Client-Computern ausgeführt werden soll. Beide GPOs sind an oberster Ebene der AD-Struktur eingehängt und werden erzwungen. Ich könnte zwar hergehen und die Richtlinien in den entsprechenden OUs verknüpfen, das hat aber zur Folge, dass an den Terminalservern die Benutzerpolicies bei jeder User-Anmeldung auch ausgeführt werden, was nicht gewünscht ist (Stichwort Loopback-Verarbeitung) - deshalb der WMI-Filter.
Die Computerpolicy erstellt an allen Servern eine Aufgabe, die Benutzerpolicy führt bei der Useranmeldung an einem Client-Rechner ein Programm aus. Das funktioniert soweit auch tadellos an allen anderen Standorten, nur eben in einer Außenstelle tritt das beschriebene Problem aus.
An einem Client habe ich testhalber die Slow Link Detection deaktiviert, siehe https://support.microsoft.com/en-us/kb/2008977
Sofern ich den Artikel richtig verstehe, sollte der Registry-Eintrag IsSlowLink=1 (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History) sein, sofern erkannt wird, dass es sich um eine langsame Verbindung handelt - doch der Wert steht bei allen Rechnern auf 0.
Weiter ist mir aufgefallen: wenn der Rechner bei "Bitte warten" hängt und ich von meinem Admin-PC mit PsKill.exe den Task WMIPrvse.exe abschieße, erscheint sofort "Drücken Sie STRG+ALT+ENTF um sich anzumelden.". Ich habe auch in dieser Richtung recherchiert und diverse MS-Patches installiert (ich weiß nicht mehr welche ^^), aber ohne Erfolg.
Auch habe ich in der Registry den Key MaxPacketSize=1 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters) gesetzt, um die Kerberos-Authentifizierung über TCP zu erzwingen - ohne Erfolg. Das war aber mehr schon ein sehr "unrealistischer Versuch", denn der Zugriff auf Netzlaufwerke und E-Mail funktioniert ja tadellos/ohne Probleme...
Wir haben auch schon einen PC getauscht - komplett frisch installiert, selbes Ergebnis. Sehr interessant ist aber: wir haben den zurückgekommenen "Problem-Rechner" mal bei uns in der Zentrale am LAN angeschlossen, eingeschalten und siehe da, die Gruppenrichtlinienverarbeitung funktioniert tadellos, schnell und ohne Probleme...
Auf Grund dieser Erkenntnisse komme ich zu dem Ergebnis, dass es sich nicht um ein "reines" Betriebssystemproblem handeln kann, sondern (zusätzlich?) irgendetwas an der Netzwerkinfrastruktur/VPN-Verbindung nicht passt - nur was? Wir haben die Firewall der Außenstelle getauscht, ohne Ergebnis. Switch ist keiner dazwischen, alle Netzwerkgeräte hängen an den LAN-Ports der Firewall. Alle Clients können den DC erreichen (Ping, Zugriff auf Netlogon etc.), es gibt keine Anzeichen für ein AD-/Domänen-/DNS-Problem - und genau das macht die Fehlersuche so schwer. Lediglich die Gruppenrichtlinienverarbeitung scheitert, sobald ein WMI-Filter eingesetzt wird - die Rechner "hängen" einfach.
Ah ja, zur WMI-Thematik: wenn ich an einem der Remoteclients wbemtest aufrufe und die oben genannte WMI-Abfrage ausführe, wird diese ohne Verzögerungen/Probleme ausgeführt.
Ein gpupdate führt übrigens ebenfalls zu einem Timeout "Die Aktualisierung der Benutzerrichtlinie wurde ich in der erwarteten Zeit abgeschlossen. Abbruch..." Es ist auch egal, ob ich als angemeldeter Domänen-Admin gpupdate aufrufe: auch wenn die Richtlinie für Domänen-Admins nicht angewendet wird, der Befehl hängt trotzdem, ehe er mit der Timeout-Meldung abbricht.
Somit bin ich mit meinem Latein ziemlich am Ende. Trotz funktionierender VPN-Verbindung und reibungslosem Zugriff auf diverse Domänen-Services (File, Mail, Print etc.) spinnt die Verarbeitung der GPOs, sobald eine Richtlinie mit einem WMI-Filter verknüpft ist.
Hat von euch jemand eine Idee, wo der Fehler noch liegen könnte? Mir wäre schon geholfen, wenn ich wüsste, wo ich ein Log der WMIPrvse.exe finde bzw. wie ich das Logging hierfür aktivieren kann - aber mein Freund Google hat hier kein zufriedenstellendes Ergebnis geliefert
Besten Dank im Voraus!
Gruß
Flo
wie der Betreff schon verrät: ich habe ein Problem mit einem Remote-Standort und der Gruppenrichtlinienverarbeitung, sobald ein WMI-Filter eingesetzt wird.
Problembeschreibung
Es handelt sich um einen kleinen Standort mit gerade mal 3 Rechnern. An allen tritt das Problem auf, dass beim Starten von Windows der Anmeldebildschirm ca. 10 - 15 Minuten bei "Bitte warten..." hängt. Wenn sich dann endlich der User anmelden kann, dauert es erneut 10 - 15 Minuten, ehe der Desktop erscheint. Im Anwendungs-Eventlog werden folgende Warnmeldungen aufgeführt, die auf ein Problem mit der Gruppenrichtlinienverarbeitung schließen lassen:
ID 6005, Quelle Winlogon, Meldung: Der Anmeldebenachrichtigungsabonnent <GPClient> benötigt einige Zeit, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten.
ID 6006, Quelle Winlogon, Meldung: Der Anmeldebenachrichtigungsabonnent <GPClient> hat 914 Sekunden benötigt, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten.
Infrastruktur
Bevor ich euch erzähle, welche Analysen und Lösungsversuche ich durchgeführt habe, zunächst ein paar Infos über die Infrastruktur - ich denke das ist wichtig zu wissen, um das Problem besser einschätzen zu können. Wir befinden uns in einer reinen, heterogenen Microsoft AD-Domäne. Die Remotestandorte sind über Site-2-Site VPN-Verbindungen mit der Zentrale verbunden. Das Subnetz des Standortes, der Probleme macht, ist in "Active Directory-Standorte und -Dienste" dem Standort der Zentrale zugewiesen, da in der Außenstelle kein separater DC bereitgestellt wurde. Die Verbindung (und damit auch die Namensauflösung) vom Remotestandort zur Zentrale funktioniert einwandfrei, die User können über Outlook auf den Mailserver zugreifen, Netzlaufwerke werden verbunden - alles läuft problemlos, nur nicht die Verarbeitung der Gruppenrichtlinien.
Durchgeführte Analysen und Lösungsversuche
Natürlich habe ich gegoogled, sogar unseren Support-Partner zur Rate gezogen, der uns bei Problemen, die wir nicht lösen können, sonst sehr kompetent unterstützt. Wir sind zu dem Ergebnis gekommen: sobald eine Gruppenrichtlinie mit einem WMI-Filter verknüpft wird, tritt dieses Phänomen auf. Insgesamt existieren zwei solcher GPO's, einmal für Computer, einmal für Benutzer, was erklärt, warum vor und nach der Useranmeldung mehrere Minuten gewartet werden muss. Die WMI-Filter lauten wie folgt:
Computerpolicy: Select * From Win32_OperatingSystem Where ProductType="2" or ProductType="3"
Benutzerpolicy: Select * From Win32_OperatingSystem Where ProductType="1"
Die Computerpolicy soll nur auf Server-Systemen greifen, während die User-Policy nur auf Client-Computern ausgeführt werden soll. Beide GPOs sind an oberster Ebene der AD-Struktur eingehängt und werden erzwungen. Ich könnte zwar hergehen und die Richtlinien in den entsprechenden OUs verknüpfen, das hat aber zur Folge, dass an den Terminalservern die Benutzerpolicies bei jeder User-Anmeldung auch ausgeführt werden, was nicht gewünscht ist (Stichwort Loopback-Verarbeitung) - deshalb der WMI-Filter.
Die Computerpolicy erstellt an allen Servern eine Aufgabe, die Benutzerpolicy führt bei der Useranmeldung an einem Client-Rechner ein Programm aus. Das funktioniert soweit auch tadellos an allen anderen Standorten, nur eben in einer Außenstelle tritt das beschriebene Problem aus.
An einem Client habe ich testhalber die Slow Link Detection deaktiviert, siehe https://support.microsoft.com/en-us/kb/2008977
Sofern ich den Artikel richtig verstehe, sollte der Registry-Eintrag IsSlowLink=1 (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History) sein, sofern erkannt wird, dass es sich um eine langsame Verbindung handelt - doch der Wert steht bei allen Rechnern auf 0.
Weiter ist mir aufgefallen: wenn der Rechner bei "Bitte warten" hängt und ich von meinem Admin-PC mit PsKill.exe den Task WMIPrvse.exe abschieße, erscheint sofort "Drücken Sie STRG+ALT+ENTF um sich anzumelden.". Ich habe auch in dieser Richtung recherchiert und diverse MS-Patches installiert (ich weiß nicht mehr welche ^^), aber ohne Erfolg.
Auch habe ich in der Registry den Key MaxPacketSize=1 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters) gesetzt, um die Kerberos-Authentifizierung über TCP zu erzwingen - ohne Erfolg. Das war aber mehr schon ein sehr "unrealistischer Versuch", denn der Zugriff auf Netzlaufwerke und E-Mail funktioniert ja tadellos/ohne Probleme...
Wir haben auch schon einen PC getauscht - komplett frisch installiert, selbes Ergebnis. Sehr interessant ist aber: wir haben den zurückgekommenen "Problem-Rechner" mal bei uns in der Zentrale am LAN angeschlossen, eingeschalten und siehe da, die Gruppenrichtlinienverarbeitung funktioniert tadellos, schnell und ohne Probleme...
Auf Grund dieser Erkenntnisse komme ich zu dem Ergebnis, dass es sich nicht um ein "reines" Betriebssystemproblem handeln kann, sondern (zusätzlich?) irgendetwas an der Netzwerkinfrastruktur/VPN-Verbindung nicht passt - nur was? Wir haben die Firewall der Außenstelle getauscht, ohne Ergebnis. Switch ist keiner dazwischen, alle Netzwerkgeräte hängen an den LAN-Ports der Firewall. Alle Clients können den DC erreichen (Ping, Zugriff auf Netlogon etc.), es gibt keine Anzeichen für ein AD-/Domänen-/DNS-Problem - und genau das macht die Fehlersuche so schwer. Lediglich die Gruppenrichtlinienverarbeitung scheitert, sobald ein WMI-Filter eingesetzt wird - die Rechner "hängen" einfach.
Ah ja, zur WMI-Thematik: wenn ich an einem der Remoteclients wbemtest aufrufe und die oben genannte WMI-Abfrage ausführe, wird diese ohne Verzögerungen/Probleme ausgeführt.
Ein gpupdate führt übrigens ebenfalls zu einem Timeout "Die Aktualisierung der Benutzerrichtlinie wurde ich in der erwarteten Zeit abgeschlossen. Abbruch..." Es ist auch egal, ob ich als angemeldeter Domänen-Admin gpupdate aufrufe: auch wenn die Richtlinie für Domänen-Admins nicht angewendet wird, der Befehl hängt trotzdem, ehe er mit der Timeout-Meldung abbricht.
Somit bin ich mit meinem Latein ziemlich am Ende. Trotz funktionierender VPN-Verbindung und reibungslosem Zugriff auf diverse Domänen-Services (File, Mail, Print etc.) spinnt die Verarbeitung der GPOs, sobald eine Richtlinie mit einem WMI-Filter verknüpft ist.
Hat von euch jemand eine Idee, wo der Fehler noch liegen könnte? Mir wäre schon geholfen, wenn ich wüsste, wo ich ein Log der WMIPrvse.exe finde bzw. wie ich das Logging hierfür aktivieren kann - aber mein Freund Google hat hier kein zufriedenstellendes Ergebnis geliefert
Besten Dank im Voraus!
Gruß
Flo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 293878
Url: https://administrator.de/forum/gruppenrichtlinienverarbeitung-eines-vpn-standorts-schlaegt-fehl-sobald-wmi-filter-eingesetzt-werden-293878.html
Ausgedruckt am: 20.12.2024 um 05:12 Uhr
5 Kommentare
Neuester Kommentar
Hi,
selten so eine ausführliche, gut ausformulierte, und - soweit ich es sehen kann - grammatikalisch und orthografisch fehlerfreie Frage hier gesehen! Respekt!
Zum Thema:
Da Du es explizit erwähnst, dass der Netzwerk-Standort nicht extra im AD abgebildet ist, gehe ich davon aus, dass an anderen Standorten außer der Zentrale schon mal DC's vor Ort sind?
Hinsichtlich Auswahl der DC im Fehlerfall und Slow Link Detection macht sich so ein Standort-Objekt aber sehr vorteilhaft. Wir haben bei uns ein Standort-Objekt "Ohne DC" angelegt und diesem alle Subnetz der betreffenden Netzwerk-Standorte zugeordnet, welche keinen DC vor Ort haben. Ein Client, der nicht bemerkt, dass er sich an einem anderen Standort als der DC befindet, prüft meines Wissens überhaupt nicht auf langsame Verbindungen. Weiterhin: Wenn der AD-Standort ohne DC nur eine Replikationsverbindung mit der Zentrale hat, dann versucht ein Client erst gar nicht, einen DC eines anderen Standorts auch nur "anzufragen". Wenn der Client jedoch "denkt", er wäre in der Zentrale, und der AD-Standort der Zentrale hat Site Links mit anderen AD-Standorten mit DC vor Ort, dann kann es vorkommen, dass Clients vom Standort ohne DC mal einfach so versuchen, einen DC von einem Standort mit DC (Nicht-Zentrale) "anzufragen". Insbesondere auch im Zusammenhang mit DFS-Namespaces (--> SYSVOL !).
Zumindest die GPO für die Computer würde ich statt über WMI besser über OU-Links filtern. OU's, in welchen nur Server sind, und OU's in welchen nur Terminalserver sind, und solche, in welchen nur Workstations sind.
Wenn Du auch für die Clients Loopback in Modus "Zusammenführen" ("merge") aktivierst, dann kannst Du die GPO, welche für Benutzer nur bei Anmeldung am Client gelten sollen, an die Stamm-OU für Workstations verlinken.
E.
selten so eine ausführliche, gut ausformulierte, und - soweit ich es sehen kann - grammatikalisch und orthografisch fehlerfreie Frage hier gesehen! Respekt!
Zum Thema:
Da Du es explizit erwähnst, dass der Netzwerk-Standort nicht extra im AD abgebildet ist, gehe ich davon aus, dass an anderen Standorten außer der Zentrale schon mal DC's vor Ort sind?
Hinsichtlich Auswahl der DC im Fehlerfall und Slow Link Detection macht sich so ein Standort-Objekt aber sehr vorteilhaft. Wir haben bei uns ein Standort-Objekt "Ohne DC" angelegt und diesem alle Subnetz der betreffenden Netzwerk-Standorte zugeordnet, welche keinen DC vor Ort haben. Ein Client, der nicht bemerkt, dass er sich an einem anderen Standort als der DC befindet, prüft meines Wissens überhaupt nicht auf langsame Verbindungen. Weiterhin: Wenn der AD-Standort ohne DC nur eine Replikationsverbindung mit der Zentrale hat, dann versucht ein Client erst gar nicht, einen DC eines anderen Standorts auch nur "anzufragen". Wenn der Client jedoch "denkt", er wäre in der Zentrale, und der AD-Standort der Zentrale hat Site Links mit anderen AD-Standorten mit DC vor Ort, dann kann es vorkommen, dass Clients vom Standort ohne DC mal einfach so versuchen, einen DC von einem Standort mit DC (Nicht-Zentrale) "anzufragen". Insbesondere auch im Zusammenhang mit DFS-Namespaces (--> SYSVOL !).
Zumindest die GPO für die Computer würde ich statt über WMI besser über OU-Links filtern. OU's, in welchen nur Server sind, und OU's in welchen nur Terminalserver sind, und solche, in welchen nur Workstations sind.
Wenn Du auch für die Clients Loopback in Modus "Zusammenführen" ("merge") aktivierst, dann kannst Du die GPO, welche für Benutzer nur bei Anmeldung am Client gelten sollen, an die Stamm-OU für Workstations verlinken.
E.
Servus emeriks,
auch ich bedanke mich recht herzlich für die umfangreiche Antwort
Deine Annahme bzgl. anderer Standorte ist korrekt: wir haben mehrere Standorte, davon sind die Meisten mit einem eigenen DC ausgestattet, es gibt aber auch 2, 3 Standorte ohne DC (da stehen nur 2, 3 Rechner rum). Die Subnetze dieser Standorte sind alle mit der Site der Zentrale verknüpft - bislang gab's auch da kein Problem.
Ich habe deinen Tipp mal befolgt und einen Standort angelegt, das Subnetz der Außenstelle zugewiesen, eine Sitelink zwischen Zentrale und Außenstelle erstellt und alles mal durchrepliziert - Ergebnis bleibt aber dasselbe.
Was gegen die Vermutung spricht, dass die Clients der Zweigniederlassung einen anderen DC versuchen zu kontaktieren:
a) Als Logonserver wird immer / ausnahmslos der DC der Zentrale angezeigt. Ich gehe daher davon aus, dass er auch die Richtlinien dann von diesem DC abruft - oder liege ich hier falsch!?
b) Sobald ich den WMI-Filter von der GPO entferne, also die Richtlinie ohne Filter konfiguriere, werden alle Richtlinien einwandfrei abgearbeitet - und das nach gefühlten 100 Neustarts die ich durchgeführt habe, um die Problematik mit den DC's anderer Standorte auszuschließen.
c) Anmeldeskripte, die im Sysvol/Netlogon-Share liegen, werden tadellos ausgeführt.
Das ist ja gerade das Seltsame: die Gruppenrichtlinien werden problemlos abgearbeitet, so lange ich keinen WMI-Filter einsetze.
Zum WMI-Filter: wir haben ca. 30 Gruppenrichtlinienobjekte, die allesamt ohne irgendwelchen speziellen Schnick Schnack wie WMI-Filter, Delegierung etc. in unserer AD-Struktur verknüpft sind. Unsere Struktur entspricht im Übrigen ziemlich genau deinen Vorstellungen. Die zwei Policies, für die wir WMI-Filter verwenden wollen, wäre das die "schönste" Lösung und ich bin ein Typ, der halt sagt "wenn M$ uns das schon zur Verfügung stellt, dann will ich es nutzen und dann muss/sollte es auch funktionieren". Und wenn es das nicht tut, dann ist sicher irgendwo der Wurm drinnen - und ich sehe es als unseren Job (als IT'ler), diesen "Wurm" zu finden Auf gut Deutsch: ich weiß halt immer gern, warum etwas nicht so funktioniert, wie ich mir das vorstelle und suche so lange nach einer Lösung, bis es funktioniert.
Vielleicht hättest du - oder gerne auch jemand anderes - eine Idee, wo der Fehler sonst noch liegen könnte.
PS: der Client-Login an den anderen Standorten ohne DC funktionieren mit und ohne WMI-Filter übrigens einwandfrei, da gab es auch noch nie Probleme...
auch ich bedanke mich recht herzlich für die umfangreiche Antwort
Deine Annahme bzgl. anderer Standorte ist korrekt: wir haben mehrere Standorte, davon sind die Meisten mit einem eigenen DC ausgestattet, es gibt aber auch 2, 3 Standorte ohne DC (da stehen nur 2, 3 Rechner rum). Die Subnetze dieser Standorte sind alle mit der Site der Zentrale verknüpft - bislang gab's auch da kein Problem.
Ich habe deinen Tipp mal befolgt und einen Standort angelegt, das Subnetz der Außenstelle zugewiesen, eine Sitelink zwischen Zentrale und Außenstelle erstellt und alles mal durchrepliziert - Ergebnis bleibt aber dasselbe.
Was gegen die Vermutung spricht, dass die Clients der Zweigniederlassung einen anderen DC versuchen zu kontaktieren:
a) Als Logonserver wird immer / ausnahmslos der DC der Zentrale angezeigt. Ich gehe daher davon aus, dass er auch die Richtlinien dann von diesem DC abruft - oder liege ich hier falsch!?
b) Sobald ich den WMI-Filter von der GPO entferne, also die Richtlinie ohne Filter konfiguriere, werden alle Richtlinien einwandfrei abgearbeitet - und das nach gefühlten 100 Neustarts die ich durchgeführt habe, um die Problematik mit den DC's anderer Standorte auszuschließen.
c) Anmeldeskripte, die im Sysvol/Netlogon-Share liegen, werden tadellos ausgeführt.
Das ist ja gerade das Seltsame: die Gruppenrichtlinien werden problemlos abgearbeitet, so lange ich keinen WMI-Filter einsetze.
Zum WMI-Filter: wir haben ca. 30 Gruppenrichtlinienobjekte, die allesamt ohne irgendwelchen speziellen Schnick Schnack wie WMI-Filter, Delegierung etc. in unserer AD-Struktur verknüpft sind. Unsere Struktur entspricht im Übrigen ziemlich genau deinen Vorstellungen. Die zwei Policies, für die wir WMI-Filter verwenden wollen, wäre das die "schönste" Lösung und ich bin ein Typ, der halt sagt "wenn M$ uns das schon zur Verfügung stellt, dann will ich es nutzen und dann muss/sollte es auch funktionieren". Und wenn es das nicht tut, dann ist sicher irgendwo der Wurm drinnen - und ich sehe es als unseren Job (als IT'ler), diesen "Wurm" zu finden
Auf gut Deutsch: ich weiß halt immer gern, warum etwas nicht so funktioniert, wie ich mir das vorstelle und suche so lange nach einer Lösung, bis es funktioniert.Vielleicht hättest du - oder gerne auch jemand anderes - eine Idee, wo der Fehler sonst noch liegen könnte.
PS: der Client-Login an den anderen Standorten ohne DC funktionieren mit und ohne WMI-Filter übrigens einwandfrei, da gab es auch noch nie Probleme...
Schau mal z.Z. hier: http://social.technet.microsoft.com/wiki/contents/articles/10130.root-c ...
Da gibt es einen Absatz "WMI" mit Hinweisen auf ein paar KB. Trifft davon was zu?
Möglicherweise kommst Du auch mit WMIDiag weiter. Das ist ein VBScript, welches Du testweise als Startup-Script einrichten könntest, um zu sehen, was hinsichtlich WMI beim Starten des PC anders ist, als wenn Du das nach der Anmeldung testest.
Siehe auch: http://windowsitpro.com/scripting/resolve-wmi-problems-quickly-wmidiag
Da gibt es einen Absatz "WMI" mit Hinweisen auf ein paar KB. Trifft davon was zu?
Möglicherweise kommst Du auch mit WMIDiag weiter. Das ist ein VBScript, welches Du testweise als Startup-Script einrichten könntest, um zu sehen, was hinsichtlich WMI beim Starten des PC anders ist, als wenn Du das nach der Anmeldung testest.
Siehe auch: http://windowsitpro.com/scripting/resolve-wmi-problems-quickly-wmidiag
Sorry für die späte Rückmeldung - die Thematik ist auf Grund anderer Probleme zurückgestellt Ich werde mich bezüglich dem Problem melden, sobald ich eine Lösung dafür habe. Sollte jemanden noch etwas dazu einfallen: ich bin über jeden Rat dankbar.
Ich werde mich bezüglich dem Problem melden, sobald ich eine Lösung dafür habe. Sollte jemanden noch etwas dazu einfallen: ich bin über jeden Rat dankbar.
Es hat etwas gedauert, bis das Problem gelöst wurde. Und die Lösung ist ziemlich ... naja ... dämlich
Für die betroffene Außenstelle kam ein (sehr?) alter Netgear-Router zum Einsatz, der auch die Site-2-Site VPN-Einwahl regelte. Da wir an anderen Standorten bereits Probleme mit diesen Geräten hatten (langsame Internetverbindung), wurde nun dieses Gerät im Zuge eines Vor-Ort-Termins durch eine andere, hochwertige Firewall ersetzt. Und siehe da: die Gruppenrichtlinien werden tadellos angewendet, trotz WMI-Filter - nicht mehr hängt, der Rechner fährt tadellost hoch, einwandfreie Sache!
Ich vermute, dass der Client über die VPN-Strecke Pakete verloren hat und deshalb die Richtlinien nie sauber abgearbeitet wurden, stattdessen hat sich der Client bzw. WMI-Dienst aufgehängt. Seltsam ist zwar, dass der Datenzugriff über die VPN-Verbindung zwar langsam war, aber funktionierte und ein arbeiten möglich war. Vielleicht hat aber auch nur der alte Router einen an der Waffel...
Wie sagt der Engländer: again what learned
Wer also solche Probleme mit über VPN angebundenen Zweigniederlassungen hat, sollte evtl. mal die Firewall tauschen. Auch ein falsch konfigurierter MTU-Wert kann zu solchen Problemen führen, das hatten wir vor Jahren mal. In diesem Fall hier war's das aber nicht, sondern offenbar der alte Router.
Danke für's Beraten, emeriks!
Für die betroffene Außenstelle kam ein (sehr?) alter Netgear-Router zum Einsatz, der auch die Site-2-Site VPN-Einwahl regelte. Da wir an anderen Standorten bereits Probleme mit diesen Geräten hatten (langsame Internetverbindung), wurde nun dieses Gerät im Zuge eines Vor-Ort-Termins durch eine andere, hochwertige Firewall ersetzt. Und siehe da: die Gruppenrichtlinien werden tadellos angewendet, trotz WMI-Filter - nicht mehr hängt, der Rechner fährt tadellost hoch, einwandfreie Sache!
Ich vermute, dass der Client über die VPN-Strecke Pakete verloren hat und deshalb die Richtlinien nie sauber abgearbeitet wurden, stattdessen hat sich der Client bzw. WMI-Dienst aufgehängt. Seltsam ist zwar, dass der Datenzugriff über die VPN-Verbindung zwar langsam war, aber funktionierte und ein arbeiten möglich war. Vielleicht hat aber auch nur der alte Router einen an der Waffel...
Wie sagt der Engländer: again what learned
Wer also solche Probleme mit über VPN angebundenen Zweigniederlassungen hat, sollte evtl. mal die Firewall tauschen. Auch ein falsch konfigurierter MTU-Wert kann zu solchen Problemen führen, das hatten wir vor Jahren mal. In diesem Fall hier war's das aber nicht, sondern offenbar der alte Router.
Danke für's Beraten, emeriks!
