11
Computereinstellungen werden übernommen... Rechner startet neu!
Hallo Leute,
habe seid heute Morgen in unserer Firma ein ganz merkwürdiges Problem.
Es sind mittlerweile fünf Rechner gemeldet worden die ganz normal hochfahren, bis zur Meldung "Computereinstellungen werden übernommen" kommen und dann noch vor der Benutzeranmeldung einen Neustart ohne Meldungen hinlegen.
Angefangen hat das Gestern mit einem Notebook wo ich erst den Verdacht hatte das es vielleich ein Plattenschaden sein könnte.
Was jetzt viele von euch denken ist sichehherlich das der Typ sich doch bestimmt einen Virus eingefangen hat. Zu diesem Theme kann ich nur sagen das die Virenscanner und die Firewall keinen einziegen Eintrag aufweisen.
Ich habe eher die Vermutung das es vielleicht etwas mit einem der Microsoft Updates zu tun hat. Wir haben am Freitag folgene Updates freigegeben:
Microsoft .NET Framework 3.0
Remotedesktopverbindung /(Terminalclient 6.0) für Windows Server 2003
Remotedesktopverbindung /(Terminalclient 6.0) für Windows XP
Stammzertifikatupdate
Update für Windwos SharePoint Services für Windows Server 2003
Ich weiß mitlerweile wie ich das Problem umgehen kann, und zwar beim Start des Client die F8 Taste drücken und ind den Erweiterten Windows-Startoptionen "Letzte als funktionierende Konfiguration" auswählen.
Damit startet der Client wieder ganz normal.
Zur Info, alle betroffenen Clients waren Windows XP SP2 Kisten.
Ich kann es mir nicht erklären und versuche jetzt mal auf diesem Weg festzustellen ob seit ein paar Tagen vielleicht noch andere das gleiche Problem haben.
mfg
Thomas
habe seid heute Morgen in unserer Firma ein ganz merkwürdiges Problem.
Es sind mittlerweile fünf Rechner gemeldet worden die ganz normal hochfahren, bis zur Meldung "Computereinstellungen werden übernommen" kommen und dann noch vor der Benutzeranmeldung einen Neustart ohne Meldungen hinlegen.
Angefangen hat das Gestern mit einem Notebook wo ich erst den Verdacht hatte das es vielleich ein Plattenschaden sein könnte.
Was jetzt viele von euch denken ist sichehherlich das der Typ sich doch bestimmt einen Virus eingefangen hat. Zu diesem Theme kann ich nur sagen das die Virenscanner und die Firewall keinen einziegen Eintrag aufweisen.
Ich habe eher die Vermutung das es vielleicht etwas mit einem der Microsoft Updates zu tun hat. Wir haben am Freitag folgene Updates freigegeben:
Microsoft .NET Framework 3.0
Remotedesktopverbindung /(Terminalclient 6.0) für Windows Server 2003
Remotedesktopverbindung /(Terminalclient 6.0) für Windows XP
Stammzertifikatupdate
Update für Windwos SharePoint Services für Windows Server 2003
Ich weiß mitlerweile wie ich das Problem umgehen kann, und zwar beim Start des Client die F8 Taste drücken und ind den Erweiterten Windows-Startoptionen "Letzte als funktionierende Konfiguration" auswählen.
Damit startet der Client wieder ganz normal.
Zur Info, alle betroffenen Clients waren Windows XP SP2 Kisten.
Ich kann es mir nicht erklären und versuche jetzt mal auf diesem Weg festzustellen ob seit ein paar Tagen vielleicht noch andere das gleiche Problem haben.
mfg
Thomas
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: 50827
Url: https://administrator.de/contentid/50827
Ausgedruckt am: 08.11.2024 um 10:11 Uhr
11 Kommentare
Neuester Kommentar
Abend,
also am Microsoft .NET Framework 3.0 und Stammzertifikatupdate liegt es (denke ich) nicht. Wir haben hier die Updates auch auf WindowsXP SP2 Prof. eingespielt ohne Probleme!
Zu den anderen Updates kann ich dir nichts sagen, weil wir diese einfach nicht installieren lassen!
Aber ich installier doch einfach mal 1 Update nach dem anderen und starte dazwischen immer wieder neu. Somit bekommst du schnell mit, woran es liegt.
Aber vorrest würde ich das verteilen der updates einstellen. Sonst hast du nachher viel zu tun (vielleicht)!!
Gruß
Dani
also am Microsoft .NET Framework 3.0 und Stammzertifikatupdate liegt es (denke ich) nicht. Wir haben hier die Updates auch auf WindowsXP SP2 Prof. eingespielt ohne Probleme!
Zu den anderen Updates kann ich dir nichts sagen, weil wir diese einfach nicht installieren lassen!
Aber ich installier doch einfach mal 1 Update nach dem anderen und starte dazwischen immer wieder neu. Somit bekommst du schnell mit, woran es liegt.
Aber vorrest würde ich das verteilen der updates einstellen. Sonst hast du nachher viel zu tun (vielleicht)!!
Gruß
Dani
Guten Morgen!
Das Problem ist das es gar nicht alle Clients betrifft. Es stehen z.B. in einer Abteilung 10 Rechner, davon haben 6 Rechner das Problem.
In der ganzen Firma betrifft es ca. 8 von 75 Rechner. Alle haben die gleichen Updates bekommen.
Ich gehe auch vor jedem Update hin und teste diese inerhalb einer VM, um sicher zu gehen das alles noch läuft nach dem Rollout. Auch diesesmal hat es keine Probleme gegeben. In der VM läuft ja auch noch alles, nur bei ein paar Client nicht.
Werde mal anfangen systematisch alles installierten Update zu deinstallieren.
Eine andere Lösung fällt mir im Augenblick nicht ein.
Wenn du was finden solltest wäre das Super. Vielleicht bringt mich das der Lösung einen Schritt weiter. Schon mal vielen Dank!
Gruß, Thomas...
Das Problem ist das es gar nicht alle Clients betrifft. Es stehen z.B. in einer Abteilung 10 Rechner, davon haben 6 Rechner das Problem.
In der ganzen Firma betrifft es ca. 8 von 75 Rechner. Alle haben die gleichen Updates bekommen.
Ich gehe auch vor jedem Update hin und teste diese inerhalb einer VM, um sicher zu gehen das alles noch läuft nach dem Rollout. Auch diesesmal hat es keine Probleme gegeben. In der VM läuft ja auch noch alles, nur bei ein paar Client nicht.
Werde mal anfangen systematisch alles installierten Update zu deinstallieren.
Eine andere Lösung fällt mir im Augenblick nicht ein.
Wenn du was finden solltest wäre das Super. Vielleicht bringt mich das der Lösung einen Schritt weiter. Schon mal vielen Dank!
Gruß, Thomas...
Hi,
schau mal vielleicht noch im Ereignisprotokoll des jeweiligen Clients nach. Ob dort Auffälligkeiten bzw. ne Ursache steht!
Gruß
Dani
schau mal vielleicht noch im Ereignisprotokoll des jeweiligen Clients nach. Ob dort Auffälligkeiten bzw. ne Ursache steht!
Gruß
Dani
Hi,
das einziege was mir aufgefallen ist war diese Meldung:
Quelle: .NET Runtime
... Unable to open shim database version registry key - v2.0.50727.00000
Steht noch ein wenig mehr aber das ist nicht so interessant.
Diesen Fehler konnte ich aber schon durch eine Berechtigungsänderung eines Registry-Schlüssels durch eine GPO ändern.
Hab heute leider keine Zeit gehabt mich weiter um dieses Problem zu kümmern (deinstallieren von Updates usw.) Werde wohl heute Abend noch ein paar Stunden machen damit sich Morgen wieder alle betroffenen Clients anmelden können.
das einziege was mir aufgefallen ist war diese Meldung:
Quelle: .NET Runtime
... Unable to open shim database version registry key - v2.0.50727.00000
Steht noch ein wenig mehr aber das ist nicht so interessant.
Diesen Fehler konnte ich aber schon durch eine Berechtigungsänderung eines Registry-Schlüssels durch eine GPO ändern.
Hab heute leider keine Zeit gehabt mich weiter um dieses Problem zu kümmern (deinstallieren von Updates usw.) Werde wohl heute Abend noch ein paar Stunden machen damit sich Morgen wieder alle betroffenen Clients anmelden können.
Also... Ich hab das Problem beheben können!
Wir setzen hier bei uns im Unternehmen eine Software zur Dokumentenarchivierung ein.
Diese benötigt, um sich automatisch Updates zu holen, einen lokalen User mit Adminrechten (hat uns von Anfang an ziemlich gestört).
Es läuft für diese Updates ein Dienst der den lokalen Adminuser benötigt um sich anzumelden.
Jetzt ist es wohl so das sich durch irgend ein Update von Microsoft (kanns mir sonnst nicht erklären da sich an den Kisten nichts geändert hat) wohl was an den Diensten oder ähnliches geändert hat. Auf jedenfall stand in der Ereignisanzeige der betroffenen Clients immer folgendes:
Quelle: Userenv
Ereigniskennung: 1524
Benutzer: Rechnername\Admin (ist der User der den Dienst steuert)
Beschreibung: Die Klassenregistrierungsdatei kann nicht entladen werden, da sie weiterhin von anderen Anwendungen bzw. Diensten verwendet wird. Die Datei wird entladen, wenn sie nicht mehr verwendet wird.
War aber kein Fehler sondern nur eine Warnung. Und das wir mit Servergespeicherten Userprofilen arbeiten und dies wohl öfter vorkommt habe ich mich erst keine Gedanken über diese Meldung gemacht.
So, Dienst deaktiviert... User gelöscht... Alles wieder in Butter!
Das mit den Updates hat eh nicht funktioniert! Warum es nur ein paar Clients betroffen hat weis ich jetzt auch. Da dieser Dienst mit der Updatefunktion eh nicht richtig funktioniert hat haben wir ihn bei den anderen Clients nicht mehr installiert. Eigentlich ganz einfach, oder?
Muß man aber erstmal drauf kommen.
Also, falls noch einer mal diese Probleme hat sollte er mal schauen ob sich nicht ein Dienst auf dem Client befindet der sich als "Lokales Systemkonto" anmeldet sonder für die anmeldung einen lokalen User braucht.
Es kann ja sein das es im allgemeinen diese Dienste betrifft die solch einen Fehler verursachen können.
Gruß, Thomas
Wir setzen hier bei uns im Unternehmen eine Software zur Dokumentenarchivierung ein.
Diese benötigt, um sich automatisch Updates zu holen, einen lokalen User mit Adminrechten (hat uns von Anfang an ziemlich gestört).
Es läuft für diese Updates ein Dienst der den lokalen Adminuser benötigt um sich anzumelden.
Jetzt ist es wohl so das sich durch irgend ein Update von Microsoft (kanns mir sonnst nicht erklären da sich an den Kisten nichts geändert hat) wohl was an den Diensten oder ähnliches geändert hat. Auf jedenfall stand in der Ereignisanzeige der betroffenen Clients immer folgendes:
Quelle: Userenv
Ereigniskennung: 1524
Benutzer: Rechnername\Admin (ist der User der den Dienst steuert)
Beschreibung: Die Klassenregistrierungsdatei kann nicht entladen werden, da sie weiterhin von anderen Anwendungen bzw. Diensten verwendet wird. Die Datei wird entladen, wenn sie nicht mehr verwendet wird.
War aber kein Fehler sondern nur eine Warnung. Und das wir mit Servergespeicherten Userprofilen arbeiten und dies wohl öfter vorkommt habe ich mich erst keine Gedanken über diese Meldung gemacht.
So, Dienst deaktiviert... User gelöscht... Alles wieder in Butter!
Das mit den Updates hat eh nicht funktioniert! Warum es nur ein paar Clients betroffen hat weis ich jetzt auch. Da dieser Dienst mit der Updatefunktion eh nicht richtig funktioniert hat haben wir ihn bei den anderen Clients nicht mehr installiert. Eigentlich ganz einfach, oder?
Muß man aber erstmal drauf kommen.
Also, falls noch einer mal diese Probleme hat sollte er mal schauen ob sich nicht ein Dienst auf dem Client befindet der sich als "Lokales Systemkonto" anmeldet sonder für die anmeldung einen lokalen User braucht.
Es kann ja sein das es im allgemeinen diese Dienste betrifft die solch einen Fehler verursachen können.
Gruß, Thomas
Abend,
so schwer kann es manchmal sein!
Bitte den Thread als "gelöst" markieren. Dazu oben bei der Problembeschreibung auf editieren klicken und den entsprechenden Hacken setzen. Danke...
Gruß
Dani
so schwer kann es manchmal sein!
Bitte den Thread als "gelöst" markieren. Dazu oben bei der Problembeschreibung auf editieren klicken und den entsprechenden Hacken setzen. Danke...Gruß
Dani
Hallo, vielen Dank für die Lösung.
Haben beim Kunden ein Netzwerk mit über 50 Arbeitsplätzen. Hier wird ebenfalls eine Dokumentenarchivierung eingesetzt.
Lange habe ich nach dem Fehler gesucht und letztendlich einige Systeme neuinstalliert.
Der Fehler lag an dem xxxxxx Update Service, der unter einem Lokalen Benutzer sich anmeldet. Anmeldung als Lokalen Dienst eingestellt, und schon funktioniert alles.
Super, Vielen Dank nochmal. Ihr habt mir sehr viel Arbeit erstparrt.
Haben beim Kunden ein Netzwerk mit über 50 Arbeitsplätzen. Hier wird ebenfalls eine Dokumentenarchivierung eingesetzt.
Lange habe ich nach dem Fehler gesucht und letztendlich einige Systeme neuinstalliert.
Der Fehler lag an dem xxxxxx Update Service, der unter einem Lokalen Benutzer sich anmeldet. Anmeldung als Lokalen Dienst eingestellt, und schon funktioniert alles.
Super, Vielen Dank nochmal. Ihr habt mir sehr viel Arbeit erstparrt.
hallo,
kann es sein, das "xxxxxx Update Service" auch durch "DocuWare 5 Update service" ersetzt werden kann ???
gruss
blumshuett
kann es sein, das "xxxxxx Update Service" auch durch "DocuWare 5 Update service" ersetzt werden kann ???
gruss
blumshuett
Ja, ganz genau... Dieser Docuware Update Service hat schon in der Version 4 nicht funktioniert und in der 5er haben die echt den Vogel abgeschossen!
hallo,
nach anfänglichen schwierigkeiten, habe ich den "dw5update" eigendlich ganz gut im griff.
mal sehen, bald werden wir keinen fix, sondern ein update auf 5.1a einspielen...
gruss
blumshuett
nach anfänglichen schwierigkeiten, habe ich den "dw5update" eigendlich ganz gut im griff.
mal sehen, bald werden wir keinen fix, sondern ein update auf 5.1a einspielen...
gruss
blumshuett
ich habe das problem gefunden:
gestern fing das mit dem runterfahren bei uns an,
weil ich gestern auf unserem alten dw46a server die datei-freigaben für dw46a gelöscht habe.
auf den clients war aber noch der dw46a client inkl. update dienst.
was ich gamacht habe:
- services.msc als administrator ausgeführt, dwupdate dienst beendet
- regedit als administrator ausgeführt, dienst dwupdate gelöscht, schlüssel für dw46a software gelöscht
- verzeichniss "c:\dw4\*.*" gelöscht
- gpupdate /force /boot
nun laufen die ps`s ( 8 ) wieder
gruss
blumshuett
gestern fing das mit dem runterfahren bei uns an,
weil ich gestern auf unserem alten dw46a server die datei-freigaben für dw46a gelöscht habe.
auf den clients war aber noch der dw46a client inkl. update dienst.
was ich gamacht habe:
- services.msc als administrator ausgeführt, dwupdate dienst beendet
- regedit als administrator ausgeführt, dienst dwupdate gelöscht, schlüssel für dw46a software gelöscht
- verzeichniss "c:\dw4\*.*" gelöscht
- gpupdate /force /boot
nun laufen die ps`s ( 8 ) wieder
gruss
blumshuett
