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

Password expiry warning in Windows 7 and Windows 8

Hi all there.

When a domain user logs on, he receives a password expiry notification some time before the password actually expires. In XP and 2003, this was evident because it was integrated into the logon process. In Windows 7 and newer, it is just a taskbar notification that users easily oversee.

Copy the following VBS code to a file of your choice and run that throuhg Group Policy - but NOT as a logon script! Better leverage "Run these programs at user logon":
user configuration
computer configuration

Adjust the values of WarningAge and PWExpiry to your needs. The value of PWExpiry could have been retrieved from AD (Domain Policy or FGPA), but that would have complicated this short script :-)

In the web, there are lots of free or costly solutions, but this one is - at least for this one and only purpose - the fastest...


Const WarningAge = 25   'how old is the pw before the warning shows up?
Const PWExpiry   = 30   'how long is the pw valid at all?

Const MsgTitle = "Password change required!"
Const MsgPart1 = "Your current password expires in "
Const MsgPart2 = " days. Please remember to change your password within time, wich means ultimately at "
Const MsgPart3 = "."

Dim oEnv : Set oEnv = CreateObject( "WScript.Shell" ).Environment( "PROCESS" )
Dim oADS : Set oADS = CreateObject( "ADSystemInfo" )

Dim objUser, strPWDate, intPWAge

strPWDate = GetObject( "LDAP://" & oEnv( "USERDNSDOMAIN" ) & "/" &  oADS.UserName ).PasswordLastChanged
intPWAge = DateDiff( "d", strPWDate, Now )
If intPWAge > WarningAge And intPWAge <= PWExpiry Then
    MsgBox MsgPart1 & PWExpiry - intPWAge & MsgPart2 & strPWDate + PWExpiry & MsgPart3, vbOk + vbInformation, MsgTitle
End If

Passwortablaufwarnung in Windows 7 und Windows 8

Hallo zusammen.

Wenn sich ein Domänenbenutzer anmeldet, erhält er eine bestimmte Zeit vor Ablauf des Kennworts einen Warnhinweis dazu. In XP und 2003 war der unübersehbar, da direkt in den Anmeldedialog integriert. In Windows 7 und neuer ist es nur noch eine Taskbar Notification, und die übersieht der Benutzer gerne.

Kopiere den folgenden VBS-Code in eine Datei Deiner Wahl und führe diese per Gruppenrichtlinie aus - nicht als Anmeldeskript! Besser eignet sich "Diese Programme bei der Benutzeranmeldung ausführen":
Benutzerkonfiguration
Computerkonfiguration

Die zwei Werte für WarningAge und PWExpiry müsst Ihr natürlich Euren Bedürfnissen anpassen. Den Wert für PWExpiry hätte ich auch aus dem AD (Domain Policy oder FGPA) ermitteln können, aber dann wird es wieder umständlich :-)

Im Web findet man dazu die eine oder andere kostenpflichtige oder freie Lösung, aber das hier ist auf jeden Fall für diesen einen Zweck die kürzeste...


Const WarningAge = 25   'Wie alt ist das Kennwort, bevor gewarnt wird?
Const PWExpiry   = 30   'Wie lange ist das Kennwort maximal gültig?

Const MsgTitle = "Kennwortwechsel"
Const MsgPart1 = "Ihr aktuelles Kennwort läuft in "
Const MsgPart2 = " Tagen ab. Bitte denken Sie daran, Ihr Kennwort rechtzeitig zu ändern, spätestens am "
Const MsgPart3 = "."

Dim oEnv : Set oEnv = CreateObject( "WScript.Shell" ).Environment( "PROCESS" )
Dim oADS : Set oADS = CreateObject( "ADSystemInfo" )

Dim objUser, strPWDate, intPWAge

strPWDate = GetObject( "LDAP://" & oEnv( "USERDNSDOMAIN" ) & "/" &  oADS.UserName ).PasswordLastChanged
intPWAge = DateDiff( "d", strPWDate, Now )
If intPWAge > WarningAge And intPWAge <= PWExpiry Then
    MsgBox MsgPart1 & PWExpiry - intPWAge & MsgPart2 & strPWDate + PWExpiry & MsgPart3, vbOk + vbInformation, MsgTitle
End If

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