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:
Donnerstag, 24. Januar 2013
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:
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:
Donnerstag, 13. Dezember 2012
Drag & Drop von Preference Items funktioniert nicht mehr unter Windows 8
Heute wieder einmal ein Fehler, der zwar nicht gelöst werden kann, aber für den es zumindest einen Workaround gibt.
In den "Remote Server Administration Tools" (RSAT) unter Windows 8 oder Server 2012 ist ein Bug vorhanden, der das Importieren von GPP Items per Drag & Drop verhindert.
Exportieren und Importieren von Items
Exportieren:
Die betreffenden Elemente können einfach auf den Desktop gezogen werden.
Danach wird dort eine XML Datei angelegt.
Diese Datei lässt sich dann editieren oder einfach nur als Sicherungskopie aufbewahren.
In gleicher Weise konnte man unter Windows 7 und Server 2008 R2
Elemente importieren.
Importieren:
Versucht man jedoch in den Windows NT 6.2 RSAT Elemente zu importieren, so erscheint das Drop-Symbol nicht:
Nach längerer Recherche scheint es so, also wäre schlichtweg nur ein
Drag-Event vorhanden, jedoch kein Drop-Event.
Dies scheint wohl in der Programmierung schief gelaufen zu sein.
Wann benötigt man den Import von XML Dateien?
Wie lassen sich die XML Dateien importieren?
Workaround 1:
Die Datei per Kontextmenü kopieren und einfügen:
Workaround 2:
Der zweite Lösungsweg ist etwas umständlicher.
Zunächst muss ein Dummy-Element in der GPMC angelegt werden.
Dies ist wichtig für die Erzeugung der XML Datei und der Registrierung der jeweiligen CSE im AD Objekt der Policy.
Nun muss man per Explorer zur jeweiligen Policy navigieren.
Im Falle eines Registry-Items ist dies:
\\domain.local\SYSVOL\domain.local\Policies\{GUID}\machine\Preferences\Registry
bzw.
\\domain.local\SYSVOL\domain.local\Policies\{GUID}\user\Preferences\Registry
Dort befindet sich eine Registry.xml die ersetzt werden muss.
Weitere Information zu diesem Thema:
http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/2abf6cb1-d900-4d21-a59e-c9687c564b0d
In den "Remote Server Administration Tools" (RSAT) unter Windows 8 oder Server 2012 ist ein Bug vorhanden, der das Importieren von GPP Items per Drag & Drop verhindert.
Exportieren und Importieren von Items
Exportieren:
Die betreffenden Elemente können einfach auf den Desktop gezogen werden.
Danach wird dort eine XML Datei angelegt.
Diese Datei lässt sich dann editieren oder einfach nur als Sicherungskopie aufbewahren.
In gleicher Weise konnte man unter Windows 7 und Server 2008 R2
Elemente importieren.
Importieren:
Versucht man jedoch in den Windows NT 6.2 RSAT Elemente zu importieren, so erscheint das Drop-Symbol nicht:
Nach längerer Recherche scheint es so, also wäre schlichtweg nur ein
Drag-Event vorhanden, jedoch kein Drop-Event.
Dies scheint wohl in der Programmierung schief gelaufen zu sein.
Wann benötigt man den Import von XML Dateien?
- Man möchte eine Sicherungskopie des Preference Item wiederherstellen
- Man möchte eine manuell editierte XML Datei importieren
- Man benutzt reg2xml
Wie lassen sich die XML Dateien importieren?
Workaround 1:
Die Datei per Kontextmenü kopieren und einfügen:
Workaround 2:
Der zweite Lösungsweg ist etwas umständlicher.
Zunächst muss ein Dummy-Element in der GPMC angelegt werden.
Dies ist wichtig für die Erzeugung der XML Datei und der Registrierung der jeweiligen CSE im AD Objekt der Policy.
Nun muss man per Explorer zur jeweiligen Policy navigieren.
Im Falle eines Registry-Items ist dies:
\\domain.local\SYSVOL\domain.local\Policies\{GUID}\machine\Preferences\Registry
bzw.
\\domain.local\SYSVOL\domain.local\Policies\{GUID}\user\Preferences\Registry
Dort befindet sich eine Registry.xml die ersetzt werden muss.
Weitere Information zu diesem Thema:
http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/2abf6cb1-d900-4d21-a59e-c9687c564b0d
Sonntag, 11. November 2012
User Shell Folders - Umgebungsvariablen umbauen mittels Group Policy Preferences
Group Policy Preferences bringen von Haus aus eine Menge von
Variablen mit. Drückt man die Taste "F3" in einem Textfeld, so erscheint die
Liste von verfügbaren GPP-Umgebungsvariablen:
Link zu allen GPP-Variablen
Zusätzlich können die vom System bereitgestellten "normalen" User- und Systemvariablen verwendet werden.
So gibt es in den GPP Variablen zum Beispiel keine Komponente für den Pfad
"C:\Program Files (x86)". Es kann die normale Variante "%ProgramFiles(x86)%" benutzt werden.
Teilweise ist dies aber nicht genug.
Dies gilt vor allem für die sogenannten User Shell Folders.
User Shell Folders
Diese USF befinden sich in der Registry unter:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
In diesem Bereich werden Pfade zu Explorer Verzeichnissen gespeichert.
Mit ein paar einfachen Schritten lassen sich diese Schlüssel in Umgebungsvariablen umbauen, die dann für Group Policies oder auch allgemeine Zwecke benutzt werden können.
Umbau der USF mittels GPP
1. Schritt
Wir erzeugen eine neue Umgebungsvariable mittels GPP.
Zu finden unter:
Computer Configuration or User Configuration
└ Preferences
└ Windows Settings
└ Environment
In unserem Beispiel handelt es sich um "User Configuration".
Als Wert weisen wir jedoch eine temporäre Variable "%TEMPVAR%" zu.
2. Schritt
Diese Variable muss nun gefüllt werden.
Hierbei hilft uns das "Item Level Targeting" kurz ILT.
Wir legen ein ILT auf Basis von "Registry Match Targeting" fest.
Als "Match type" wählen wir "Get value data".
Fertig.
Da zuerst die Filter überprüft werden, wird der betreffende Registrykey ausgelesen. Dieser wird in eine temporäre Variable geschrieben, %TEMPVAR%.
Diese Variable füllt dann unsere "richtige" Variable %LINKS%.
Known Folder GUIDs for File Dialog Custom Places
Auf diesem Wege lassen sich auch die Known Folder GUIDs umbauen.
Allerdings werden diese an unterschiedlichen Stellen in der Registry gespeichert.
Ein Teil davon landet unterhalb der USF.
Der Großteil jedoch unter:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions
Inwieweit sich die KFGs in Variablen umbauen lassen, hängt von den gespeicherten Werten ab.
Fazit:
Mittels Item Level Targeting und der Environment CSE lassen sich sehr flexibel
Registrywerte in benutzbare Umgebungsvariablen umwandeln.
Variablen mit. Drückt man die Taste "F3" in einem Textfeld, so erscheint die
Liste von verfügbaren GPP-Umgebungsvariablen:
Link zu allen GPP-Variablen
Zusätzlich können die vom System bereitgestellten "normalen" User- und Systemvariablen verwendet werden.
So gibt es in den GPP Variablen zum Beispiel keine Komponente für den Pfad
"C:\Program Files (x86)". Es kann die normale Variante "%ProgramFiles(x86)%" benutzt werden.
Teilweise ist dies aber nicht genug.
Dies gilt vor allem für die sogenannten User Shell Folders.
User Shell Folders
Diese USF befinden sich in der Registry unter:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
In diesem Bereich werden Pfade zu Explorer Verzeichnissen gespeichert.
Mit ein paar einfachen Schritten lassen sich diese Schlüssel in Umgebungsvariablen umbauen, die dann für Group Policies oder auch allgemeine Zwecke benutzt werden können.
Umbau der USF mittels GPP
1. Schritt
Wir erzeugen eine neue Umgebungsvariable mittels GPP.
Zu finden unter:
Computer Configuration or User Configuration
└ Preferences
└ Windows Settings
└ Environment
In unserem Beispiel handelt es sich um "User Configuration".
Als Wert weisen wir jedoch eine temporäre Variable "%TEMPVAR%" zu.
2. Schritt
Diese Variable muss nun gefüllt werden.
Hierbei hilft uns das "Item Level Targeting" kurz ILT.
Wir legen ein ILT auf Basis von "Registry Match Targeting" fest.
Als "Match type" wählen wir "Get value data".
Fertig.
Da zuerst die Filter überprüft werden, wird der betreffende Registrykey ausgelesen. Dieser wird in eine temporäre Variable geschrieben, %TEMPVAR%.
Diese Variable füllt dann unsere "richtige" Variable %LINKS%.
Known Folder GUIDs for File Dialog Custom Places
Auf diesem Wege lassen sich auch die Known Folder GUIDs umbauen.
Allerdings werden diese an unterschiedlichen Stellen in der Registry gespeichert.
Ein Teil davon landet unterhalb der USF.
Der Großteil jedoch unter:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions
Inwieweit sich die KFGs in Variablen umbauen lassen, hängt von den gespeicherten Werten ab.
Fazit:
Mittels Item Level Targeting und der Environment CSE lassen sich sehr flexibel
Registrywerte in benutzbare Umgebungsvariablen umwandeln.
Montag, 5. November 2012
Windows 8: GPP Drive Mapping als Administrator schlägt fehl
*** Informationen zum Update KB2795944 siehe Ende des Posts ***
Unter Windows 8 und Server 2012 gibt es einen Bug, der das Mapping von Laufwerken fehlschlagen lässt.
Der Fehler tritt unter folgender Konstellation auf:
EnableLinkedConnections:
Einigen sollte ein ähnlicher Fehler bekannt sein, der im Zusammenhang mit der
Benutzerkontensteuerung und Anmeldeskripten auftritt.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;937624
http://think-like-a-computer.com/2011/06/16/login-scrips-fail-map-drives/
Die Kurzfassung: Anmeldeskripte werden mit dem vollständigen Access-Token ausgeführt, insofern der Benutzer administrative Rechte auf dem Client hat.
Die Laufwerke werden folglich mit dem vollständigen Token gemappt.
Die Benutzersession (explorer.exe usw.) läuft jedoch unter dem gefilterten Token (welcher weniger Rechte besitzt).
Da beide Token eine unterschiedliche Logon-ID besitzen, schlägt der Zugriff auf die Laufwerke fehl.
Zitat Microsoft:
If a user is logged on to Windows Vista or to Windows 7, and if User Account Control is enabled, a program that uses the user’s filtered access token and a program that uses the user’s full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs.
Das Verhalten lässt sich mittels des Registry-Keys "EnableLinkedConnections" abstellen. Ein anderer Workaround ist das Skript "launchapp.wsf".
Zurück zu unserem Problem.
Da der Drive Mapping Fehler bei Windows 8 und Server 2012 auch bei komplett deaktivierter UAC auftritt, trifft das "EnableLinkedConnections" Problem nicht zu.
Von einigen Usern wurden bereits Supportanfragen zu diesem Thema bei Microsoft eröffnet.
Der Fehler wurde auch von mir bei Microsoft eingereicht.
Nach langem Hin und Her lautet das Ergebnis:
By Design.
By Design ist bei Microsoft alles, was man nix fixen will bzw. was
"so ist, wie es ist". Toll.
Wie ihr den Fehler dennoch umgehen könnt, erfahrt ihr hier:
Der Workaround
Im Item der Preference muss die Reconnect-Option deaktiviert werden:
Dies hat allerdings folgenden Nachteil:
User die sich ohne Netzwerkverbindung anmelden, erhalten keine Laufwerke.
Da die CSE "GPP Drive Maps" standardmäßig nur im Vordergrund ausgeführt werden kann, werden die Laufwerke erst dann wieder verbunden, wenn der Benutzer sich das nächste Mal mit Netzwerkverbindung anmeldet.
Dies ist insbesondere ein Nachteil für VPN Benutzer.
Zu hoffen bleibt, dass Microsoft die Auswirkungen dieses Bugs erkennt und eine "richtige" Lösung präsentiert.
Die Hoffnung stirbt zuletzt.
Update 13.02.2013:
Microsoft hat nun reagiert und ein Update bereitgestellt, welches den Fehler beheben soll.
Leider wird in der Beschreibung dieses Updates nicht weiter auf das Drive-Mapping Problem eingegangen.
Es handelt sich um ein "reguläres", nicht kritisches Update (als kein Hotfix), welches unter anderem auch per WSUS verfügbar ist.
http://support.microsoft.com/kb/2795944
Unter Windows 8 und Server 2012 gibt es einen Bug, der das Mapping von Laufwerken fehlschlagen lässt.
Der Fehler tritt unter folgender Konstellation auf:
- Die Laufwerke werden per GPP Drive Mapping gemappt
- Als Betriebssystem wird Windows 8 oder Server 2012 eingesetzt
- Das gemappte Laufwerk befindet sich in einem DFS-Namespace
- Der DFS-Namespace läuft auf Windows Server 2008 R2, 2008 oder 2003
(nicht 100%ig verifiziert) - Der Benutzer der sich anmeldet, ist Mitglied der lokalen Gruppe "Administrators" (SID S-1-5-32-544)
- Die Option "Reconnect" im GPP Item ist aktiviert
- Der Fehler tritt selbst bei komplett deaktivierter UAC auf
- Die Laufwerke werden nicht verbunden
- Teilweise bei erster Übernahme der Policy wird jedoch das Laufwerk gemappt
- Das Tracing der GPP Drive Maps CSE zeigt keine Fehler
- Innerhalb des RSOP wird als Status der CSE "Pending" angezeigt
EnableLinkedConnections:
Einigen sollte ein ähnlicher Fehler bekannt sein, der im Zusammenhang mit der
Benutzerkontensteuerung und Anmeldeskripten auftritt.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;937624
http://think-like-a-computer.com/2011/06/16/login-scrips-fail-map-drives/
Die Kurzfassung: Anmeldeskripte werden mit dem vollständigen Access-Token ausgeführt, insofern der Benutzer administrative Rechte auf dem Client hat.
Die Laufwerke werden folglich mit dem vollständigen Token gemappt.
Die Benutzersession (explorer.exe usw.) läuft jedoch unter dem gefilterten Token (welcher weniger Rechte besitzt).
Da beide Token eine unterschiedliche Logon-ID besitzen, schlägt der Zugriff auf die Laufwerke fehl.
Zitat Microsoft:
If a user is logged on to Windows Vista or to Windows 7, and if User Account Control is enabled, a program that uses the user’s filtered access token and a program that uses the user’s full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs.
Das Verhalten lässt sich mittels des Registry-Keys "EnableLinkedConnections" abstellen. Ein anderer Workaround ist das Skript "launchapp.wsf".
Zurück zu unserem Problem.
Da der Drive Mapping Fehler bei Windows 8 und Server 2012 auch bei komplett deaktivierter UAC auftritt, trifft das "EnableLinkedConnections" Problem nicht zu.
Von einigen Usern wurden bereits Supportanfragen zu diesem Thema bei Microsoft eröffnet.
Der Fehler wurde auch von mir bei Microsoft eingereicht.
Nach langem Hin und Her lautet das Ergebnis:
By Design.
By Design ist bei Microsoft alles, was man nix fixen will bzw. was
"so ist, wie es ist". Toll.
Wie ihr den Fehler dennoch umgehen könnt, erfahrt ihr hier:
Der Workaround
Im Item der Preference muss die Reconnect-Option deaktiviert werden:
Dies hat allerdings folgenden Nachteil:
User die sich ohne Netzwerkverbindung anmelden, erhalten keine Laufwerke.
Da die CSE "GPP Drive Maps" standardmäßig nur im Vordergrund ausgeführt werden kann, werden die Laufwerke erst dann wieder verbunden, wenn der Benutzer sich das nächste Mal mit Netzwerkverbindung anmeldet.
Dies ist insbesondere ein Nachteil für VPN Benutzer.
Zu hoffen bleibt, dass Microsoft die Auswirkungen dieses Bugs erkennt und eine "richtige" Lösung präsentiert.
Die Hoffnung stirbt zuletzt.
Update 13.02.2013:
Microsoft hat nun reagiert und ein Update bereitgestellt, welches den Fehler beheben soll.
Leider wird in der Beschreibung dieses Updates nicht weiter auf das Drive-Mapping Problem eingegangen.
Es handelt sich um ein "reguläres", nicht kritisches Update (als kein Hotfix), welches unter anderem auch per WSUS verfügbar ist.
http://support.microsoft.com/kb/2795944
Mittwoch, 26. September 2012
Geplante Aufgabe als SYSTEM ausführen - Fehler 0x80070534
Die CSE "Scheduled Tasks"
Die Group Policy CSE "Scheduled Tasks" bietet eine einfache Möglichkeit
Aufgaben per Richtlinie zu konfigurieren.
Die Tasks können entweder per Benutzerkonfiguration oder Computerkonfiguration erstellt werden.
Benutzt man die User-Config, so lässt sich die Aufgabe zum Beispiel als angemeldeter Benutzer ausführen.
Es können die Variablen "%LogonDomain%\%LogonUser%" benutzt werden.
Kennwort speichern?
Anders schaut es bei der Computerkonfiguration aus.
Hier muss explizit ein Benutzer angegeben werden:
Es kann ein lokaler Benutzer oder ein Domänenbenutzer verwendet werden.
Verteilt man "Geplante Aufgaben" per Group Policy Preferences,
so möchte man in der Regel jedoch nicht das Passwort in der Group Policy speichern.
Die Begründung liefert unter anderem dieser Technet Blog:
quelle:
http://blogs.technet.com/b/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx
Welchen Account benutzen?
Welchen Account könnte man also benutzen, der ausreichend Rechte auf dem Computer hat, jedoch es nicht erfordert ein Passwort zu speichern?
Die Antwort:
SYSTEM
OK, nichts leichter als das.
Per Object-Picker auswählen und gut ist es!?
Eingetragen wird anschließend "BUILTIN\SYSTEM" im UI des
GPP Items.
Wie verhält sich der Client?
Gleich vorneweg, der Task wird niemals am Client erzeugt werden.
Aktiviert man das Tracing der CSE, so erhält man folgenden Fehler:
[ hr = 0x80070534 "Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt." ]
Der Benutzer "BUILTIN\SYSTEM" kann also nicht zugeordnet werden.
Nächster Versuch, manuelles eingeben des Benutzers "SYSTEM":
Das Policy Item lässt sich speichern.
Am Client schlägt allerdings der gleiche Fehler auf, 0x80070534.
Wie verhält es sich, wenn der Task manuell angelegt wird?
Aufgaben werden im XML Format bereitgestellt.
Wenn wir manuell einen Task erzeugen, kann dieser als XML Datei exportiert werden.
<Principals>
<Principal id="Author">
<UserId>S-1-5-18</UserId>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
Der User "SYSTEM" (genau genommen ist dies gar kein User, aber egal),
wird also mit seiner SID "S-1-5-18" eingetragen.
Schaut man sich allerdings das XML File der Policy an, wird er mit diesem Wert
hinzugefügt:
runAs="BUILTIN\SYSTEM"
Der Client kann dies nicht umsetzen und quittiert dies mit dem genannten Fehler.
Erzeugt man die Policy mit der SID, wird sie am Client übernommen.
Der Client übersetzt sogar die SID zum User "SYSTEM".
Fazit:
Sollen Tasks als Local System ausgeführt werden, so muss die SID als Benutzername verwendet werden.
Hier noch eine Liste der "Well-known security identifiers"
http://support.microsoft.com/kb/243330/en-us
Die Group Policy CSE "Scheduled Tasks" bietet eine einfache Möglichkeit
Aufgaben per Richtlinie zu konfigurieren.
Die Tasks können entweder per Benutzerkonfiguration oder Computerkonfiguration erstellt werden.
Benutzt man die User-Config, so lässt sich die Aufgabe zum Beispiel als angemeldeter Benutzer ausführen.
Es können die Variablen "%LogonDomain%\%LogonUser%" benutzt werden.
Kennwort speichern?
Anders schaut es bei der Computerkonfiguration aus.
Hier muss explizit ein Benutzer angegeben werden:
Es kann ein lokaler Benutzer oder ein Domänenbenutzer verwendet werden.
Verteilt man "Geplante Aufgaben" per Group Policy Preferences,
so möchte man in der Regel jedoch nicht das Passwort in der Group Policy speichern.
Die Begründung liefert unter anderem dieser Technet Blog:
To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.
Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.
quelle:
http://blogs.technet.com/b/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx
Welchen Account benutzen?
Welchen Account könnte man also benutzen, der ausreichend Rechte auf dem Computer hat, jedoch es nicht erfordert ein Passwort zu speichern?
Die Antwort:
SYSTEM
OK, nichts leichter als das.
Per Object-Picker auswählen und gut ist es!?
GPP Items.
Wie verhält sich der Client?
Gleich vorneweg, der Task wird niemals am Client erzeugt werden.
Aktiviert man das Tracing der CSE, so erhält man folgenden Fehler:
[ hr = 0x80070534 "Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt." ]
Der Benutzer "BUILTIN\SYSTEM" kann also nicht zugeordnet werden.
Nächster Versuch, manuelles eingeben des Benutzers "SYSTEM":
Das Policy Item lässt sich speichern.
Am Client schlägt allerdings der gleiche Fehler auf, 0x80070534.
Wie verhält es sich, wenn der Task manuell angelegt wird?
Aufgaben werden im XML Format bereitgestellt.
Wenn wir manuell einen Task erzeugen, kann dieser als XML Datei exportiert werden.
<Principals>
<Principal id="Author">
<UserId>S-1-5-18</UserId>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
Der User "SYSTEM" (genau genommen ist dies gar kein User, aber egal),
wird also mit seiner SID "S-1-5-18" eingetragen.
Schaut man sich allerdings das XML File der Policy an, wird er mit diesem Wert
hinzugefügt:
runAs="BUILTIN\SYSTEM"
Der Client kann dies nicht umsetzen und quittiert dies mit dem genannten Fehler.
Erzeugt man die Policy mit der SID, wird sie am Client übernommen.
Der Client übersetzt sogar die SID zum User "SYSTEM".
Fazit:
Sollen Tasks als Local System ausgeführt werden, so muss die SID als Benutzername verwendet werden.
Hier noch eine Liste der "Well-known security identifiers"
http://support.microsoft.com/kb/243330/en-us
Freitag, 31. August 2012
Group Policy Preferences ohne Verbindung zum DC - kann das gut gehen?
Was ist Item Level Targeting?
Eines der meist genutzten Features der Group Policy Preferences ist das "Item Level Targeting". Mithilfe des ILT lassen sich einzelne Elemente mit einer
großen Anzahl an vorgefertigten Filtern versehen.
Noch bevor es die Preferences gab, konnte nur unterschieden werden,
ob die gesamte Richtlinie bzw. der Benutzer- oder Computeranteil für den jeweiligen Anwender bzw. Computer gültig ist.
Item Level Targeting geht hier einen Schritt weiter und filtert innerhalb einer bereits zutreffenden Richtlinie die einzelnen Elemente.
Eine Liste aller ILTs findet ihr hier:
http://technet.microsoft.com/en-us/library/cc733022.aspx
Hat man erst einmal die Logik hinter den ILTs verstanden, lassen sich relativ einfach selbst komplexe Filter bilden.
Typische Beispiele:
Eine relativ beliebter Filter ist des "IP Address Range Targeting".
Stellen wir uns zum Beispiel folgendes Szenario vor:
Das erste Item setzt die Variable auf "YES":
Wir erzeugen ein Item Level Targeting:
Nun erzeugen wir das Item, dass die Variable auf "NO" setzt, sobald wir in einem anderen Netzwerk als 172.16.0.0 bzw. 172.17.0.0 sind:
Dass sollte es gewesen sein.
Und nun der Funktionstest:
Zuerst innerhalb des Firmennetzwerkes:
Die Variable wird wie erwartet auf "YES" gesetzt.
Nun der Test außerhalb des Firmennetzwerkes (192.168.0.0).
Der Rechner wird zusätzlich gebootet.
Die Variable steht wider Erwarten auf "YES".
Ein Blick ins gpsvc.log verrät:
GPSVC(3a4.414) 08:59:32:968 Wait for network connectivity timed out... proceeding to apply policy.
GPSVC(3a4.414) 08:59:33:234 NlaQueryNetSignatures returned 1 networks
GPSVC(3a4.414) 08:59:33:234 NlaGetIntranetCapability failed with 0x15
GPSVC(3a4.414) 08:59:33:234 There is no domain compartment
etwas später:
Der Policy Zyklus schlägt fehl.
Für die "normalen" Policies ist dies kaum von Bedeutung.
Bei den Preferences hat dies jedoch eine massive Auswirkung.
Die Policy wird nicht gelesen und es kann auch nicht auf das XML-File der Policy zugegriffen werden.
Im XML-File der Policy befinden sich ebenfalls die Item Level Targetings.
Die Variable wird nicht wie erwartet geändert.
Fazit:
Um Richtlinien korrekt anwenden zu können, benötigen wir also immer eine Verbindung zum Domaincontroller bzw. zum Firmennetzwerk.
Preferences die sich auf unterschiedliche Netzwerke beziehen, funktionieren nur dann, wenn aus diesen Netzwerken heraus ein Domaincontroller erreichbar ist.
Da viele Einstellungen die per Group Policy Preferences geschrieben werden, auch direkt vom Benutzer geändert werden können (Einstellungen die im Benutzeranteil der Policy definiert sind), hat man keine Kontrolle über diese Einstellungen wenn keine Verbindung zum DC besteht.
Wollen wir zum Beispiel einen Registrykey setzen, funktioniert das
perfekt solange der Benutzer sich innerhalb des Firmennetzwerkes befindet.
(selbst wenn der Benutzer den Key ändert, wird er beim nächsten Policy-Zyklus erneut gesetzt)
Verlässt er jedoch dieses Firmennetzwerk, so kann er den Key unter Umständen ändern und er wird erst dann erneut gesetzt, wenn der Benutzer wieder Kontakt zum Domänennetzwerk hat.
Eines der meist genutzten Features der Group Policy Preferences ist das "Item Level Targeting". Mithilfe des ILT lassen sich einzelne Elemente mit einer
großen Anzahl an vorgefertigten Filtern versehen.
Noch bevor es die Preferences gab, konnte nur unterschieden werden,
ob die gesamte Richtlinie bzw. der Benutzer- oder Computeranteil für den jeweiligen Anwender bzw. Computer gültig ist.
Item Level Targeting geht hier einen Schritt weiter und filtert innerhalb einer bereits zutreffenden Richtlinie die einzelnen Elemente.
Eine Liste aller ILTs findet ihr hier:
http://technet.microsoft.com/en-us/library/cc733022.aspx
Wie kann ich mir diese Filter zunutze machen?
Hat man erst einmal die Logik hinter den ILTs verstanden, lassen sich relativ einfach selbst komplexe Filter bilden.
Typische Beispiele:
- Alle Notebooks / alle Desktops
- Filter auf die Betriebssystemversion
- Filter auf Sicherheitsgruppen
- Benutzerdefinierte LDAP Filter
- WMI Filter
- IP-Range Filter
Und nun ein typisches Szenario:
Eine relativ beliebter Filter ist des "IP Address Range Targeting".
Stellen wir uns zum Beispiel folgendes Szenario vor:
- Wir möchten eine Umgebungsvariable "OFFICE" erzeugen
- Diese Variable soll auf "YES" gesetzt werden, so lange der Rechner mit dem Firmennetzwerk verbunden ist
- Ist der Rechner außerhalb des Firmennetzwerkes, soll die Variable auf "NO" gesetzt werden
Das erste Item setzt die Variable auf "YES":
Nun erzeugen wir das Item, dass die Variable auf "NO" setzt, sobald wir in einem anderen Netzwerk als 172.16.0.0 bzw. 172.17.0.0 sind:
Dass sollte es gewesen sein.
Und nun der Funktionstest:
Zuerst innerhalb des Firmennetzwerkes:
Die Variable wird wie erwartet auf "YES" gesetzt.
Nun der Test außerhalb des Firmennetzwerkes (192.168.0.0).
Der Rechner wird zusätzlich gebootet.
Die Variable steht wider Erwarten auf "YES".
Was ist hier also passiert?
Ein Blick ins gpsvc.log verrät:
GPSVC(3a4.414) 08:59:32:968 Wait for network connectivity timed out... proceeding to apply policy.
GPSVC(3a4.414) 08:59:33:234 NlaQueryNetSignatures returned 1 networks
GPSVC(3a4.414) 08:59:33:234 NlaGetIntranetCapability failed with 0x15
GPSVC(3a4.414) 08:59:33:234 There is no domain compartment
etwas später:
GPSVC(3a4.50c) 08:59:49:484 NlaGetIntranetCapability returned Not Ready error. Consider it as NOT intranet capable.
GPSVC(3a4.50c) 08:59:49:484 There is no connectivity
GPSVC(3a4.50c) 08:59:49:484 There is no connectivity
Der Policy Zyklus schlägt fehl.
Für die "normalen" Policies ist dies kaum von Bedeutung.
Bei den Preferences hat dies jedoch eine massive Auswirkung.
Die Policy wird nicht gelesen und es kann auch nicht auf das XML-File der Policy zugegriffen werden.
Im XML-File der Policy befinden sich ebenfalls die Item Level Targetings.
Die Variable wird nicht wie erwartet geändert.
Fazit:
Um Richtlinien korrekt anwenden zu können, benötigen wir also immer eine Verbindung zum Domaincontroller bzw. zum Firmennetzwerk.
Preferences die sich auf unterschiedliche Netzwerke beziehen, funktionieren nur dann, wenn aus diesen Netzwerken heraus ein Domaincontroller erreichbar ist.
Da viele Einstellungen die per Group Policy Preferences geschrieben werden, auch direkt vom Benutzer geändert werden können (Einstellungen die im Benutzeranteil der Policy definiert sind), hat man keine Kontrolle über diese Einstellungen wenn keine Verbindung zum DC besteht.
Wollen wir zum Beispiel einen Registrykey setzen, funktioniert das
perfekt solange der Benutzer sich innerhalb des Firmennetzwerkes befindet.
(selbst wenn der Benutzer den Key ändert, wird er beim nächsten Policy-Zyklus erneut gesetzt)
Verlässt er jedoch dieses Firmennetzwerk, so kann er den Key unter Umständen ändern und er wird erst dann erneut gesetzt, wenn der Benutzer wieder Kontakt zum Domänennetzwerk hat.
Abonnieren
Posts (Atom)




























