PCs mit automatischer Benutzeranmeldung warten nicht auf das Netzwerk

[lefg 276]

Welche Rollte sollte für das Problem  "... immer auf das Netzwerk warten.", die Behandlung mit Sysprep spielen? Und welche Rolle sollte die Aktualität von BIOS und Treiber spielen dafür?

[Sunny61 807]

Welche Rollte sollte für das Problem  "... immer auf das Netzwerk warten.", die Behandlung mit Sysprep spielen?

Wenn PCs gekont werden und anschließend nicht mit SYSPREP behandelt werden, hatte es in der Vergangenheit immer wieder alle möglichen Probleme gegeben, deshalb mein Hinweis.

 

Und welche Rolle sollte die Aktualität von BIOS und Treiber spielen dafür?

 

Ich weiß es nicht, da es nur bei LENOVOs auftritt, war es mir einen Hinweis wert. Es gab in der Vergangenheit immer wieder Dinge, die mit einem BIOS Update oder mit der Aktualisierung von Treibern behoben wurden. Was also spricht dagegen die Treiber zu aktualisieren?

[lefg 276]

Wenn PCs gekont werden und anschließend nicht mit SYSPREP behandelt werden, hatte es in der Vergangenheit immer wieder alle möglichen Probleme gegeben, deshalb mein Hinweis.

 

Ich habe so etwas mal im Kontext mit WSUS erlebt. Schon der zweite Client, der mit identischer SID ins Netz kam, der wurde im WSUS nicht mehr gelistet.

bearbeitet 23. August 2013 von lefg

[iDiddi 27]

Ich habe so etwas mal im Kontext mit WSUS erlebt. Schon der zweite Client, der mit identischer SID ins Netz kam, der wurde im WSUS nicht mehr gelistet.

 

Bitte verwechsle die SID nicht mit der SUSID. Ab Win Vista Sysprep-Version wird zwar auf jeden Fall auch die SUSID bei den Clones geändert, aber Sysprep macht noch viel mehr, was Sunny wohl eher meint.

 

http://support.microsoft.com/kb/903262/de

 

Und zwar werden auch Plug'n'Play-Treiber der alten Hardware entfernt und noch einiges mehr. Daher ist der Tipp hier gut aufgehoben ;)

bearbeitet 24. August 2013 von iDiddi

[lefg 276]

Wo ist da aber eine Einwirkung auf ".... immer auf das Netzwerk warten."? Nachweisbar, erkennbar?

bearbeitet 24. August 2013 von lefg

[iDiddi 27]

Wenn es sich nur um Lenovo-Clients handelt, die das Problem haben, liegt ein Problem mit der Hardware oder der Treiber ziemlich nahe.

 

Hat der Ursprungs-Client denn die gleichen Probleme?

 

Hast Du die Software von Lenovo installiert?

 

Hast Du dort Virenscanner o.a. installiert?

 

Manche Virenscanner ändern die abstrusesten Dinge am System. Hier ein Beispiel:

http://www.mcseboard.de/topic/191256-reiter-erweitert-in-mmc-ohne-inhalt/

bearbeitet 24. August 2013 von iDiddi

[lefg 276]

Nun, schauen wir mal, ob und was der Owner nächste Woche berichtet.

[lefg 276]

Das GPRESULT-Protokoll habe ich ja schon an eine Nachricht hier im Thread angehängt, die Richtlinie wird angewendet!

 

Gemeint war dieses. Der Aufruf dafür ist rsop.msc oder rsop z.B. an der Eingabeaufforderung oder Ausführen. Sieh angehängte Grafik.

 

Und die Richtlinie is ja noch nicht das Ende der Fahnenstange, das ist nämlich ein Eintrag der Registryteil aus der  System.dat.

 

Registryeintrag "SyncForegroundPolicy" von 0 auf 1 setzen.

 

HKLM\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon

 

Dieser Eintrag muss beim Systemstart vorhanden sein und ausgewertet werden auf 1. Falls die System.dat aber durch den HDGuard geschützt und nicht geändert werden konnte, dann ist er nicht vorhanden oder es steht darin eine 0 dafür.

 

bearbeitet 24. August 2013 von lefg

[WinfriedHH 10]

Nun, schauen wir mal, ob und was der Owner nächste Woche berichtet.

Moin ... leider komme ich erst jetzt zum Antworten, da die letzte Woche bei uns etwas chaotisch war. Aber es scheint nun alles zu funktionieren. Die Kollegin in dem Klassenraum, in dem ich testweise mal für ein paar Neustarts den HDGuard abgeschaltet hatte, hat in den letzten Tagen mal verstärkt darauf geachtet, ob nach dem Booten das Profil richtig geladen wird, und das war der Fall. Ich werde das dann in den nächsten Tagen auch noch mal bei den anderen Lenove-Rechnern machen.

 

Sind die PCs nach dem klonen auch mit SYSPREP bearbeitet worden?

Nein. Mit Sysprep stehe ich auf Kriegsfuß. An anderer Stelle mußte ich Sysprep mal verwenden, weil es unter Windows 7 offenbar die einzige ofiziell zugelassene Methode ist, ein vorbereitetes Benutzerprofil zur Standardvorlage für neue Profile zu machen. Leider ging das genau dreimal, und dann verweigerte Sysprep die Arbeit.

[iDiddi 27]

Also hast Du beim Clonen kein sysprep ausgeführt.

 

Das solltest Du aber wirklich tun:

 

http://blog.danielhahn.eu/2008/arbeiten-mit-sysprep/

 

http://www.windowspro.de/wolfgang-sommergut/sysprep-windows-images-fuer-das-deployment-vorbereiten

bearbeitet 3. September 2013 von iDiddi

[lefg 276]

Also hast Du beim Clonen kein sysprep ausgeführt.

 

Das solltest Du aber wirklich tun:

 

Moin,

 

ich meine, Thema und Problem dieses Thread, Begehren des TO haben doch nichts mit Sysprep zu tun.

 

Allem Anschein nach ist das primäre Problem beseitigt, nach der automatischen Anmeldung wird das richtige servergespeicherte Benutzerprofil geladen.

bearbeitet 4. September 2013 von lefg

[iDiddi 27]

Moin,

 

ich meine, Thema und Problem dieses Thread, Begehren des TO haben doch nichts mit Sysprep zu tun.

 

Allem Anschein nach ist das primäre Problem beseitigt, nach der automatischen Anmeldung wird das richtige servergespeicherte Benutzerprofil geladen.

 

Mag sein. Trotzdem sollte ein Hinweis erlaubt sein, beim Clonen Sysprep auszuführen, zumal es sich um Domänenclients handelt. Ob der TO den Hinweis beherzigt, steht ja auf einem anderen Blatt ;)

[WinfriedHH 10]

Mag sein. Trotzdem sollte ein Hinweis erlaubt sein, beim Clonen Sysprep auszuführen, zumal es sich um Domänenclients handelt. Ob der TO den Hinweis beherzigt, steht ja auf einem anderen Blatt ;)

Wenn Microsoft die Beschränkung aufhebt, daß Sysprep nur dreimal angewendet werden kann, dann kann man gerne darüber sprechen. Ansonsten haben wir in eineinhalb Jahren ein Problem. Wir aktualisieren nämlich einmal im Halbjahr einen (!) PC (neue Versionen der Lernprogramme, Updates und so weiter) und klonen den dann auf die anderen hardwaregleichen Systeme.

 

Abgesehen davon nervt es einfach, daß man nach Sysprep auf jedem Rechner erst mal diesen blöden Erststart-Assistenten durchlaufen muß.

 

 

Und die Richtlinie is ja noch nicht das Ende der Fahnenstange, das ist nämlich ein Eintrag der Registryteil aus der  System.dat.

 

HKLM\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon

Registryeintrag "SyncForegroundPolicy" von 0 auf 1 setzen. 

 

Dieser Eintrag muss beim Systemstart vorhanden sein und ausgewertet werden auf 1. Falls die System.dat aber durch den HDGuard geschützt und nicht geändert werden konnte, dann ist er nicht vorhanden oder es steht darin eine 0 dafür.

Mal ne ganz blöde Frage: Reicht es statt des ganzen Hin- und Her mit dem HDGuard ausschalten, Richtlinie übernehmen, mehrmals neustarten, bis die Richtlinie angewendet wurde und so weiter nicht einfach aus, manuell diesen Registryeintrag zu ändern und diese Änderung im HDGuard zu übernehmen???

bearbeitet 4. September 2013 von WinfriedHH

[lefg 276]

Hallo,

 

natürlich reicht es aus, wenn die Richtlinie übernommen ist und sichtlich, erkennbar auf den Rechner wirkt beim zweiten Neustart. 

 

Die Richtlinie wirkt doch auf die Registry, der Wert wird in die Rgistry geschrieben.

 

Was ich damit meinte, man kann sich durch Inaugenscheinnahme in der Registry davon überzeugen bei Zweifel.

 

Es gibt keine dummen Fragen, es gibt manchmal dumme Antworten. :)

bearbeitet 4. September 2013 von lefg

[lefg 276]

Wie ist die Geschichte hier weiter gegangen?

 

Ich hatte das wohl selbe Problem vor fast fünf Jahren, habe die Rechner jetzt wieder bekommen, habe an bisher fünf von denen das Problem lösen können mit erneutem Installieren des SP3.

 

http://www.mcseboard.de/topic/143394-richtlinie-immer-auf-das-netzwerk-warten-wirkt-nicht-mehr/?hl=%2Bbootvis

bearbeitet 23. September 2013 von lefg