olc 18 Geschrieben 6. Dezember 2007 Melden Teilen Geschrieben 6. Dezember 2007 Hi, also das ist schon wirklich "komisch". Hier sind die Policies durch: USERENV(3b0.218) 08:13:38:968 PolicyChangedThread: Leaving Nur wenige Sekunden danach werden diverse userinit-Prozesse gestartet, die sehr, sehr lange laufen. Das ist sehr verwunderlich - warum werden die userinit-Prozesse mehrmals angestoßen? Meiner Meinung sollte das pro Benutzer nur ein Mal passieren... Interessant ist auch, daß der WMI-Prozess so lange braucht. Es sieht so aus, als wenn der Windows Update Dienst dort etwas anfragt oder initiiert, womit der Client eine Weile lang beschäftigt ist. Es gibt doch auch ein WMI-Logging. Vielleicht kann man da einmal hineinschauen? Ebenfalls wäre ein Blick in den Gerätemanager interessant, ob da alle Geräte mit den richtigen Treibern versorgt sind. Ggf. kannst Du auch einmal prüfen, ob Du manuell WMI -Abfragen problemlos durchführen kannst. USERENV(830.834) 08:13:41:109 LibMain: Process Name: C:\WINDOWS\system32\net.exe USERENV(948.94c) 08:13:48:031 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe USERENV(a2c.a30) 08:13:55:625 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(b4c.b50) 08:14:11:937 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe USERENV(f64.f68) 08:19:09:093 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe USERENV(fa4.fa8) 08:20:27:765 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe USERENV(fe8.fec) 08:20:28:546 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(3b0.3b4) 08:25:41:062 InitializePolicyProcessing: Initialised Machine Mutex/Events Der Desktop sollte dann hier zu sehen sein: USERENV(b6c.b70) 08:27:26:437 LibMain: Process Name: C:\WINDOWS\Explorer.EXE Falls der WMI-Ansatz keine Ergebnisse bringt: Was läuft auf den Clients für ein Virenscanner / Firewall (habe keinen entsprechenden Prozess finden können)? Falls dort soetwas installiert ist: Habt Ihr die testweise schon einmal abgeschaltet? Wenn Ihr den Client in eine OU ohne jegliche Policies / Scripts verschiebt, treten die Fehler dann ebenfalls auf? Waren in den Eventlogs Fehler zu finden? Kannst Du einmal einen Netzwerktrace ziehen damit man prüfen kann, was in der Zwischenzeit so über die Leitung geht? Ist wirklich schwierig einzugrenzen... Gruß olc Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 6. Dezember 2007 Autor Melden Teilen Geschrieben 6. Dezember 2007 Hi OLC Danke für deine tolle Hilfe!!! Das mit den userinit Prozessen hat mich eben auch irritiert. Der PC zu diesem Zeitpunkt einfach für "n" Minuten still und der PC resp. das Harddisk LED gibt keine Zeichen/Geräusche mehr aus. Anti-Viren Lösung ist von Trend Micro. Eine Firewall wird soweit keine verwendet, auch die von XP wurde mittels Policy deaktiviert. Ich werde den Start-Up ohne AV noch testen. Auch den Geräte-Manager prüfe ich nochmals! Explizit diesen PC habe ich noch nicht ohne GPO getestet, aber bei anderen PC's traten die Probleme zuvor auch in OU's ohne Policies auf. Die Verarbeitung ist allerdings ja schnell zuende, würdest du dennoch auf ein GPO Problem tendieren? Werden per Default auch WMI Abfragen auf einem Client ausgeführt? Nebst den GPO (ohne WMI Filter) wird noch WSUS in der Version 3 verwendet. Im Event-Log waren bei diesem PC noch folgende beide Fehler zu finden: Type: DCOM Event-ID: 10010 Description: The server {4991D34B-80A1-4291-83B6-3328366B9097} did not register with DCOM within the required timeout. Type: Winlogon Event-ID: 1217 Description: Execution of GPO scripts has timed out and have been terminated. Danke und Gruss Miguel Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 6. Dezember 2007 Melden Teilen Geschrieben 6. Dezember 2007 Hier was bei (Der DCOM-Server wird weiter unten erwähnt) ? EventID.Net Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 6. Dezember 2007 Autor Melden Teilen Geschrieben 6. Dezember 2007 Bei eventid.net habe ich geschaut und die Hinweise befolgt. BSp diesen hier: NUS Software Update Services Jedoch war der Ordner "C:\Documents and Settings\All Users\Application Data\Microsoft\Network" überall vorhanden. In Zusammenhang des DCOM Fehler konnte auf der BITS Service nicht gestartet werden. Kann dies ev. mit dem Logon-Problem zusammenhängen, oder ist dies eine andere Baustelle? Grüsse Miguel Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 6. Dezember 2007 Melden Teilen Geschrieben 6. Dezember 2007 Deaktiviere "Automatische Updates" und "BITS" mal und starte neu ... Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 6. Dezember 2007 Melden Teilen Geschrieben 6. Dezember 2007 Hi, ja, das Deaktivieren des wuauclt und bits ist nach den Beobachtungen oben eine gute Idee. Danach wäre interessant, ob die WMI-Abfrage weiterhin hängt. In Richtung "GPO-Verarbeitung" geht es - denke ich zum jetzigen Zeitpunkt - eher nicht: Die GPOs sind ja als solches schon abgearbeitet. Jedoch können natürlich die Settings, die in den GPOs gesetzt wurden, durchaus auch einen Fehler nach sich ziehen. ;) Warten wir einmal die WSUS / WMI Geschichte ab und schauen dann weiter. Gruß olc Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 7. Dezember 2007 Autor Melden Teilen Geschrieben 7. Dezember 2007 Hallo zusammen Ich habe den BITS Service nun von manuell auf deaktiviert gestellt. Dazu mehr am Montag. Allerdings ist mir aufgefallen, dass der erwähnte DCOM Fehler heute nicht im Log aufgeführt war, dennoch war der Login langsam... Zur Sicherheit habe ich mir nochmals das Userenv-Log gezogen. userenv_071207.txt Auch hier haben die beiden Dienste userinit.exe und wmiprvse.exe eine lange Zeit benötigt. Die Hardware habe ich auch noch angeschaut. Diese scheint korrekt geladen zu sein. Es sind soweit keine Fehlermeldungen im HW-Manager ersichtlich. Was mir noch zugetragen wurde: Wenn der User den PC in diesem Stadium "abwürgt", also abschaltet und wieder startet funktioniert der login meistens schnell?! Gruss und Danke Miguel Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 7. Dezember 2007 Melden Teilen Geschrieben 7. Dezember 2007 Nur den BITS oder auch "Automatische Updates" ? Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 13. Dezember 2007 Autor Melden Teilen Geschrieben 13. Dezember 2007 Hallo zusammen So, nun habe ich endlich wieder eine Feedback zu diesem Thread ;) Wie letzte Woche geschrieben habe ich den "BITS" Service deaktiviert. Dies hat gemäss Userenv-Log noch zu keiner Besserung geführt. Nachdem noch den Service "Automatische Updates" deaktiviert wurde, geht der Logon flot. Der User hat ebenfals bestätigt, dass der Anmelde-Vorgang in der letzten Zeit wieder gut ist. Dies ist auch in diesem aktuellen Userenv-Log ersichtlich: userenv_BITS-AU.log Das scheint nun effektiv auf diesen Service (WMI Abfrage?) zurückzuführen zu sein. Als Update Server wird übrigens WSUS in der Version 3 eingesetzt. Grüsse Miguel Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 26. Dezember 2007 Melden Teilen Geschrieben 26. Dezember 2007 Hi, also wie oben schon vermutet die WMI Abfrage...? War noch etwas im Eventlog eines betroffenen Clients zu sehen oder ist das Thema für Dich damit "erledigt"? Gruß olc Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 26. Dezember 2007 Autor Melden Teilen Geschrieben 26. Dezember 2007 Hallo olc Genau, der WUAU verursachte die Logon-Probleme. Nun ist der Übeltäter gefunden, aber das Problem habe ich noch nicht gelöst (hatte allerdings aktuell ein anderes Projekt). Im Event-Log ist nichts mehr zu sehen. Hast du ev. gerade eine gute Idee? Grüsse Miguel Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 26. Dezember 2007 Melden Teilen Geschrieben 26. Dezember 2007 N'Abend, Genau, der WUAU verursachte die Logon-Probleme. <Haarspalterei>Na ja, nicht ganz - genau genommen scheint ja ein WMI Query das Problem zu verursachen. Der WUAU initiiert zwar vermutlich die WMI Abfrage, ist jedoch eher das Opfer des Prozesses oder?</Haarspalterei> Hast du ev. gerade eine gute Idee? Nö. :D Mal im Ernst: Kenne mich mit WMI nicht so gut aus. Aber ich würde versuchen das WMI Logging auf einem Testclient zu aktivieren und dann schauen, ob ich etwas daraus erkennen kann. Schau mal hier hinein: WMI Troubleshooting (Windows) Viele Grüße olc Zitieren Link zu diesem Kommentar
zuschauer 10 Geschrieben 26. Dezember 2007 Melden Teilen Geschrieben 26. Dezember 2007 Hi @all ! Das es bei dem WSUS-Server um einen WSUS Vers.3 geht, welche Version des WSUS-Clients ist denn auf dem Client installiert ? Nach meinem Kenntnisstand (ca 8 Wochen alt - also steinalt) wird der WSUS-Client Ver.3 immer noch nicht automatisch per WSUS verteilt ? Zitieren Link zu diesem Kommentar
Sunny61 772 Geschrieben 26. Dezember 2007 Melden Teilen Geschrieben 26. Dezember 2007 Das es bei dem WSUS-Server um einen WSUS Vers.3 geht, welche Version des WSUS-Clients ist denn auf dem Client installiert ? Nach meinem Kenntnisstand (ca 8 Wochen alt - also steinalt) wird der WSUS-Client Ver.3 immer noch nicht automatisch per WSUS verteilt ? Der WSUS 3.0 kommt mit dem Client .374 daher, d.h. jeder Client der sich erstmalig zum WSUS 3.0 verbindet, bekommt den o.g. Client installiert. Es gibt zwar einen aktuelleren, den .381er, der wird z.Zt. nur via WU/MU installiert/angeboten. Daran kann es also nicht liegen. Der OP kann aber trotzdem den aktuellen WU-Agent installieren: http://download.windowsupdate.com/WindowsUpdate/redist/standalone/7.0.6000.381/WindowsUpdateAgent30-x86.exe Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 27. Dezember 2007 Autor Melden Teilen Geschrieben 27. Dezember 2007 Hallo zusammen Nun ja, WMI habe ich bisher auch eher nebensächlich behandelt ;) Widme mich mal dem geposteten Link (Danke!). Bezüglich WSUS 3, der neue Client wurde automatisch deployed. Den exaken Build kann ich aber nicht nennen. Grüsse Miguel Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.