«

»

Deploy GPO (Migration Client)

Durch das „Deploy GPO“ werden die geplanten NTFS Berechtigungen über Microsoft Gruppenrichtlinien in das Quellverzeichnis geschrieben.

1. Deploy GPO in migRaven.one

1.1. Automatisches Erstellen der Microsoft GPO durch migRaven.

Beim „Deploy GPO“ wird ein Gruppenrichtlinienobjekt angelegt, das die zu setzenden Berechtigungen enthält. Diese GPO muss nach der Erzeugung dem entsprechenden Server zugordnet werden. Die GPO kann hunderte von Einträgen enthalten. Da beim Setzen der Berechtigungen über GPO nicht die Standard API genutzt wird, die Berechtigungen nur der Reihe nach bearbeiten kann, werden die neuen Berechtigungen über GPO parallel über den Verzeichnisbaum gesetzt. Dieses Verfahren ist rasend schnell und macht es überhaupt möglich die Rechte auf einem produktiven System ohne Einfluss auf die Nutzer zu setzen.

Beim „Deploy GPO“ werden keine Verzeichnisse angelegt, da wir in das Quell-Verzeichnis schreiben. Aus gleichem Grund entfällt das „Deploy Data“. Mit zwei Ausnahmen. Wenn Sie 8MAN-Kompatibilität gewählt haben, werden .id.8MAN-Dateien in den Quell-Ordner geschrieben. Wenn Sie neue Verzeichnisse beim „Design & Work“ angelegt haben, werden diese jetzt erstellt.

Deploy GPO

Bild 1:  Deploy GPO

1.1.1. Die GPO

Danach wird für die Berechtigungen ein Gruppenrichtlinienobjekt angelegt, dessen Name sich zusammensetzt aus dem Projektnamen, dem Datum und der Uhrzeit, z.B. „GPO 01_2016_04_05_16_21_55“. Es enthält die vorgesehenen Berechtigungen. Geschrieben werden die Berechtigungen von migRaven nicht. Das erfolgt im nächsten Schritt durch die Gruppenrichtlinienverwaltung.

Das erstellte GPO enthält die neuen Berechtigungen für die Verzeichnisse. Wird vor der Aktivierung des GPO ein Verzeichnis umbenannt oder verschoben, kann es nicht berechtigt werden. Ein gelöschtes Verzeichnis wird von dem GPO nicht wieder angelegt.

1.1.2. Berechtigungen auf den Einstiegspunkt

Das GPO-Projekt ist das einzige Verfahren in migRaven, bei dem Berechtigungen entfernt werden. migRaven entfernt aus dem Quellverzeichnis alle Berechtigungen. Das ist notwendig, da wir in das gleiche Verzeichnis die neuen Berechtigungen schreiben wollen und ein Gemisch der alten und neuen Berechtigungen wohl nur chaotisch wäre.

Wir wollen gewährleisten, dass Sie nachher noch als Administrator auf die Verzeichnisse zugreifen können und dass Sie Ihre firmeninternen Regeln zur Berechtigung von Shares bzw. Einstiegspunkten realisieren können. Dafür haben wir zwei zusätzliche Eingabefelder vorgesehen (Bild 1). Bei den „Admin-Berechtigten am Einstiegspunkt“ haben wir „Local System“ und „Administratoren“ vorgesehen. Die Berechtigungen für diese Berechtigten werden nach unten vererbt. Bei den „List-Berechtigten am Einstiegspunkt“ sind „Authenticated Users“ vorgesehen. Dabei werden Listrechte nur für diesen Ordner vergeben. Darunter erstellt migRaven Listrechte entsprechend den von Ihnen in der Konfiguration gewünschten Einstellungen.

Die Vorgaben in den beiden Eingabefelden entsprechen den Best Practices. Sie können in beiden Feldern Berechtigte entsprechend Ihren Anforderungen und Regeln ergänzen.

Wichtig: Auch bei Vererbungsunterbrechungen werden die für den Einstiegspunkt vorgesehenen Berechtigten explizit berechtigt.

1.2. Bekannte Probleme

1.2.1. RSAT fehlt auf dem Client „Die COM-Klassenfactory…: Klasse nicht registriert“

Wenn das „Deploy GPO“ lange rödelt und nicht fertig wird, haben Sie möglicherweise das Remoteserver-Verwaltungstool (RSAT) von Microsoft nicht auf dem Client installiert bzw. nicht aktiviert. Folgende Fehlermeldung kann bei  fehlendem RSAT auftreten:

RSAT-Fehler

Auch die falsche RSAT-Version kann Ursache eines Fehlers sein, da es ein eigenes RSAT für jede Windows-Version gibt.

Nach der Aktivierung des RSAT-Tools muss migRaven neu gestartet werden.

Die Anleitung dazu finden Sie im Artikel „Gruppenrichtlinien-Projekt“ im Abschnitt „2.3. Gruppenrichtlinienverwaltung auf Client installieren (RSAT)„.

1.2.2. Fehlermeldung  „Die Policy wurde nicht erstellt. Es sind mehr Daten verfügbar.“

Beim Deploy GPO werden erst die .id.8MAN-Dateien geschrieben. Dann wird das GPO angelegt. Ist dieses sehr groß, ab ca. 3 000 Berechtigungen, kann folgender Fehler auftreten. Das scheint ein Timeout-Fehler des RPCs zu sein und hängt damit von der Leistungsfähigkeit des Systems ab. In der Gruppenrichtlinienverwaltung werden Sie das GPO finden, aber leer.

GPO-Fehler

Unter c:\ProgramData\migRaven\gpo\ finden Sie die von migRaven geplanten GPO-Daten. Ein gesuchtes GPO erkennen Sie an Datum und Uhrzeit und am Inhalt der GptTmpl.inf-Datei im untersten Verzeichnis. Diese Datei können Sie (nach Sicherung) bearbeiten.

2. Gruppenrichtlinienverwaltung (gpmc.msc)

Um die Berechtigungen zu schreiben, müssen wir in die Gruppenrichtlinien-Verwaltung des Servers wechseln.

Dort finden wir in dem Container „Gruppenrichtlinienobjekte“ ein neues Objekt, das mit dem migRaven-Projektnamen beginnt. Gegebenenfalls muss die Anzeige aktualisiert werden.
Rechts unter dem Reiter „Einstellungen“ können Sie sich den Inhalt des Richtlinienobjekts anzeigen lassen.

GPO-Einstellungen

Gruppenrichtlinienverwaltung mit von migRaven erstelltem GPO „KM GmbH_2016_04_18_09_16_41“

Um die Berechtigungen zu schreiben, sind folgende Schritte erforderlich.

2.1. Prüfung der GPO

In der Gruppenrichtlinienverwaltung kann die GPO geprüft werden.

Wenn nötig, können Sie die GPO verändern. Dazu sichern Sie die GPO über das Kontextmenü. Im untersten Verzeichnis der Sicherung,
z.B.  …\{……….}\DomainSysvol\GPO\Machine\microsoft\windows nt\SecEdit\  finden Sie die Datei „GptTmpl.inf“. Nach einem Backup der Datei können Sie sie editieren. In der Gruppenrichtlinienverwaltung wird mit „Einstellungen importieren“ der neue Inhalt in unsere GPO zurückgeladen.

Gründe für eine Änderung der GPO können sein:

  • dass ein Share gescannt wurde und erstmal nur ein Unterordner (z.B. eine Abteilung) bearbeitet werden soll. Also nur für diesen einen Unterordner wird die GPO erstellt. Dann steht in der GPO auch für den Share ein Eintrag (der erste Eintrag) und dieser muss zwingend entfernt werden, da man sonst im Zweifel alle anderen Unterordner mit berechtigt.
  • dass Sie einen Fehler in der GPO gefunden haben. Z.B. wird bei einer Angabe des Quellpfades mit zwei Unterverzeichnissen in der GPO der erste Eintrag den Servernamen enthalten. z.B. \\servername\… Das ist falsch, diese Angabe muss durch den Pfad, mit Laufwerksbuchstabe beginnend, ersetzt werden. Der falsche Eintrag führt dazu, dass die GPO nicht ausgeführt wird.

2.2. Verlinkung des Gruppenrichtlinienobjekts mit dem zu berechtigenden Server

Anfangs hatten wir im AD eine OU („GPO-Projekt“) angelegt mit dem zu migrierenden Server. In der Gruppenrichtlinien-Verwaltung verlinken wird jetzt das neue Gruppenrichtlinienobjekt mit der OU „GPO-Projekt“. Dazu ziehen wir einfach das neue GPO-Objekt auf diese OU.

Wurde keine zusätzliche OU angelegt, muss der Link auf die OU gezogen werden, in der sich der Server befindet.

GPO

2.3. GPUpdate

Standardmäßig aktualisiert Windows durch den Hintergrundprozess die GPOs in einem voreingestellten Intervall von 90 Minuten. D.h. wirksam wird die GPO innerhalb der nächsten 90 Minuten. Um das zu beschleunigen, führen wir „gpupdate /force“ auf dem Server aus.

Das gpupdate kann aber auch remote aus der Gruppenrichtlinienverwaltung heraus gestartet werden.

GPO remote

Im Kontextmenü der OU „GPO-Projekt“ kann mit „Gruppenrichtlinienupdate“ das gpupdate remote angestoßen werden.

Bei diesem Vorgang werden die vorhandenen Berechtigungen durch die von migRaven geplanten Berechtigungen ersetzt. Nach einer unbestimmten Vorbereitungszeit können Sie durch Stichproben die ersten Berechtigungsänderungen erkennen. Der Vorgang kann je nach Datenmenge bis zu einer Stunde dauern.

2.4. Kontrolle

Mit  „gpresult /R“ als Administrator! können Sie prüfen, ob Ihre GPO aktiviert wurde. Unter dem Abschnitt „COMPUTEREINSTELLUNGEN“ bei den „Angewendeten Gruppenrichtlinienobjekten“ stehen die aktivierten GPOs.

gpresult /R

Kontrollieren Sie stichprobenartig, ob in den Verzeichnissen die berechtigten Nutzer und Gruppen durch die Berechtigungsgruppen ersetzt wurden. Ist das nicht geschehen, finden Sie in der Protokolldatei c:\%windir%\security\logs\winlogon.log (Windows Server 2008) Hinweise auf die Ursache. Fehler in der GPO können dazu führen, dass sie nicht ausgeführt wird. Gegebenenfalls müssen Sie die GPO editieren und mit „gpupdate /force“ nochmal starten.

2.5. Verlinkung wieder entfernen

Wurden alle Berechtigungen eingetragen, können Sie die GPO aus der Server-UO entfernen. Bleibt die Verbindung zwischen Server und Gruppenrichtlinienobjekt bestehen, kann auch nach späteren Berechtigungsänderungen die Gruppenrichtlinienverwaltung dieses GPO wieder auf den Share schreiben. Damit gehen spätere Veränderungen wieder verloren. Das ist meist nicht gewollt. Daher sollte nach erfolgreicher Vergabe der Berechtigungen der Link des GPO aus der OU „GPO-Projekt“ wieder entfernt werden.

2.6. Bekannte Probleme

2.6.1. Berechtigte Verzeichnisse mit %-Zeichen im Namen

Wir haben festgestellt, dass das %-Zeichen in berechtigten Verzeichnissen für GPUpdate ein Problem darstellt. Ein GPO mit %-Zeichen in berechtigten Verzeichnissen wird zwar ausgeführt, aber die neuen Berechtigungsgruppen werden in Verzeichnissen mit einem %-Zeichen im Namen nicht angelegt. Da die Gruppen im AD vorhanden sind, können sie manuell berechtigt werden.

2.6.2. NetApp

NetApp reagiert auf das GPO nicht wie Windows. Auf Verzeichnissen mit neuen expliziten Berechtigungen werden die neuen Berechtigungen geschrieben und die alten entfernt, wie es sein soll. Aber die Vererbungen werden nicht in die Unterverzeichnisse geschrieben. Und explizite Berechtigungen in Unterverzeichnissen werden nicht entfernt. (Getestet mit NetApp Release 8.2.3.)

Groß- und Kleinschreibung

Da NetApp auf Linux basiert, ist bei den Verzeichnisnamen auf die Groß- und Kleinschreibung zu achten.