Donnerstag, 24. Januar 2013

PowerShell - Leere Benutzer- und Computerkonfigurationen deaktivieren

Microsoft's Best Practice schlägt vor, ungenutzte Benutzer- bzw.
Computerkonfigurationen zu deaktivieren.

Mehr Informationen dazu hier:

http://technet.microsoft.com/en-us/magazine/dd673616.aspx

http://support.microsoft.com/kb/315418/en-us


Deaktivierung per GPMC:

Die Deaktivierung kann in der GPMC erfolgen:


Das Hauptproblem liegt darin, leere GPOs aufzufinden.
Bei einer großen Anzahl von GPOs ist die manuelle Methode unbrauchbar.


Deaktivierung per PowerShell:

Für die automatische Deaktivierung per PowerShell habe ich ein Skript geschrieben:


# You will use this script at your own risk.
#
# Matthias Wolf - MVP Group Policy
# http://matthiaswolf.blogspot.com
#

import-module GroupPolicy

$gpos = get-gpo -All

foreach ($item in $gpos)

{

      # Checking if Computer Configuration is empty
      if ($item.Computer.DSVersion -eq 0)

     {

             write-host $item.DisplayName Computer Config is empty
             write-host Disabling Computer Config
             $item.Computer.Enabled=$false

      }
     
      # Checking if User Configuration is empty
            if ($item.User.DSVersion -eq 0)

     {

             write-host $item.DisplayName User Config is empty
             write-host Disabling User Config
             $item.User.Enabled=$false

      }

}


Das Skript könnt ihr hier herunterladen.
Download


Zu beachten:

Zwei Dinge sind zu beachten.

1. Das Skript verwendet die Versionsnummer der Konfiguration


Wird die Policy bearbeitet erhöht sich die Versionsnummer.
Werden die Einstellungen wieder aus der Policy entfernt, erhöht sich ebenfalls die Versionsnummer!

Bereits verwendete Policies (auch wenn diese mittlerweile leer sind) werden also nicht deaktiviert.

2. Deaktivierte Einstellungen bleiben deaktiviert

Deaktiviert man einen Policy-Anteil, so bleibt dieser so lange deaktiviert bis man dies wieder rückgängig macht.

Wird z.B. die Benutzerkonfiguration deaktiviert und ein Admin setzt danach Einstellungen in der Benutzerkonfiguration, so muss diese erst wieder manuell aktiviert werden. 

Performancegewinn?:

In der Theorie werden die Richtlinien schneller abgearbeitet.
Der eigentliche Gewinn ist jedoch nur schwer messbar.


Group Policy MVP Darren Mar-Elia berichtet unter anderem in seinem Artikel "Optimizing Group Policy Performance" darüber.

Der größte Vorteil besteht meiner Meinung nach in der Übersichtlichkeit der Richtlinien. In der GPMC ist direkt ersichtlich welche Richtlinen Computer- bzw. Benutzerkonfigurationen enthalten:



 

Mittwoch, 9. Januar 2013

Windows 8: The scheduled task nightmare goes on

Vor einiger Zeit habe ich schon einmal über ein seltsames Verhalten beim Anlegen von geplanten Tasks berichtet.

Geplante Aufgabe als SYSTEM ausführen - Fehler 0x80070534

Damals drehte es sich um die Verwendung des Benutzers "SYSTEM".

0x80070057 unter Windows 8

Unter Windows 8 tritt nun ein neuer Fehler auf.
Dieser Fehler besteht nur, wenn man einen klassischen Task per Group Policy Preferences anlegen will.



Als Test benutzen wir diesen Task:



Der Task wird jedoch nie am Client angelegt.
Aktiviert man das GPP Tracing, so zeigt sich folgender Fehler:

2013-01-09 11:32:45.523 [pid=0x36c,tid=0xbbc] Starting filter [AND FilterComputer].
2013-01-09 11:32:45.523 [pid=0x36c,tid=0xbbc] Properties handled. [ hr = 0x80070057 "The parameter is incorrect." ]
2013-01-09 11:32:45.523 [pid=0x36c,tid=0xbbc] Error suppressed. [ hr = 0x80070057 "The parameter is incorrect." ]


Das Problem tritt für definierte Tasks in der Computerkonfiguration als auch Benutzerkonfiguration auf.

Wird explizit ein Benutzer zur Ausführung der Aufgabe angegeben, so erscheint der gleiche Fehler 0x80070057.


Die Lösung:

Es muss ein v2-Task angelegt werden.

Dieser Task nennt sich "Geplante Aufgabe (mindestens Windows 7)".

Das Anlegen in dieser Form bringt einem erst einmal keine Nachteile,
im Gegenteil, es können die erweiterten Features der v2-Tasks genutzt werden.


Einen Haken hat diese Lösung jedoch, sollen Tasks ebenfalls für Betriebssysteme kleiner Windows 7 erstellt werden, so muss man nun zwei GPP Items anlegen:

- einen klassischen Task für alle Systeme inkl. Windows Vista
- einen neuen Task für alle Systeme ab Windows 7




Die neue Aufgabe wird ohnehin nicht auf einem "alten" Betriebssystem angelegt. 
Allerdings wird ohne Verwendung eines Item Level Targetings versucht,
den klassischen Task auf Windows 7 und Windows 8 Maschinen anzulegen
(ebenfalls Server 2008 R2 und Server 2012).

Bei Windows 7 funktioniert das in der Regel, bei Windows 8 erscheint der genannte Fehler.

Trennen der Tasks durch Item Level Targeting:

Die saubere Lösung ist die Verwendung von zwei ILTs:

Neuer Task:



Alter Task: