Fileservermigration, Anpassung von Terminaldiensteprofilen

Ich habe vor kurzem bei einem Migrationsprojekt mitgewirkt, in dem es um die Migration von Dateidiensten ging.

Der Kunde wollte in dieser Migration vom System der lokalen Freigabe \\Servername\Freigabename weg hin zu einem DFS \\Domänen-FQDN\Namespace\Freigabename migrieren. Die Vorteile sind u.a., dass ein einheitlicher Einstiegspunkt in die Freigaben ermöglicht wird, ohne den Servernamen, der die Freigabe hostet, kennen zu müssen. Auch spätere Migrationen von Dateidiensten werden durch ein DFS erheblich vereinfacht.

Die Migration von Dateidiensten bedeutet auch immer, diverse Abhängigkeiten bzgl. Pfadangaben zu prüfen, z.B. in:

  • Gruppenrichtlinien
  • Loginskripten
  • User-Objekten im Active Directory (Homelaufwerk, Profilpfade)
  • Drittanbieterprogrammen (in meinem Beispiel AppSense)

Für die Anpassung der User-Objekte im AD reicht es, die Objekte z.B. in einer OU oder benutzerdefinierten LDAP-Abfrage zu markieren (STRG+A) und über die Eigenschaften entsprechend anzupassen.

 

Damit lassen sich u.a. Profilpfad, Anmeldeskript und Basisordner für viele Benutzer in einem Zug anpassen.
Interessant bei dieser Migration war, dass in früheren Zeiten (zu Windows Server 2003 R2) die Einstellungen für Terminalserverprofile über die User-Objekte im AD konfiguriert wurden. In größeren Umgebungen wird dies üblicherweise über GPOs konfiguriert und nur in Ausnahmefällen im User-Objekt selbst. Problematisch ist, dass der oben beschriebene Weg (über STRG+A…) bei Terminalserver-Profilen (oder heute: Remotedesktopdienste-Profilen) nicht funktioniert.

In der Abbildung oben ist zu erkennen, dass der entsprechende Reiter fehlt. Im folgenden Bild ist der Reiter sichtbar, gilt allerdings auch nur für ein einzelnes User-Objekt. Nun habe ich als nächstes mit CSVDE versucht, alle Userobjekt mit den Attributen „TerminalServicesProfilePath“ bzw. „TerminalServicesHomeDirectory“ auszulesen, um zu erkennen, welche User wir anpassen müssen. Das Ergebnis war eine CSV-Datei mit allen Usern der Domäne. Die abgefragten Attribut wurden nicht gefunden und waren somit nicht in der CSV-Datei vorhanden. ADSIedit bestätigte, dass diese Attribute nicht im User-Objekt abgelegt werden!

 

Lösung:
Ich möchte an dieser Stelle auf folgende Skript-Seite verweisen, welches die Lösung für das Problem brachte: http://gallery.technet.microsoft.com/scriptcenter/d36bd6b8-91b4-482b-8f67-9016cf367dbe
Über dieses Skript können die gewünschten Attribute konfiguriert oder, wie in meinem Fall, gelöscht werden.

Im Übrigen haben wir diese Problematik vor der Umstellung beim Testen entdeckt. Also auch für so eine Migration gilt: Testszenarien entwickeln und testen, testen testen!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.