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.

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:
  • 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
Der Fehler äußert sich wie folgt:
  • 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