none
Benutzer GPO wird nicht übernommen RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    ich habe wohl ein Problem wie im angepinnten Beitrag (https://social.technet.microsoft.com/Forums/de-DE/d5f58aae-46f8-40f6-82e1-732eea17a645/nderungen-der-gpo-verarbeitung-mit-update-ms16072kb3163622?forum=gruppenrichtliniende) beschrieben.

    Wie beschrieben habe ich den betroffenen GPOs die Gruppe Domänen Computer via Delegation hinzugefügt. Dann habe ich gpupdate auf dem DC und auf dem betroffenen TS durchgeführt und den TS auch neugestartet. Dennoch werden die GPOs mit den Benutzerkonfigurationen nicht angewendet. Ein anderer TS ohne den Patch wendet die GPOs ohne Probleme an. Was könnte ich übersehen haben?

    Vielen Dank

    Grüße

    David

    Mittwoch, 5. Oktober 2016 20:49

Alle Antworten

  • Am 05.10.2016 schrieb DKCT:
    Hi,

    ich habe wohl ein Problem wie im angepinnten Beitrag (https://social.technet.microsoft.com/Forums/de-DE/d5f58aae-46f8-40f6-82e1-732eea17a645/nderungen-der-gpo-verarbeitung-mit-update-ms16072kb3163622?forum=gruppenrichtliniende) beschrieben.

    Wie beschrieben habe ich den betroffenen GPOs die Gruppe Domänen Computer via Delegation hinzugefügt. Dann habe ich gpupdate auf dem DC und auf dem betroffenen TS durchgeführt und den TS auch neugestartet.

    Wozu auch immer man auf dem dc gpupdate in dem Fall durchführt.

    Dennoch werden die GPOs mit den Benutzerkonfigurationen nicht angewendet. Ein anderer TS ohne den Patch wendet die GPOs ohne Probleme an. Was könnte ich übersehen haben?

    Loopbackmodus aktiv auf dem betroffenen TS?

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 5. Oktober 2016 21:04
    Moderator
  • Nein, Loopbackmodus ist auf keinem der TS aktiv.

    Mittwoch, 5. Oktober 2016 21:16
  • Am 05.10.2016 schrieb DKCT:

    Nein, Loopbackmodus ist auf keinem der TS aktiv.

    Also sprich, die User GPOs sind auf die OU der Nutzer verlinkt?


    Dilbert's words of wisdom #04:
    There are very few personal problems that cannot be solved by a suitable application of high explosives.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 5. Oktober 2016 21:46
    Moderator
  • Also die GPO ist auf die übergeordnete OU verlinkt. (unterhalb ist die OU für die Nutzer und auch für die OU für die TS Server)

    Die OU mit den betreffenden Benutzereinstellungen ist aber via Sicherheitsfilterung an eine Benutzergruppe gebunden. Die Gruppenrichtlinienergebnisse spucken bei den TS mit dem Patch "Zugriff nicht möglich" aus (es wird auch nur die Eindeutige ID angezeigt statt des GPO Namens), beim TS ohne den Patch wird die Richtlinie angewandt.


    • Bearbeitet DKCT Mittwoch, 5. Oktober 2016 22:20 Ergänzung
    Mittwoch, 5. Oktober 2016 22:01
  • Am 06.10.2016 schrieb DKCT:
    Hi,

    Die OU mit den betreffenden Benutzereinstellungen ist aber via Sicherheitsfilterung an eine Benutzergruppe gebunden. Die Gruppenrichtlinienergebnisse spucken bei den TS mit dem Patch "Zugriff nicht möglich" aus (es wird auch nur die Eindeutige ID angezeigt statt des GPO Namens), beim TS ohne den Patch wird die Richtlinie angewandt.

    Dann hast du wahrscheinlich irgendwas beim Delegieren falsch gemacht. ;) Probiers mal hiermit:
    https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/
    Powershell skript runterladen und ausführen.

    Bye
    Norbert


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 5. Oktober 2016 22:27
    Moderator
  • Hallo Norbert,

    danke für deine Hilfe, ich habe mal das erweiterte Skript von Jeremy Saunders benutzt (auch auf der Seite von SDM verlinkt), damit kann man die GPOs erst überprüfen lassen. Und das Skript gibt aus, dass keine GPOs angepasst werden müssen. Damit sollte beim Delegieren alles richtig sein. :(

    Donnerstag, 6. Oktober 2016 12:04
  • Moin,

    aber was sagt denn GPRESULT für den betreffenden Server und User?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 6. Oktober 2016 12:07
  • Am 06.10.2016 schrieb DKCT:
    Hi,
     > danke für deine Hilfe, ich habe mal das erweiterte Skript von Jeremy Saunders benutzt (auch auf der Seite von SDM verlinkt), damit kann man die GPOs erst überprüfen lassen. Und das Skript gibt aus, dass keine GPOs angepasst werden müssen. Damit sollte beim Delegieren alles richtig sein. :(

    OK. Sind denn die TS in der Gruppe der Domänencomputer überhaupt Mitglied?

    Donnerstag, 6. Oktober 2016 12:16
    Moderator
  • Ja natürlich, hab ich schon 3 mal gecheckt. Aber ich habe jetzt des Rätsels Lösung gefunden. Neben den Rechten in der Delegierung, hat bei den Nutzern die ich gestern testen sollte, auch der Profilpfad im AD gefehlt. Da bei dem Netzwerk Servergespeicherte Profile zum Einsatz kommen, der entsprechende Pfad im AD aber gefehlt hat, konnte die Richtlinie anscheinend nicht angewendet werden. Was mich halt nur stutzig macht, ist die Tatsache dass es bei dem TS ohne den Patch trotzdem funktioniert hat.
    Donnerstag, 6. Oktober 2016 14:03