7
Nach Windowsanmeldung hängt der Rechner für ca. 15 Minuten
Hallo zusammen - ich wende mich mal wieder an die Macht der Administratoren 
Kurz zur Umgebung:
- Typische Windows Serverumgebung mit ADS, Exchange, DNS, DHCP usw.
- Ca. 1500 Clients mit einer Mischumgebung aus Dell Latitude D610-D630 und jetzt auch HP Elitebook 6930p und alle mit Win XP SP3
- Diverse (ca. 20) integrierte kleinere ADs in Landesgesellschaften die per VPN angebunden sind.
- Installationen über Matrix42 Empirum
- Der Fileserver (server11) ist bei I: (Bereiche) ein DFS-Knoten
Zum Problem:
Die (neuen) HP-Clients wurden normal installiert und in die Domäne aufgenommen.
Einige - nicht alle... - der installierten Geräte weißen jetzt das Problem auf, dass solange die Default Domain Policy aktiv ist (welche die Netzlaufwerke verbindet) und der Rechner NICHT am Netzwerk hängt, man direkt nach der Anmeldung ca. 15-20 Minuten warten darf bis dann der Desktop kommt. STRG-ALT-ENTF ist nicht möglich, STRG-SHIFT-ESC ebenfalls nicht, einziges was meistens hilft ist zuklappen des Deckels so dass er in den Standy geht und danach neu anmelden oder eben das Netzwerkkabel einstecken.
Sobald die Policy von dem User der angemeldet wird entfernt ist gibt es beim nächsten Neustart keine Probleme mehr.
das Loginscript liegt im \\de.domain.com\SYSVOL\de.domain.com\scripts\ und heißt "LoginScriptDOMAIN.CMD"
Inhalt:
net use i: /del
net use j: \\server11\Appdata
net use i: \\server11\Bereiche
net use p: \\server11\Projekte
net use z: \\server11\Public
net use t: \\server11\Themen
Wir haben echt schon alles durch und auch schon alles versucht. Im Eventlog kommt zwar, dass er das Loginscript nicht ausführen konnte (Userinit Kennung 1000) aber das scheint normal, da es auch auf den Clients wo alles funktioniert geht. Übrigens sind die Probleme AUSSCHLIEßLICH auf einigen HP-Clients. Bei DELL-Clients alles super.
Netzwerkkarten Treiberupdates wurden schon versucht - keine Verbesserung.
Komisch aufgefallen auf einem problematischen PC bei einem loggingversuch mit "Bootvis" is das die zwei Dateien "mrxdav.sys" und "fltmgr.sys" einen Delay von 77,7 secs haben. Das ist zwar nicht annähernd solange wie der PC wirklich hängt, aber vielleicht hängt davor und danach das Bootvis selber auch und somit kommt das zustande. Google konnte mir nicht viel zu den Files sagen, außer das die mrxdav wohl was mit WebDAV laufwerken zu tun hat (die wir nicht nutzen, aber vielleicht ist bei DFS-Knoten der gleiche Treiber?!).
Bei einem Client ohne Probleme werden beim logging die zwei Files garnicht aufgeführt.
Danke für eure Hilfe!
Kurz zur Umgebung:
- Typische Windows Serverumgebung mit ADS, Exchange, DNS, DHCP usw.
- Ca. 1500 Clients mit einer Mischumgebung aus Dell Latitude D610-D630 und jetzt auch HP Elitebook 6930p und alle mit Win XP SP3
- Diverse (ca. 20) integrierte kleinere ADs in Landesgesellschaften die per VPN angebunden sind.
- Installationen über Matrix42 Empirum
- Der Fileserver (server11) ist bei I: (Bereiche) ein DFS-Knoten
Zum Problem:
Die (neuen) HP-Clients wurden normal installiert und in die Domäne aufgenommen.
Einige - nicht alle... - der installierten Geräte weißen jetzt das Problem auf, dass solange die Default Domain Policy aktiv ist (welche die Netzlaufwerke verbindet) und der Rechner NICHT am Netzwerk hängt, man direkt nach der Anmeldung ca. 15-20 Minuten warten darf bis dann der Desktop kommt. STRG-ALT-ENTF ist nicht möglich, STRG-SHIFT-ESC ebenfalls nicht, einziges was meistens hilft ist zuklappen des Deckels so dass er in den Standy geht und danach neu anmelden oder eben das Netzwerkkabel einstecken.
Sobald die Policy von dem User der angemeldet wird entfernt ist gibt es beim nächsten Neustart keine Probleme mehr.
das Loginscript liegt im \\de.domain.com\SYSVOL\de.domain.com\scripts\ und heißt "LoginScriptDOMAIN.CMD"
Inhalt:
net use i: /del
net use j: \\server11\Appdata
net use i: \\server11\Bereiche
net use p: \\server11\Projekte
net use z: \\server11\Public
net use t: \\server11\Themen
Wir haben echt schon alles durch und auch schon alles versucht. Im Eventlog kommt zwar, dass er das Loginscript nicht ausführen konnte (Userinit Kennung 1000) aber das scheint normal, da es auch auf den Clients wo alles funktioniert geht. Übrigens sind die Probleme AUSSCHLIEßLICH auf einigen HP-Clients. Bei DELL-Clients alles super.
Netzwerkkarten Treiberupdates wurden schon versucht - keine Verbesserung.
Komisch aufgefallen auf einem problematischen PC bei einem loggingversuch mit "Bootvis" is das die zwei Dateien "mrxdav.sys" und "fltmgr.sys" einen Delay von 77,7 secs haben. Das ist zwar nicht annähernd solange wie der PC wirklich hängt, aber vielleicht hängt davor und danach das Bootvis selber auch und somit kommt das zustande. Google konnte mir nicht viel zu den Files sagen, außer das die mrxdav wohl was mit WebDAV laufwerken zu tun hat (die wir nicht nutzen, aber vielleicht ist bei DFS-Knoten der gleiche Treiber?!).
Bei einem Client ohne Probleme werden beim logging die zwei Files garnicht aufgeführt.
Danke für eure Hilfe!
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: 115447
Url: https://administrator.de/forum/nach-windowsanmeldung-haengt-der-rechner-fuer-ca-15-minuten-115447.html
Ausgedruckt am: 31.12.2024 um 21:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo das Problem kommt mir bekannt vor, habe das gleiche Problem bei nem Kunden gehabt allerdings mit IBM PC.
Folgende Lösungsvorschlage:
Zu allererst solltest du sämtliche Wartungsarbeiten mit windows durchführen
1. Defrag der festplatte
2. Scandisk
3. Registry Cleaner
dann solltest du prüfen welche Herstellerspezifischen Softwares installiert sind
z.B. IBM AutoUpdate Software
Sonstige Tools des Systemherstellers wie Infokanal Newsletter Brenner etc.
ausserdem tritt das Problem gerne auf wenn du Benutzer hast mit erweiterten rechten unter welchen Programme installiert und konfiguriert wurden welche in die Windows Registry schreiben .... so auch in den autostart ..... testen ob dies das Problem ist kannst du indem du während des anmeldevorgangs die shift-taste gedrückts hälst das unterbindet den autostart des betriebssystems bzw. des users also shift taste ab winxp oder was sosnt bildschirm gedrückt halten
wahrscheinlich hast du ein Programm installiert welches von einem administrativen user in gang gesetzt wurde wenn nun regitry einträge von mehreren beuntzern verwendt werden jedoch der eigentliche besitzer höhere rechte hatte können diese nicht aktualisiert werden was jedoch bei schlecht programmierten oder falsch installierten autostartprogrammen gerne der fall ist .. bedeutet dann das der rechner in ner schleife hängt die das programm im hintergrund fährt
Befehl ausführen ergebnis in die registry "schreibfehler" ergebnius prüfen falches ergebnis vorgang von vorne je nachdem um was es sich handelt oder wie oft der programmierer die schleife wiederholt bevor er sie abbricht bzw. wie sie wiederholt wird weil kein abbruch vorgesehen ist und windows irgendwann den vorgang abbricht kann das länger gehen ... was auch gerne passiert ist das benutzer nachträglich eingechränkt werden alo registrywerte selbst mit erhöhten rechten an stellen geschrieben haben auf die sie jetzt keinen vollzugriff mehr haben und diese versucht der rechner dann während des anmeldevorgangs zu aktualisieren bis er sagt ende aus
die ereignis protokollierung von windows xp zeigt die nur systemrelevante fehler an also fehler die bei systemdiensten auftreten und die für die protokollierung definiert sind deshalb kein ereignis im logfile...
Beispiel
Laufwerk X wird mit rechten von benutzer01 verbunden...
Benutzer01 hat adminrechte
jetzt schreibt windows xp informationen darüber in die regitry um den vorgang beim nächsten mal zu beschleunigen (deltabit)
dann wird diese anmeldung mehrmals erneuert und windows setzt den gültigkeit wert immer wieder hoch...
der neue admin ist ein versierter admin und sagt hier muessen dedizierte rechte vergeben werden und ändert kurzerhand die gruppenzuordnung bzw. berechtigungen des benutzer01 auf domänenbenutzer jetzt ändert sich GUID des users nicht also das profil bleibt erhalten im profil steht jetzt verbinden mit unter den bedingungen XYZ aha nun will der benutzer01 diese werte aktulalisieren und windows stellt fest halt das ein admin geschrieben und nun wills ein benutzer löschen was wäre denn windows denn für ein nt system wenn der benutzer adminwerte ersetzen kann
Folgende Lösungsvorschlage:
Zu allererst solltest du sämtliche Wartungsarbeiten mit windows durchführen
1. Defrag der festplatte
2. Scandisk
3. Registry Cleaner
dann solltest du prüfen welche Herstellerspezifischen Softwares installiert sind
z.B. IBM AutoUpdate Software
Sonstige Tools des Systemherstellers wie Infokanal Newsletter Brenner etc.
ausserdem tritt das Problem gerne auf wenn du Benutzer hast mit erweiterten rechten unter welchen Programme installiert und konfiguriert wurden welche in die Windows Registry schreiben .... so auch in den autostart ..... testen ob dies das Problem ist kannst du indem du während des anmeldevorgangs die shift-taste gedrückts hälst das unterbindet den autostart des betriebssystems bzw. des users also shift taste ab winxp oder was sosnt bildschirm gedrückt halten
wahrscheinlich hast du ein Programm installiert welches von einem administrativen user in gang gesetzt wurde wenn nun regitry einträge von mehreren beuntzern verwendt werden jedoch der eigentliche besitzer höhere rechte hatte können diese nicht aktualisiert werden was jedoch bei schlecht programmierten oder falsch installierten autostartprogrammen gerne der fall ist .. bedeutet dann das der rechner in ner schleife hängt die das programm im hintergrund fährt
Befehl ausführen ergebnis in die registry "schreibfehler" ergebnius prüfen falches ergebnis vorgang von vorne je nachdem um was es sich handelt oder wie oft der programmierer die schleife wiederholt bevor er sie abbricht bzw. wie sie wiederholt wird weil kein abbruch vorgesehen ist und windows irgendwann den vorgang abbricht kann das länger gehen ... was auch gerne passiert ist das benutzer nachträglich eingechränkt werden alo registrywerte selbst mit erhöhten rechten an stellen geschrieben haben auf die sie jetzt keinen vollzugriff mehr haben und diese versucht der rechner dann während des anmeldevorgangs zu aktualisieren bis er sagt ende aus
die ereignis protokollierung von windows xp zeigt die nur systemrelevante fehler an also fehler die bei systemdiensten auftreten und die für die protokollierung definiert sind deshalb kein ereignis im logfile...
Beispiel
Laufwerk X wird mit rechten von benutzer01 verbunden...
Benutzer01 hat adminrechte
jetzt schreibt windows xp informationen darüber in die regitry um den vorgang beim nächsten mal zu beschleunigen (deltabit)
dann wird diese anmeldung mehrmals erneuert und windows setzt den gültigkeit wert immer wieder hoch...
der neue admin ist ein versierter admin und sagt hier muessen dedizierte rechte vergeben werden und ändert kurzerhand die gruppenzuordnung bzw. berechtigungen des benutzer01 auf domänenbenutzer jetzt ändert sich GUID des users nicht also das profil bleibt erhalten im profil steht jetzt verbinden mit unter den bedingungen XYZ aha nun will der benutzer01 diese werte aktulalisieren und windows stellt fest halt das ein admin geschrieben und nun wills ein benutzer löschen was wäre denn windows denn für ein nt system wenn der benutzer adminwerte ersetzen kann
moin,
Also wie ich das verstanden habe, dauert es nur so lange wenn die Clients nicht im Netz sind, oder?
Wir hatten mal das ähnliche Problem, wenn Clients nicht im Netz waren haben die mehrere Minuten gebraucht.
Das Problem waren die Logon Scripts / Startscripte in Verbdinugn mit dem Dienst "WebClient".
Der Dienst wird auch für WebDAV und so ein zeug benutzt. Versuch den Dienst mal zu Deaktivieren.
Bei uns hat geholfen.
Da wir aber den Dienst trotzdem benötigen haben wir das Anmeldescript und Abmeldescript geändert, d.h. bei der Anmeldung wird der DIenst gestartet beim Abmelden Deaktiviert (nicht gestopt).
Gruß ich
Also wie ich das verstanden habe, dauert es nur so lange wenn die Clients nicht im Netz sind, oder?
Wir hatten mal das ähnliche Problem, wenn Clients nicht im Netz waren haben die mehrere Minuten gebraucht.
Das Problem waren die Logon Scripts / Startscripte in Verbdinugn mit dem Dienst "WebClient".
Der Dienst wird auch für WebDAV und so ein zeug benutzt. Versuch den Dienst mal zu Deaktivieren.
Bei uns hat geholfen.
Da wir aber den Dienst trotzdem benötigen haben wir das Anmeldescript und Abmeldescript geändert, d.h. bei der Anmeldung wird der DIenst gestartet beim Abmelden Deaktiviert (nicht gestopt).
Gruß ich
Hey,
das hat sehr vielversprechend geklungen aber hat leider auch nichts gebracht. Nach Deaktivierung des dienstes ist immernoch alles beim alten.
Komisch ist, dass es ab und zu dann doch funktioniert und besonders komisch, dass es mit anderen Laptops des gleichen Typs funktioniert!
Einige Laptops wurden sogar von Hand installiert und die Treiber usw. auch.
Ich tippe mittlerweile trotzdem auf Treiberprobleme mit den HP Netzwerkkarten... aber es sind die aktuellsten jeweils drauf...
An der Hardware kanns auch nicht liegen - ein Festplattentausch zwischen zwei identischen Systemen hat hervorgebracht, dass ein funktionierendes System und ein nicht funktionierendes System im jeweils anderen Laptop sich genau gleich verhalten.
Es hat also auf jeden Fall etwas mit Windows oder den Treibern zu tun!
Weitere Ideen?
das hat sehr vielversprechend geklungen aber hat leider auch nichts gebracht. Nach Deaktivierung des dienstes ist immernoch alles beim alten.
Komisch ist, dass es ab und zu dann doch funktioniert und besonders komisch, dass es mit anderen Laptops des gleichen Typs funktioniert!
Einige Laptops wurden sogar von Hand installiert und die Treiber usw. auch.
Ich tippe mittlerweile trotzdem auf Treiberprobleme mit den HP Netzwerkkarten... aber es sind die aktuellsten jeweils drauf...
An der Hardware kanns auch nicht liegen - ein Festplattentausch zwischen zwei identischen Systemen hat hervorgebracht, dass ein funktionierendes System und ein nicht funktionierendes System im jeweils anderen Laptop sich genau gleich verhalten.
Es hat also auf jeden Fall etwas mit Windows oder den Treibern zu tun!
Weitere Ideen?
langsameverbindungen erkennen in den domänenrichtlinien deaktivieren...
versuchen sich als administrator@domöne.xxx anmelden zeit vergleichen.....
manche notebooks haben das problem das sie ihre cpu leistung verringern bzw.
weniger saft am sysetmbus haben das ist ein profil welches nichts mit netzanschluss
zu tun hat das verringert die übertragungsgeschwindigkeit....
switchkonfiguration prüfen zwecks media speed eine 10 Mbit zu 100mbit oder 1000mbit wird im netz als langsame verbindung erkannt ausserdem vernachlässigt windows server diese verbindung oder debient sie gar über web
anmeldenamen des netBIOS (NT4) oder Active directory
netzwerkkarten framelänge standard??
Mediasensemanuell einstellen....
switches unterstützen wirklich alle protokolle ??
wie gesagt am wahrscheinlichsten ist die sache mit den registry einträgen
versuchen sich als administrator@domöne.xxx anmelden zeit vergleichen.....
manche notebooks haben das problem das sie ihre cpu leistung verringern bzw.
weniger saft am sysetmbus haben das ist ein profil welches nichts mit netzanschluss
zu tun hat das verringert die übertragungsgeschwindigkeit....
switchkonfiguration prüfen zwecks media speed eine 10 Mbit zu 100mbit oder 1000mbit wird im netz als langsame verbindung erkannt ausserdem vernachlässigt windows server diese verbindung oder debient sie gar über web
anmeldenamen des netBIOS (NT4) oder Active directory
netzwerkkarten framelänge standard??
Mediasensemanuell einstellen....
switches unterstützen wirklich alle protokolle ??
wie gesagt am wahrscheinlichsten ist die sache mit den registry einträgen
Hey,
cknemessis danke für deine aktive beteiligung aber deine Ideen gehen in die völlig falsche Richtung.
Wir haben das Problem ja bei so gut wie allen Rechnern (HP), da brauch ich nichts mit Defrag etc. machen. Auch solche dinge wie CPU-Leistung etc. machen sicher keine 15 Minuten oder länger aus.
Mediasens etc. protokolle und auch framelänge wären eine Erklärung wenn das Problem MIT Netzwerk auftreten würde - es ist ja aber nur OHNE Netzwerk ein Problem.
Aber wir haben das Problem jetzt "gelöst" bzw. eher analysiert.
Wir nutzen Empirum als Softwaremanagementsystem und haben dort jede Menge Installerpakete. Einige brauchen für eine Installation einen Dienst der sich Empirum Agent nennt und dieser muss für diese Pakete als ein Domänenadmin laufen um alle Pakete richtig zu installieren.
Genau das war das Problem. Der Dienst lief unter dem Benutzerkonto eines Domänenadmin. Dazu kam unsere Safeboot Installation, die die Windowsanmeldung ja erheblich beschleunigt und sofort nach dem hochfahren einloggt. Anscheinend ist diese Kombo das Problem.
Bei einem PC wo von Hand eingeloggt wird tritt das Problem deutlich weniger oft auf, da man -manchmal- viel länger für den Login braucht.
Für alle die kein Safeboot haben: Safeboot fragt das Windowspasswort schon vor dem Booten ab und loggt dann direkt beim starten ein.
-> Domänenkontos sind für Dienste anscheinend keine wirklich gute Lösung. Das gleiche Problem besteht bei einem Adminkollegen, der einen anderen Dienst als Domänenadmin startet. Es scheint also echt dort dran zu liegen. Komisch bleibt trotzdem warum das Problem bei DELL anscheinend nicht besteht!
cknemessis danke für deine aktive beteiligung aber deine Ideen gehen in die völlig falsche Richtung.
Wir haben das Problem ja bei so gut wie allen Rechnern (HP), da brauch ich nichts mit Defrag etc. machen. Auch solche dinge wie CPU-Leistung etc. machen sicher keine 15 Minuten oder länger aus.
Mediasens etc. protokolle und auch framelänge wären eine Erklärung wenn das Problem MIT Netzwerk auftreten würde - es ist ja aber nur OHNE Netzwerk ein Problem.
Aber wir haben das Problem jetzt "gelöst" bzw. eher analysiert.
Wir nutzen Empirum als Softwaremanagementsystem und haben dort jede Menge Installerpakete. Einige brauchen für eine Installation einen Dienst der sich Empirum Agent nennt und dieser muss für diese Pakete als ein Domänenadmin laufen um alle Pakete richtig zu installieren.
Genau das war das Problem. Der Dienst lief unter dem Benutzerkonto eines Domänenadmin. Dazu kam unsere Safeboot Installation, die die Windowsanmeldung ja erheblich beschleunigt und sofort nach dem hochfahren einloggt. Anscheinend ist diese Kombo das Problem.
Bei einem PC wo von Hand eingeloggt wird tritt das Problem deutlich weniger oft auf, da man -manchmal- viel länger für den Login braucht.
Für alle die kein Safeboot haben: Safeboot fragt das Windowspasswort schon vor dem Booten ab und loggt dann direkt beim starten ein.
-> Domänenkontos sind für Dienste anscheinend keine wirklich gute Lösung. Das gleiche Problem besteht bei einem Adminkollegen, der einen anderen Dienst als Domänenadmin startet. Es scheint also echt dort dran zu liegen. Komisch bleibt trotzdem warum das Problem bei DELL anscheinend nicht besteht!
gerne immer wieder aber lies doch bitte meine erste antwort zweiter absatz dann löst sich betstimmt auch das problem mit dem admin ich glaube im zweiten abschnitt habe ich die richtung angegeben... wie gesagt eine software mit adminrechten benutzerprofil mit entsrepchendem fehler muss neu angelegt werden
bin gespannt woran es schlussendlich liegt
bin gespannt woran es schlussendlich liegt
Hey,
das Problem mit dem administrator ist schon gelöst und zwar auf die gleiche Art und Weise. Einfach den Dienst als "Lokales Systemkonto" laufen lassen und alles ist super. Oder einfach vor der Anmeldung etwas warten, das scheint auch zu helfen (was uns ja mit Safeboot nichts bringt).
Das Problem ist sicher bei DELL genauso, nur da dort kein Safeboot installiert ist (wurde erst mit HP eingeführt) ist die Anmeldung dort langsamer und somit kein Problem.
Somit Problem fixed und ich hab mir nen Kasten von meinem Chef verdient
Grüße
das Problem mit dem administrator ist schon gelöst und zwar auf die gleiche Art und Weise. Einfach den Dienst als "Lokales Systemkonto" laufen lassen und alles ist super. Oder einfach vor der Anmeldung etwas warten, das scheint auch zu helfen (was uns ja mit Safeboot nichts bringt).
Das Problem ist sicher bei DELL genauso, nur da dort kein Safeboot installiert ist (wurde erst mit HP eingeführt) ist die Anmeldung dort langsamer und somit kein Problem.
Somit Problem fixed und ich hab mir nen Kasten von meinem Chef verdient
Grüße
