Login-Scripts über GPOs und User-Eigenschaften konfigurieren

In den letzten Jahren haben Login-Scripts für diese klassischen Aufgaben jedoch Konkurrenz durch bessere Technologien bekommen. Neben UEM-Tools von Drittanbietern sind das ganz besonders die Windows-eigenen Group Policy Preferences (GPP). Sie können Netzlaufwerke verbinden, zentrale Drucker zuweisen, Registry-Einträge setzen, INI- oder CFG-Dateien modifizieren oder Dateitypen mit Programmen assoziieren.

Die GPP haben den Vorteil, dass sie keine Programmierung erfordern und daher weniger fehleranfällig sind. Darüber hinaus erlaubt das Item Level Targeting eine exakte Eingrenzung der Aktionen auf bestimmte User oder Computer. Zudem entfällt mittlerweile das Argument, dass GPP ältere Versionen des Betriebssystems nicht unterstützen. Es existiert nämliche eine Implementierung für XP, und ältere Systeme sollten nur noch in IT-Museen laufen.

Und schließlich erfolgt die Ausführung von GPOs abhängig von der gewählten Aktion und der Windows-Version asynchron, so dass der Anmeldevorgang verkürzt wird. Eine Neuerung von Windows 8.1 besteht darin, dass sogar das Laufwerk-Mapping im Hintergrund erfolgt, wodurch Änderungen ohne Ab- und Anmelden des Benutzers während einer Session wirksam werden.

Vorbereitungen für Login-Script

Wen diese Vorteile nicht überzeugen oder wer bei der Benutzeranmeldung Aufgaben erledigen muss, die sich partout nicht über GPP erledigen lassen, kann dafür weiterhin Scripts nutzen. Neben den traditionellen Mitteln wie VB-Script oder Batch steht nun auch PowerShell zur Verfügung, weil es seit Windows 7 zum Lieferumfang des OS gehört.

Es versteht sich von selbst, dass man Login-Scripts ausführlich testet, bevor man sie mit Benutzerobjekten verknüpft. Wichtig ist dabei, dass sie nicht nur im Kontext des Administrators problemlos laufen, sondern auch dann, wenn man sie als normaler User ausführt. Scripts können nämlich an mangelnden Rechten scheitern, wenn sie auf einem Verzeichnis außerhalb des SYSVOL liegen oder wenn sie Dateien lesen, anlegen oder verändern sollen.

Im Fall von PowerShell ist zu bedenken, dass Windows standardmäßig keine Scripts ausführt. Daher wird man diese zuerst freischalten müssen, bei einer größeren Zahl von PCs bevorzugt über Gruppen­richt­linien. Falls ein Script eine neuere Ausführung von PowerShell verlangt, die nicht auf allen Rechnern verfügbar ist, dann kann man über die requires-Anweisung sicherstellen, dass es nur unter bestimmten Versionen läuft (z.B.: #requires -version 2 für PowerShell 2.0 oder höher).

Unter Windows 8.1 ist daran zu denken, dass Login-Scripts standardmäßig mit einer Verzögerung von 5 Minuten ausgeführt werden. Wenn dies zu unerwünschten Effekten führt, kann man dieses Verhalten über eine Gruppen­richt­linie ändern.

Script über AD-Attribut zuweisen

Die eigentliche Zuweisung von Scripts zu Benutzern erfolgt entweder über das ältere Verfahren, bei dem man den Dateinamen des Scripts in das scriptPath-Attribut der User-Objekte schreibt. Dies geschieht typischerweise über Active Directory-Benutzer und -Computer (ADUC), und zwar in den Eigenschaften eines Benutzers auf der Registerkarte Profil.

Standardmäßig liegen die Scripts bei dieser Variante im Verzeichnis \\FQDN\SYSVOL\FQDN\scripts (also zum Beispiel in \\contoso.com\sysvol\­contoso.com\scripts), so dass sie zwischen den Domänen-Controllern repliziert werden. Belässt man es bei diesem Speicherort, dann reicht es, wenn man in ADUC bloß den Dateinamen des Scripts ohne Pfadangabe eintippt.

Es liegt auf der Hand, dass dieses Vorgehen nicht für größere Umgebungen geeignet ist, weil man jedes User-Objekt einzeln konfigurieren muss. Sein Vorteil war lange Zeit, dass die Methode auch mit steinalten Windows-Versionen funktioniert, die noch keine Gruppenrichtlinien unterstützen. Aber dieser Aspekt dürfte heute keine Rolle mehr spielen.

Login- und Logoff-Scripts über GPOs

Die Ausführung von Login-Scripts über GPOs überwindet nicht nur diese Beschränkung, weil man GPOs mit einer ganzen Domäne, Site oder OU verknüpfen und somit vielen Benutzern einfach ein Login-Script zuordnen kann.

Daneben bieten Group Policies die Möglichkeit, Scripts auch beim Abmelden eines Users sowie beim Hoch- oder Herunter­fahren eines Computers automatisch zu starten. Schließlich kann man Benutzern auch mehrere Anmelde-Scripts zuordnen und die Reihenfolge festlegen, in der sie ausgeführt werden.

Die Einstellungen für Anmelde- und Abmelde-Scripts finden sich unter Benutzerkonfiguration => Richtlinien => Windows-Einstellungen => Skripts. Jene, die beim Hoch- und Herunterfahren des PCs ausgeführt werden sollen, finden sich in der Computerkonfiguration unter dem gleichen Pfad.

Der Speicherort für Scripts, die man über GPOs zuweist, ist nicht identisch mit jenem, dem man in Active Directory-Benutzer und -Computer eingibt. Vielmehr befindet er sich in dem Pfad nach dem Muster \\FQDN\SYSVOL\FQDN\policies\<GUID>\user\scripts\logon bzw. logoff.

Mehrere Login-Scripts pro User möglich

Am einfachsten findet man das tatsächliche Verzeichnis, indem man im Konfigurationsdialog von Anmelden oder Abmelden auf den Button Dateien anzeigen klickt. Dies öffnet ein Explorer-Fenster in dem betreffenden Verzeichnis, so dass man seine Scripts einfach dorthin kopieren kann. Anschließend muss man nur mehr den Dialog zum Hinzufügen der Scripts öffnen und die eben kopierten Dateien übernehmen. Bei Bedarf kann man sie über die Schaltflächen Nach oben und Nach unten sortieren.

Für PowerShell bieten die Eigenschaften von Anmelden und Abmelden eine eigene Registerkarte. Sie entspricht weitergehend jener für die Konfiguration anderer Scripts. Neben dem Hinweis, dass Ziel-PCs mindestens unter Windows 7 oder Server 2008 R2 laufen müssen, findet sich hier noch Möglichkeit, die Ausführung von PowerShell vor oder nach den anderen Scripts festzulegen.