GPO-Fehler in Windows 8.1 (4): Die unendlichen Weiten des RSoP-Berichts...

Hallo zusammen.

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 :-)

Windows 8.1 und EnableLinkedConnections

Hallo zusammen.

Im letzten Post (http://evilgpo.blogspot.de/2013/09/windows-8-und-enablelinkedconnections.html) ging es um das Problem, dass Laufwerksmappings zu Unterordnern von Shares für Administratoren in Windows 8 im Explorer nicht im entspechenden Unterordner landen, sondern direkt auf dem Share. Und dass es dafür jetzt einen Hotfix gibt.

Diesen Hotfix gibt es NICHT FÜR WINDOWS 8.1 - hier besteht der Fehler nach wie vor. Ob und wann es einen Fix geben wird - unbekannt...

Greez, Martin

Windows 8 und EnableLinkedConnections: Fix verfügbar

Hallo Welt.

Hier und hier ist ein Fehler in Windows 8 beschrieben. Dieser Fehler hat für Admins zur Folge, dass Netzlaufwerke, die auf Unterverzeichnisse zeigen, im Explorer immer auf Shareebene und nicht im jeweiligen Unterordner geöffnet werden.

Und seit einigen Tagen gibt es jetzt einen privaten Hotfix KB2878604, der diesen Fehler endlich behebt.

Greetz, Martin

GPO-Fehler in Windows 8 (3): Ausführungszeiten von CSEs im RSoP

Hallo zusammen.

In Windows 8 wurde ja der RSoP-Bericht gründlichst durcheinandergewirbelt und ist jetzt relativ unübersichtlich geworden, auch wenn das GPTeam da anderer Meinung ist.

Auf jeden Fall völlig misslungen ist dabei die Nachvollziehbarkeit der Verarbeitungsreihenfolge von GPOs. Wurden die einzelnen GPOs früher von oben nach unten in der Reihenfolge protokolliert, wie sie angewendet werden, so kam jemand im GPTeam auf die Idee, dass man das doch besser alphabetisch machen könnte (ja, sie verkaufen es wirklich als Verbesserung). Völliger Unfug und ein Schuß in den Ofen, aber was solls - heute geht's nicht darum (ist ja kein Bug, sondern ein Feature - wer die Verarbeitungsreihenfolge trotzdem wissen will, muss entweder ins GP Eventlog schauen oder den Report remote von Win7 aus erstellen). Und warum "Enforced" oder "Slow/Fast Link"einen Alert wert sind, weiß auch niemand so genau.

Im "improved" neuen Report-Format findet Ihr jetzt allerdings die Verarbeitungszeiten der einzelnen CSEs direkt protokolliert - das liefert auf einen Blick Anhaltspunkte, wo man ansetzen muß, wenn die Verarbeitungszeiten zu lang sind.

(Screenshot vom GPTeam-Blog)

Unter "Component Status" liefert die Spalte "Time Taken" die Zeiten, die hier alle im grünen Bereich liegen. Interessant wird es allerdings, wenn eine CSE 60 Sekunden oder mehr braucht. Dann bekommt Ihr z.B. folgende Zeitangaben im Eventlog und im Report:

Ereignisdetails aus der Ereignisanzeige: Die Verarbeitung der Group Policy Files-Erweiterung wurde in 93735 Millisekunden abgeschlossen. 15.05.2013 10:40:12

Anzeige im RSoP-Bericht in GPMC: Group Policy Files Erfolgreich 1 Stunde(n) 33 Minute(n) 15.05.2013 10:40:12


Die GPMC macht also aus Minuten hier Stunden... Ist als Bug bestätigt und "will be considered for vNext".

Happy reporting! :-)

GPO-Fehler in Windows 8 (2): TCP/IP-Drucker mit Group Policy Preferences

Hallo zusammen.

Vielleicht habt Ihr ja auch schon einmal Group Policy Preferences "Drucker" verwendet, um lokale oder Netzwerkdrucker zu verwalten (erstellen, verbinden, löschen etc.). Hier gibt es auch die Möglichkeit, TCP/IP-Drucker zu erstellen.



Das ganze funktioniert mit Windows XP bis Windows 7 problemlos. In Windows 8 leider nicht mehr... Wenn "DNS-Name verwenden" aktiviert ist, dann erstellt GPP einen TCP/IP-Port mit dem Namen "IP_2.0.0.0" und der IP-Adresse 2.0.0.0.

Einziger bekannter Workaround: Keinen DNS-Namen verwenden, sondern direkt eine IP-Adresse eintragen. Das funktioniert aber nicht nachträglich für bestehende Drucker - die behalten den anfänglich zugewiesenen falschen Anschluss (obwohl der neue Anschluss mit der korrekten IP-Adresse aber erstellt wird). Ihr müsst also den "fehlerhaften" Drucker zunächst löschen und dann einen neuen mit IP-Adresse anlegen.

Das Verhalten wurde von MS als Bug bestätigt, aber ob und wenn ja wann es einen Fix dazu geben wird, ist derzeit offen.

Die Ursache für den Fehler ist die gleiche wie bei einem anderen Fehler: In der Zielgruppenadressierung gibt es einen Filter auf IP-Adressbereiche. Auch dieser Filter funktioniert in Windows 8 nicht mehr. GPP-intern hat MS anscheinend von Winsock 1 auf Winsock 2 umgestellt, und dabei wurden einige Code Defects implementiert...

Happy Printing! :-))

GPO-Fehler in Windows 8 (1): AppMgmtDebugLevel

Hallo zusammen.

Mit Windows 8 hat sich in GPOs scheinbar wenig geändert - zumindest kamen kaum grundlegend neue Funktionen dazu. Lediglich die Sicherheitseinstellungen sind erweitert worden, um z.B. DNSSEC und DirectAccess besser zu unterstützen.

Trotzdem hat MS es geschafft, in einigen Bereichen - teilweise in uralten Funktionen - neue Fehler einzubauen. Einer dieser Bereiche ist die Softwareinstallation mit Gruppenrichtlinien (MSI-Verteilung, auch als AppMgmt bezeichnet). Und der Fehler ist folgender:

Wenn wir eine MSI-Datei mit GPOs verteilen und die Installation funktioniert, dann ist alles gut. Funktioniert sie nicht, benötigen wir allerdings Protokolle, in denen wir nach Fehlern suchen können. Für AppMgmt benötigen wir sogar gleich mehrere Protokolle, da hier drei Komponenten zusammenwirken:

• Group Policy-Verarbeitung (also das GPO Eventlog und ggf. das GPSVC Debug Logging)
• AppMgmt-Verarbeitung, also das Ermitteln und Auswerten der zu installierenden MSI-Pakete - das Logging hierfür muss allerdings zuerst aktiviert werden
• Die eigentliche Installation der MSI-Pakete (Windows-Installer) - auch hier muss das Logging zuerst aktiviert bzw. passend konfiguriert werden

Soweit, so gut. Keine dieser Komponenten hat sich von Windows 7 nach Windows 8 gravierend geändert, aber trotzdem: Das Logging von AppMgmt funktioniert nicht mehr...

Setzten wir AppMgmtDebugLevel=0x4B (andere Quellen sagen 0xF7 oder 0x9B, ist aber egal, da das nur einen Bitmaske ist - 0xFFFFFFFF würde auch gehen) und installieren eine MSI-Datei mit GPOs, dann wird die Protokolldatei %windir%\usermode\appmgmt.log nicht erstellt. Entfernen wir dann die MSI-Datei aus dem GPO, dann wird plötzlich eine Datei erstellt - aber die enthält für jede GPO-Verarbeitung genau einen einzigen Eintrag, nämlich einen Zeitstempel:

05-07 19:03:28:054
05-07 20:39:31:727
05-07 22:19:36:728
05-07 23:57:41:073
05-08 01:45:46:129
05-08 03:15:50:317
05-08 05:06:54:839
05-08 06:49:58:543
05-08 08:29:04:912 


Das hilft uns natürlich in keinster Weise weiter, wenn wir Fehlersuche betreiben wollen. Dieses Verhalten wurde von MS zwischenzeitlich als Bug bestätigt und für Windows 8.1 wird es möglicherweise behoben. Ob es für Windows 8 jemals einen Fix geben wird, ist derzeit nicht bekannt.

Die einzige Möglichkeit für uns ist damit: Wir benötigen einen Computer mit Windows 7, auf dem das gleiche Verhalten auftritt, das wir analysieren wollen. Hier können wir dann wie gewohnt das AppMgmt-Logging aktivieren.

Happy MSI-Deployment! :-))

Windows 8 und EnableLinkedConnections: Fix in Aussicht

Hallo zusammen.

Der eine oder andere ist vielleicht schon über dieses Problem gestolpert: Setzt man unter Windows 8 EnableLinkedConnections=1 (damit Netzlaufwerke in Admin-Prozessen verfügbar sind), dann verbindet Windows keine Unterverzeichnisse mehr als Laufwerk, sondern nur noch direkt die Shares.

Soll heißen: Wenn Ihr ein Laufwerk \\Server\Share\Subdir1\Subdir2 verbunden habt und öffnet das in Windows 8, dann landet Ihr nicht in Subdir2, sondern direkt in \\Server\Share.

Matthias hat das in seinem Blog auch schon beschrieben.

Die gute Nachricht: Dieses Fehlverhalten wurde heute von Microsoft als Bug bestätigt, und im September soll es einen private Hotfix dafür geben. Sobald ich die Fixnummer kenne, werde ich sie hier veröffentlichen.

Greetz, Martin