none
GPO Setting: "Beim Neustart des Computers und der Anmeldung immer auf Netzwerk warten" fehlerhaft! RRS feed

  • Allgemeine Diskussion

  • Wir verwenden Gruppenrichtlinien unter anderem dazu, Internet-Preferences oder Drucker-Preferences zu setzen.

    Die verwendeten GPO werden aber nur unter bestimmten Benutzern und Profilbedingungen sicher angewendet.

    Wir haben nun mit viel Sisyphusarbeit folgenden Sachverhalt reproduzierbar gemacht:

    * In der Umgebung werden GPO sicher angewendet für Admin, User mit lokalen oder Roaming-Profiles.

    * Übersteigt das Roaming-Profile eine bestimmte Größe und sind die Rechner eher langsamer, so werden die GPOs zwar angewendet, aber die Preferences fehlen.

    Dies haben wir schon seit zwei Jahren versucht mit den Richtlinienvorgaben  :

    1. Beim Neustart des Computers und der Anmeldung immer auf das Netzwerk warten

    2. Wartezeit für Richtlinienverarbeitung beim Systemstart (1-120sek)

    3. Anmeldeskripts gleichzeitig ausführen

    in den Griff zu bekommen.

    Aber die Richtlinienhaben haben nie gegriffen, weil diese so wahrscheinlich auch nicht funktionieren!

    Wir wissen nun aus unseren Untersuchungen, dass nur der Reg.Key.: HKLM/SW/Pol/MS/WinNT/CV/Winlogon: SyncForegroundpolicy = 0/1, darüber bestimmt, ob die GPOs vollständig angewendet werden.

    Zunächst haben wir über eine GPO den Wert SyncForegroundpolicy = 1 gesetzt. Das führte aber zu keinem besseren Ergebnis bei der Anwendung der Preferences.

    Die Überprüfung des GPO-Debugs ergab: GPO und GPP angewendet, SyncForegroundpolicy = 1 in Registry gesetzt.

    Dann haben wir die GPO deaktiviert und in der Registry direkt den Wert SyncForegroundpolicy = 1 gesetzt.

    Nach dem Neustart und der Anmeldung waren nun die Preferences korrekt angewendet!

    Die Überprüfung des Reg.Keys ergab aber nun, dass dieser wieder zurückgesetzt worden war: SyncForegroundpolicy = 0

    Folglich wurden nach dem Neustart die Preferences wiederum nicht mehr korrekt angewendet.

    Erst mit dem erneuten manuellen Setzen des Keys wurde die GPO einmal korrekt angewendet.

    Was läuft hier schief?

    Warum funktioniert das Setzen des Keys SyncForegroundpolicy = 1 über die Richtlinie, aber hat keine funktionellen Auswirkungen!

    Warum wird der manuelle Reg.-Eintrag SyncForegroundpolicy = 1 nach jedem Neustart auf 0 zurückgesetzt?

    mfg

    jf

    Dienstag, 1. April 2014 18:22

Alle Antworten

  • Hallo,

    das sind mir noch zu viele Mutmaßungen :-)

    Aktiviere bitte mal das GPP Tracing der jeweiligen CSE:

    http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat.aspx

    Dort solltest du sehen warum die CSE fehlschlägt.

    SyncForegroundpolicy ist wirklich nur diese Policy, also musst du hier nichts manuell setzen.

    http://gpsearch.azurewebsites.net/#1839

    Ist das Ganze abhängig vom Betriebssystem?

    PS:

    Den Key kannst du auch temporär mit gpupdate /sync setzen...


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Dienstag, 1. April 2014 18:32
    Beantworter
  • Hallo Matthias,

    wir haben in der Vergangenheit bei verschieden Threads dieses Problem schon gemeinsam behandelt.

    Es ist so wie es ist! Unwiderrufbar!

    1. Definitiv tritt das Problem verstärkt bei Profilgrößen > 100MB auf!

    2. Bei Windows XP und Vista gab es dieses Problem auch, wenn auch nur sehr selten!

    3. Der SyncForegroundpolicy-Key wirkt nur, wenn ich diesen lokal per Registry-Eintrag setze!

    Aber: Warum wird er nach dem Neustart wieder zurückgenommen?, so dass beim zweiten Neustart der Key nicht mehr greift!

    4. Auf das Netzwerk warten, bevor ich mit meinen Startprozessen weitermache, bedeutet ja eigentlich auch, dass die Information: Du musst warten!, bereits auf dem System vorhanden ist. Woher will das System dies sonst wissen? Deswegen war es für mich logisch, zu prüfen, was passiert, wenn der Key manuell gesetzt wurde oder die lokale Policy bearbeitet wurde. Aber bei letzterem kam auch kein besseres ergebnis zustande.

    Mittwoch, 2. April 2014 06:38
  • Aktiviere bitte einmal das gpsvc-logging.

    http://matthiaswolf.blogspot.de/2012/06/gpsvc-logging-aktivieren.html

    Dem Ordner "usermode" musst du noch unter %windir%\debug anlegen.

    Setze bitte einmal den SyncForegroundpolicy per Policy.

    Mach dann einen gpupdate.

    Jetzt bitte booten.

    Stell mir bitte einmal das gpsvc.log zur Verfügung und prüfe bitte auch,
    wie der Registrykey nach dem Booten gesetzt ist.

    Ändert diese Policy etwas an dem Verhalten? (aktivieren und auf z.B. 60 setzen)
    http://gpsearch.azurewebsites.net/#2586


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Mittwoch, 2. April 2014 09:17
    Beantworter
  • Moin,

    Am 02.04.2014 08:38, schrieb Jenny Frank:

    Aber: Warum wird er nach dem Neustart wieder zurückgenommen?, so dass
    beim zweiten Neustart der Key nicht mehr greift!

    SChau bitte in alle deine GPOs, GPP Registry, Scripte, Dienste und Tools. Irgendwer überschreibt den Wert.

    Ich bin ein Prediger dieses Werts und der hat sich bei mir noch nie
    zurückgesetzt. Ich habe den wirklich in jedem Netz, in dem ich meine
    Finger hatte aktiv.

    Lass doch mal einen Tag auf einem Rechner nen Procmon mitlaufen, der nur diesen Wert beobachtet und schau ob er über Tag zurückgesetzt wird.
    Ein Dienst, ein Tool, whatever.
    Passiert die Änderung beim Start? Dann wirds mit der Protokollierung schwieriger: Rechner nehme, alle Drittanbieter Dienste auschalten, alle Runkeys Autostart Einträge aufräumen und schauen.
     > 4. Auf das Netzwerk warten, bevor ich mit meinen Startprozessen

    weitermache, bedeutet ja eigentlich auch, dass die Information: Du
    musst warten!

    Jein, das ist jetzt aber philosophisch und führt uns nicht weiter.

    Defacto wartet das System, bis der Netzwerkstack vollständig geladen ist, entwicklungstechnisch ist der Wert aber nicht für das Netzwerk, sondern für die Abarbeitungsreihenfolge der CSEs.

    Er sortiert die CSEs seriell / synchron, genau wieder Schalter "Run Scripts synchronously" für Scripte, nur halt für die CSEs.

    Die Frage ist dann nur, warum heisst der "immer auf das Netzwerk warten"? ;-)

    Ich sag ja: Philosophisch.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 2. April 2014 16:18
  • zu dieser Antwort, bevor ich weiter Tests anstelle:

    das Umstellen des Keys: SyncForegroundPolicy = 1 --> 0 findet bei jedem Neustart nachdem der Wert einmal "angewendet" wurde, statt.

    Die Prozessmon-Überwachung lass ich jetzt mitlaufen, alle andere Dinge hatte ich auch schon deaktiviert.

    mfg

    jf

    Donnerstag, 3. April 2014 09:57
  • das Umstellen des Keys: SyncForegroundPolicy = 1 --> 0 findet bei jedem Neustart nachdem der Wert einmal "angewendet" wurde, statt.

    Prüfe bitte auch noch einmal, ob dies nicht durch irgendeine Policy gesetzt wird.

    gpresult /h report.html
    gpresult /z


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Freitag, 4. April 2014 06:11
    Beantworter
  • Hallo Matthias,

    zunächst herzlichen Dank für deine und der anderen Unterstützung!

    Ich habe für zwei Rechner EDVR2-AP01 und EDVR2-AP02 das gpsvc- und das CSE-Printer-Logging eingestellt und verschiedene Test durchgeführt.

    Im Prinzip geht es darum, über die Einstellungen eines Benutzers einen Drucker zu verbinden und diesen dabei zum Standarddrucker zu machen.

    Wird diese CSE angewendet, wissen wir unter anderen, hier nicht eingeschalteten Einstellungen, dass die GPO richtig arbeiten ("Grüner Haken beim Drucker")

    Weil das über die diskutierten Wege einfach nicht funktionieren will und wir nach unserer Beobachtung festgestellt haben, dass dies etwas mit dem Windows Installationsstand zu tun haben muss, haben wir System AP01 (und drei weitere)  komplett up-to-date neu installiert und vergleichen diesen nun mit AP02.

    Bei AP01 hatten wir nun das beschriebene Verhalten.

    Deswegen haben wir am 02.04. ab 18.10Uhr, 18.16Uhr, 18.22Uhr, 18.30Uhr, 18.38Uhr, 18.46Uhr das System AP01 mehrmals gestartet und die Ergebnisse kontrolliert.

    Nicht erstaunlich war hier, dass wenn das SyncForegroundPolicy-Flag gesetzt war, der Druckerstandard gesetzt wurde und das Flag nach dem Neustart wieder zurückgesetzt war. OK!

    Anschließend haben wir die Policy aktiviert. Es wurde das Flag gesetzt und dieses war nach dem Neustart noch sichtbar vorhanden. Der Druckerstandard wurde nun plötzlich auch richtig angewendet. OK, dachte ich. Problem auf wundersame Weise gelöst.

    Ich wollte wissen, warum das nun lief und habe mir die Log-files mit dem Policy-Reporter angeschaut, allerdings keine Stelle gefunden, wo ich "das Standarddruckersetzen" hätte nachvollziehen können.

    Jetzt habe ich Rechner AP02 geloggt. Bei diesem System, unter den gleichen Bedingungen wie bei AP01, bekomme ich keine erfolgreiche Anwendung der Printer-CSE hin.

    Das Sync-Flag ist gesetzt. Im Logging von AP02 kann ich aber wiederum keine Erklärung finden.

    Was läuft hier schief. Meine Einschätzung, dass das Problem mit Windows zusammenhängt, scheint sich zu bestätigen, aber ich will den Nachweis!

    https://onedrive.live.com/redir?resid=C3BCE6593E915BA3%21126

    mfg

    jf

    Freitag, 4. April 2014 15:20
  • jetzt habe ich auch am rechner AP02 das Problem nachgestellt und das Sync-Flag manuell gesetzt.

    Auch hier gilt: einmal gesetzt, einmal die GPO angewandt, Drucker passt.

    Beim Zweitenmal: Drucker nicht gesetzt --> manuell Setzen --> Neustart --> OK

    Jetzt wende ich wieder die GPO "GPO-VSE-Loginoptimierung" an und mache ein gpresult /h report.html (siehe Anlage). Das Sync-flag wurde über die GPO gesetzt, der Drucker ist allerding sein Standard.

    Auffallend hier ist, die GPO "GPO-VSE-Loginoptimierung" wird angewandt! Die CSE-Printer hingegen nicht.

    https://onedrive.live.com/embed?cid=C3BCE6593E915BA3&resid=C3BCE6593E915BA3%21153&authkey=ACiVZsUYQF6DAZE

    mfg

    jf

    Freitag, 4. April 2014 17:05
  • Textkorrektur:

    Jetzt habe ich auch am Rechner AP02 das Problem nachgestellt und das Sync-Flag manuell über die Registry gesetzt.

    Auch hier gilt: Ist das Sync-Flag einmal mit der Registry gesetzt, wird die GPO einmal angewandt, der Drucker ist als Standard gesetzt.

    Beim zweiten Neustart: wie erwartet, wird der Drucker nicht als Standard gesetzt --> deshalb erneut: manuelles Setzen des Sync-Flag --> Neustart --> OK, Drucker ist wieder Standard

    Jetzt wende ich wieder die Gruppenrichtlinie "GPO-VSE-Loginoptimierung" an und mache ein gpresult /h report.html (siehe Anlage). Das Sync-flag wurde über die GPO gesetzt, der Drucker wird allerdings nicht als Standard gesetzt.

    https://onedrive.live.com/embed?cid=C3BCE6593E915BA3&resid=C3BCE6593E915BA3%21153&authkey=ACiVZsUYQF6DAZE

    Ich habe den Vorgang nun auch mit dem ProcessMonitor analysiert und erkenne, dass auf den entsprechenden Reg-Key für das Sync-flag zugegriffen wird.

    Leider kann ich hier nirgendwo im ProcessMonitor nachvollziehen, wo das SyncForegroundPolicy-Flag gesetzt oder gelöscht wird. Ist das so oder mache ich hier einen Fehler? 

    mfg

    jf

    Sonntag, 6. April 2014 10:34
  • Hallo,

    irgendetwas setzt deinen Key wieder zurück. Das steht schon einmal fest.

    Leider kann ich hier nirgendwo im ProcessMonitor nachvollziehen, wo das SyncForegroundPolicy-Flag gesetzt oder gelöscht wird. Ist das so oder mache ich hier einen Fehler?

    Setze bitte mal einen Filter auf "Operation = RegSetValue".
    Du kannst beim Process Monitor auch ein Bootlogging aktivieren.

    Dann solltest du hoffentlich sehen welcher Prozess den Key zurücksetzt.

    Wird der Key auch bei einem gpupdate /force auf 0 zurückgesetzt?


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Dienstag, 8. April 2014 05:34
    Beantworter
  • PS:

    In den Logfiles ist das hier entscheidend:

    GPSVC(490.538) 14:10:58:985 SetFgRefreshInfo: Previous Machine Fg policy Synchronous, Reason: SyncPolicy.
    GPSVC(490.538) 14:10:58:985 SetFgRefreshInfo: Next Machine Fg policy Synchronous, Reason: SyncPolicy.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Dienstag, 8. April 2014 05:42
    Beantworter