TL;DR: Der RSoP-Bericht von Windows 8.1 zeigt keine abgelehnten GPOs an.
Nachdem Windows 8.1 inzwischen RTM ist, habe ich den Titel dieser kleinen Serie geändert - die meisten Fehler, die ich in Windows 8 bisher gefunden habe, sind auch in Windows 8.1 noch vorhanden. Das gilt natürlich auch für Server 2012 und 2012 R2. Allerdings bringt Windows 8.1 noch ein paar neue Fehler mit.
Einige der Fehler stecken im RSoP-Bericht. Nicht nur die Ausführungszeiten von CSEs werden hier unter bestimmten Umständen falsch angezeigt. Auch die abgelehnten GPOs sind - nun ja - interpretationsfähig..
(Anmerkung: Die folgenden Abbildungen wurden jeweils auf einem Remotesystem erzeugt - der Zielcomputer und der Benutzer waren dabei aber immer dieselben.)
Abgelehnte GPOs eines Benutzers in Windows 7
Der gleiche Benutzer mit den gleichen GPOs unter Windows 8
(Warum weicht die Uhrzeit um 8 Sekunden von der in Windows 7 ab? Weil Windows 7 den Beginn der GPO-Verarbeitung als Timestamp verwendet, Windows 8 und 8.1 dagegen das Ende der GPO-Verarbeitung. Das kann im Gruppenrichtlinien-Ereignisprotokoll nachvollzogen werden.)
Die Übersichtlichkeit hat stark gelitten, da ich jedes GPO einzeln auf den Ablehnungsgrund untersuchen muß. Und die Vererbungsreihenfolge wurde ersetzt durch eine alphabetische Auflistung. Nun ja, bei MSFT ist man stolz auf diese "Verbesserung". Der Ablehnungsgrund ist eigentlich falsch - in diesem speziellen GPO ist lediglich der Benutzerteil deaktiviert. Aber wir wollen ja nicht pingelig sein.
Und noch einmal der gleiche Benutzer mit den gleichen GPOs in Windows 8.1
Hoppla - wo sind die abgelehnten GPOs? Verschwunden in den Tiefen des äußeren Weltalls?
Übrigens: Auch im Eventlog des Windows 8.1. Computers fehlen die abgelehnten GPOs.
Damit haben wir also in einem Umfeld ohne ältere Betriebssysteme derzeit keine Möglichket, abgelehnte GPOs zu untersuchen.
Happy resulting :-)
Hallo Martin,
ReplyDeletebei den meisten Deiner Erkenntnissen stimme ich Dir zu.
Anders sehe ich es bzgl. der "Denied GPOs".
Der Status "Inaccessible" deutet darauf hin, dass der User überhaupt kein Recht hat, die GPO Informationen überhaupt zu lesen. Deswegen wird auch nur die GUID statt des Namens angezeigt. Man kann beide Varianten von GPO-Filtering (Apply oder Deny) auch so nutzen, dass die User in jedem Fall ein "Read" Recht auf die GPO haben. Ob die Anwendung der GPO tatsächlich stattfindet, entscheidet ja das "Apply" Recht.
Bsp: Setze auf eine GPO "Read" Rechte für "Authenticated Users", aber "Read+Apply" nur für eine bestimmte Benutzer-Gruppe. Ist der User nicht Mitglied der Gruppe, wendet er die GPO nicht an, bekommt diese aber dennoch sauber im RSOP (via GPMC oder gpresult) als "Access Denied (Security Filtering)" angezeigt.
Happy resulting ;-)
Patrick, ich weiß schon, wie das mit "deny apply" geht, das darfst du mir glauben. Und auch das Problem "GUID statt Name, wenn kein Sicherheitsfilter". Mir geht es aber darum: Im Report unter 8/8.1 wurde die Auflistung der Applied/Denied GPOs statt in Vererbungsreihenfolge ersetzt durch "alphabetisch", was für die Praxis völliger Müll ist. Und den Ablehnungsgrund ("inaccessible") sehe ich erst in den Details aller GPOs, was bei größeren Umfeldern auch blöd ist.
ReplyDeleteUnd das mit dem deaktivierten Benutzerteil stimmt wirklich - lass mal AuthUsers im Security Filter drin, verlinke mit dem User und deaktiviere den Benutzerteil... Ich HABE Lesezugriff (sogar apply, um genau zu sein), trotzdem zeigt der Report nur die GUID.
Hoppla, dass Dein Beispiel auf "deaktivierten Benutzerteil" abzielt, hatte ich überlesen.
ReplyDeleteWas ich versucht hatte darzustellen ist die Tatsache, dass auch GPO's komplett aus dem Report fallen, auf die das Konto keine Leseberechtigung hat. Dem kann man entgegenwirken, wenn man das Read-Recht wie beschrieben sicherstellt. Oder anders ausgedrückt: nur noch GPO's, auf die kein Apply-Recht besteht, werden ab Win 8.1 noch als "Denied GPOs" aufgelistet (sofern eben zumindest Read-Recht besteht). Alle anderen Gründe fürs Ablehnen (z.B. Link disabled) und damit die GPO's fallen beim RSOP unter den Tisch.
Die Reihenfolge der GPO's nach GPO-Namen zu sortieren ist wahrlich Unsinn.
Die mangelnde Übersicht im neuen RSOP-Rreport ist vermutlich dem Umstand geschuldet, dass eben nicht nur 3 Werte (Name, Link Location, Reason Denied) pro GPO aufgeführt werden, sondern 8 + der Name, der dabei als Gruppierung verwendet wird: mehr Infos zum Preis von weniger Komfort.
Übrigens auch sehr unschön: einen Report von Win 8.1 remote auf Win 7 ausführen.
Da bekommt man als "Reason Denied" nur noch das generische "Inaccessible, Empty or Disabled".
Patrick
Zitat: "Übrigens auch sehr unschön: einen Report von Win 8.1 remote auf Win 7 ausführen.
ReplyDeleteDa bekommt man als "Reason Denied" nur noch das generische "Inaccessible, Empty or Disabled"."
Und das ist der Punkt, den ich adressieren möchte: Der Report ist ab Win8 unbrauchbar geworden...