Wenn Sie schon einmal mit FIM gearbeitet haben, wissen Sie, dass die Migration einer FIM-Dienstkonfiguration von einer Umgebung in eine andere sehr schwierig sein kann.
Microsoft stellt zwar ein Verfahren, einige Skripte und einige zugrunde liegende PowerShell-Primitive zur Unterstützung des Prozesses zur Verfügung, aber die vorgeschlagene Lösung geht davon aus, dass Sie eine gesamte Konfiguration migrieren und nicht mehrere Konfigurationen verwalten müssen. Fairerweise muss gesagt werden, dass das, was Microsoft anbietet, nur ein Vorschlag für einen Ausgangspunkt ist.
In diesem Blogbeitrag werde ich ein Verfahren vorstellen, das wir bei CSS entwickelt haben, um den Migrationsprozess zu verbessern. Wir haben sicherlich nicht alle Probleme gelöst, aber wir hoffen, dass Sie das, was wir getan haben, hilfreich und nützlich für die Erstellung Ihres eigenen Migrationsprozesses für FIM-Dienste finden.
Im TechNet-Artikel über die Migration von FIM-Konfigurationen ist die Rede von der Sicherung der Datenbanken, dem Extrahieren der Konfiguration für den FIM-Dienst und die Sync-Engine, dem Kopieren des FIM-Dienst-Workflows und der Erweiterungs-DLLs der Sync-Engine, dem Vergleichen der FIM-Dienst-Konfigurationen und dem Importieren der Änderungen des FIM-Dienstes in das Zielsystem. Viele dieser Schritte sind wichtig (insbesondere das Backup), werden aber in diesem Beitrag nicht behandelt. Ich werde nur auf die Migration von Schema und Richtlinien im FIM-Dienst selbst eingehen. Bitte nehmen Sie sich die Zeit, den TechNet-Artikel (oben und unten verlinkt) zu lesen.
Um die Verwaltung mehrerer Konfigurationen zu erleichtern, haben wir die PowerShell-Skripte aktualisiert, um Verzeichnisse zu erstellen und mit ihnen zu arbeiten, die einzelne Konfigurationen enthalten. Durch die Automatisierung der Erstellung konfigurationsbezogener Verzeichnisse verringern wir die Fehler, die beim manuellen Kopieren und Umbenennen von Dateien auftreten können, wie es beim Migrationsprozess der Standardkonfiguration erforderlich ist.
Der erste Schritt besteht darin, die Skripte und das Deltatool zu beschaffen. Sie sind hier verfügbar . Entpacken Sie die Dateien in ein Verzeichnis mit dem Namen "FIM Service Migration" oder ähnlich. Führen Sie dies sowohl auf Ihren Entwicklungs- als auch auf Ihren Produktionsrechnern durch (oder in den Umgebungen, zwischen denen Sie migrieren).
Führen Sie anschließend das Skript ExportConfig.ps1 in beiden Umgebungen aus. Dieses Skript kombiniert die Funktionen der Originalskripte ExportSchema und ExportPolicy und legt die resultierenden Exportdateien in einem Unterverzeichnis mit dem aktuellen Datum und der aktuellen Uhrzeit ab. Beachten Sie, dass Sie dieses Skript wie die Original-Microsoft-Skripte mit einem Konto ausführen müssen, das sich in der Gruppe der "Administratoren" des FIM-Dienstes befindet. Andernfalls erhalten Sie keinen vollständigen Konfigurationsexport.
Da das vom Skript ExportConfig erstellte Verzeichnis eine FIM-Service-Konfiguration für eine bestimmte Umgebung zu einem bestimmten Zeitpunkt darstellt, sollten Sie das Verzeichnis in etwas umbenennen, das für Sie aussagekräftiger ist. Ich würde empfehlen, zumindest den Namen der Umgebung und entweder einen Zeitstempel oder eine Versionsnummer hinzuzufügen. In diesem Beispiel werde ich den obigen Export (vom Entwicklungsrechner) in "Dev-20140429" umbenennen, um anzuzeigen, dass es sich um die Konfiguration der Entwicklungsumgebung vom 29. April handelt. Auf dem Produktionscomputer werde ich dasselbe tun, aber den Verzeichnisnamen "Prod-20140429" verwenden. Kopieren Sie das Verzeichnis vom Entwicklungscomputer auf den Produktionscomputer, so dass sich beide Verzeichnisse auf dem Produktionscomputer befinden. Auf dem Produktionscomputer sollten Sie etwa Folgendes haben:
Führen Sie anschließend das Skript DiffConfig.ps1 aus. Dieses Skript kombiniert die Funktionen der Originalskripte SyncSchema und SyncPolicy. Anstatt dass Sie die Exportdateien für jeden Schema- und Richtlinienextrakt in pilot.xml und production.xml umbenennen müssen (und sich merken müssen, welche Dateien welche sind), nimmt das DiffConfig-Skript stattdessen die Verzeichnisnamen aus den vorherigen Schritten als Parameter. Der Parameter SourceDirectory ist die neue Konfiguration, die Sie irgendwo anwenden wollen (in unserem Fall die Entwicklungsumgebung), und der Parameter TargetDirectory ist die Konfiguration, auf die wir die Quellkonfiguration anwenden wollen (in unserem Fall die Produktionsumgebung). Wir wollen die Quelle auf das Ziel anwenden (so dass das Ziel wie die Quelle aussieht).
Das Skript berechnet, welche Änderungen auf dem Ziel erforderlich sind, und erstellt eine Reihe von Änderungsdateien. Diese Dateien werden in ein neues Verzeichnis mit dem Namen "Diff-", gefolgt von den Namen der Quell- und Zielverzeichnisse, abgelegt.
Das Skript verwendet die gleichen Techniken (FIM PowerShell-Automatisierungs-Cmdlets) wie die Microsoft-Skripte und hat die gleichen Probleme. Wenn Sie Instanzen von Objekten haben, die nicht eindeutige Anzeigenamen haben, oder wenn Sie benutzerdefinierte Ressourcentypen erstellt haben, müssen Sie möglicherweise Ihre Daten bereinigen oder die Verknüpfungsregeln im Skript bearbeiten (im Übrigen kann der vorherige Exportprozess ähnliche Probleme haben, wenn es ungültige Verweise in Ihrer Konfiguration gibt oder wenn Sie Zeichenfolgenwerte haben, die wie Verweise auf die Automatisierungs-Cmdlets "aussehen").
Ein Blick in das resultierende Verzeichnis zeigt nun Folgendes:
Abgesehen von den Dateinamen sind diese Dateien identisch mit den changes.xml-Dateien, die von den Skripten SyncSchema und SyncPolicy bereitgestellt wurden. Wenn wir wüssten, dass wir alle berechneten Änderungen übernehmen wollen, könnten wir diese Dateien einfach auf die Produktionsumgebung anwenden und wären fertig.
Was aber, wenn wir in der Entwicklungsumgebung Dinge haben, die wir nicht in die Produktion übernehmen wollen?
In unserem Beispiel enthält die Entwicklungsumgebung einige zusätzliche Ressourcentypen, die versehentlich erstellt wurden. Sobald Sie im FIM-Dienst einen neuen Objekttyp erstellt und verwendet haben, können Sie ihn nicht mehr löschen, so dass dies zu einem Problem werden kann, wenn Sie keine zusätzlichen Ressourcen in der Produktion wünschen. Unsere Konfiguration umfasst auch einige Sets mit manueller Mitgliedschaft. Wenn wir also nichts Besonderes tun, wird der Migrationsprozess entweder versuchen, die Entwicklungsbenutzer in der Produktion anzulegen, oder sich beschweren, dass er die entsprechenden Benutzer nicht finden kann.
Um dies zu korrigieren, müssten Sie traditionell die Datei changes.xml öffnen und die Objekte herausschneiden, die Sie nicht in die Produktion übernehmen wollen. Wenn Sie nur die genauen Änderungen sehen wollten, die an die Produktion übermittelt werden sollten, mussten Sie die Änderungsdatei von Hand prüfen. Die Inspektion und Bearbeitung der Änderungsdatei ist schwierig und fehleranfällig, da sie Objekte intern anhand ihrer GUID-Ressourcen-IDs identifiziert und viele Objekte Verweise auf andere Objekte enthalten. Die falsche Bearbeitung eines Objekts oder die Unterbrechung einer Verweiskette kann im späteren Verlauf des Prozesses zu Importfehlern führen.
Vor etwa einem Jahr hat ein Herr namens Alex Skalozub ein großartiges Tool namens "FimDelta" auf GitHub veröffentlicht. Dieses Tool zeigt den Inhalt einer Änderungsdatei in einer grafischen Baumstruktur an und ermöglicht es Ihnen, Elemente zu entfernen, die Sie nicht in die Produktion übernehmen möchten. Änderungen können auf Objekt- oder Attributsebene ausgeschlossen werden. Mit dem Tool können Sie auch leicht durch die Referenzen und Beziehungen zwischen Objekten navigieren. Selbst wenn Sie keine Objekte aus der Produktionsliste ausschließen wollen, ist es ein hervorragendes Werkzeug, um sich einen Überblick über die Änderungen zu verschaffen.
Aus irgendeinem Grund scheint das Tool nicht weit verbreitet zu sein. Die meisten unserer Kunden haben noch nie davon gehört. Das mag daran liegen, dass das Tool etwas schwierig zu starten ist, da Sie die Quell- und Zieldateien sowie die Änderungsdatei in das Verzeichnis, in dem das Tool installiert ist, kopieren und umbenennen müssen.
Um die Nutzung zu vereinfachen und es in unseren Migrationsprozess einzubinden, habe ich einige Aktualisierungen an dem Tool vorgenommen. Ich habe die Möglichkeit hinzugefügt, die benötigten Dateinamen in der Zeile command zu übergeben, und traditionelle "Datei"-Menüs hinzugefügt, so dass Sie innerhalb des Tools zu den benötigten Dateien navigieren und diese öffnen sowie den Namen und den Speicherort der Ausgabedatei angeben können. Ich habe auch die Möglichkeit hinzugefügt, die "Ausnahmen" oder die Dinge, die Sie nicht migrieren möchten, zu speichern und wiederherzustellen. Dies kann Zeit sparen, wenn Sie mehrere Migrationen durchführen müssen.
Das aktualisierte Tool ist zusammen mit den Migrationsskripten im obigen Link enthalten, und der aktualisierte Quellcode ist auf GitHub verfügbar (wie bei allen kostenlosen Produkten erfolgt die Verwendung auf eigene Gefahr, ohne Garantie usw.).
Schauen wir uns das Tool an und sehen wir uns an, wie wir die Schemaänderungen ausschließen, die wir in der Entwicklung haben, aber nicht in der Produktion verwenden wollen. Das Skript LaunchFimDelta.ps1 startet das Tool und gibt ihm die erforderlichen Dateinamen. Sie werden sehen, dass es die gleichen Parameter wie das DiffConfig-Skript plus einen weiteren benötigt. Das bedeutet, dass Sie, wenn Sie gerade das Diff-Skript ausgeführt haben, den Pfeil nach oben drücken, den Namen des Skripts bearbeiten, die Ende-Taste drücken und den Kategorie-Parameter hinzufügen können. Der Kategorie-Parameter nimmt entweder "schema" oder "policy_portal" an, je nachdem, welchen Satz von Änderungen Sie untersuchen.
Wenn das Tool geöffnet wird, sehen Sie das Dialogfeld "Dateien öffnen", klicken Sie einfach auf OK. Wenn Sie das Tool manuell ausführen, müssen Sie die Quell- und die Zieldatei sowie die durch den Vergleichsprozess erzeugte Änderungsdatei angeben. Beachten Sie, dass das Tool wahrscheinlich abstürzt, wenn Sie ihm eine Reihe von Dateien übergeben, die nicht zusammenpassen.
Die Einzelheiten zur Verwendung des Tools sind Gegenstand eines weiteren Blogbeitrags, aber Sie können die Änderungen nach Vorgang oder Objekttyp sortieren und viel Zeit damit verbringen, Ihre Änderungsdatei zu untersuchen und zu filtern. Für diese Erzählung werden wir einige unerwünschte Objekttypen ausschließen:
Wie Sie sehen, habe ich fünf Ressourcentypen (Objekttypen), die nicht in die Produktionsumgebung übertragen werden sollen, abgewählt und den einen neuen Ressourcentyp (Standort), der in die Produktionsumgebung übertragen werden soll, markiert gelassen.
Wir speichern nun unsere Änderungen (Datei, Speichern unter). Standardmäßig hängt das Tool "_filtered" an den Dateinamen an und speichert die Datei in demselben Verzeichnis, aus dem die Änderungsdatei stammt.
Als Nächstes werden wir verhindern, dass die Entwicklungsbenutzer in die Produktion migriert werden. Der nächste Screenshot zeigt, wie das Delta-Tool nach Ausführung des Skripts LaunchFimDelta aussieht, diesmal mit der Option policy_portal:
Ich habe die Änderungen nach Objekttyp gruppiert, und Sie können Beispiele für die verschiedenen Nicht-Schema-Objekttypen sehen, die Teil einer FIM-Dienstkonfiguration sind. Ich habe alle "Person"-Objekte deaktiviert, weil ich keine Identitäten von der Entwicklung in die Produktion verschieben möchte. Sie können sehen, dass der Operationstyp "Resolve" ist. Das ist die Operation, die der Importprozess (der als Nächstes kommt) verwendet, um Referenzen auf Objekte abzugleichen, die in der Zielumgebung noch nicht existieren. Da wir keine Benutzer verschieben, wollen wir uns nicht die Mühe machen, nach ihnen zu suchen.
Wenn wir ein wenig nach unten blättern, sehen wir einige Definitionen:
Hier sehen Sie, dass wir uns dafür entscheiden, eine Gruppe mit dem Namen "_Location Admins" zu erstellen, aber die tatsächliche Mitgliedschaft in der Gruppe nicht übertragen werden soll. In der Änderungsdatei werden die Mitglieder der Gruppe als Verweise gespeichert, aber das Delta-Tool ist in der Lage, Ihnen zu zeigen, was die Verweise sind. Der Screenshot zeigt, dass "ce2579dd-204c..." tatsächlich ich in der Entwicklungsumgebung bin. Wenn ich mein Konto in die Produktionsumgebung übernehmen wollte, hätte ich mein Attribut "ExplicitMember" und die entsprechende Auflösungsaktion aktiviert lassen können.
Nach dem Speichern haben wir folgendes in unserem "diff-Verzeichnis":
Nun ist es an der Zeit, die Änderungen tatsächlich in die Produktion zu importieren. Hierfür verwenden wir das Skript CommitChanges.ps1. Dieses Skript kombiniert die Funktionen der ursprünglichen Skripte CommitChanges und ResumeUndoneImports.
Beachten Sie, dass das Skript CommitChanges tatsächlich Änderungen an Ihrer Konfiguration vornimmt. Daher sollten Sie, wie bei jeder Konfigurationsänderung, sicherstellen, dass Sie eine gute Sicherungskopie der FIM-Dienst-Datenbank haben, bevor Sie es ausführen.
CommitChanges benötigt die Änderungsdatei als Parameter. Normalerweise übergeben Sie die "gefilterte" Version der Datei, die Sie gerade mit dem Delta-Tool erstellt haben. Hier ist der Import des Schemas, der sauber abläuft:
Manchmal läuft der Import nicht "sauber" ab. In unserem Fall haben wir einen Fehler beim Importieren der Richtlinie:
In diesem Fall haben wir eine Funktion verwendet, die mit einem Hotfix zu FIM hinzugefügt wurde (die Möglichkeit, den Link für die erweiterte Suche im Portal auszublenden). In der Entwicklungsumgebung haben wir das für die Aktivierung der Funktion erforderliche Schema manuell hinzugefügt und die Verwaltungsregel erstellt, die erforderlich ist, um den Zugriff auf das neue Schema zu ermöglichen. Diese Änderungen wurden noch nicht in der Produktionsumgebung vorgenommen, und zufällig wird die Konfigurationsoption, die die neue Einstellung enthält, vor der erforderlichen MPR angewendet, die eine Änderung der Einstellung ermöglicht. Diese Art von Ordnungsfehler ist ein häufiges Problem bei Konfigurationsmigrationen. Die Lösung besteht darin, es für die Änderungen, die nicht importiert werden konnten, erneut zu versuchen.
Wie das ursprüngliche CommitChanges-Skript gibt auch unser aktualisiertes Skript alle Änderungen aus, die es nicht an das Zielsystem senden konnte. Im Gegensatz zum ursprünglichen Skript wird der Name der "Rückgängig"-Datei aus dem Namen der verwendeten Änderungsdatei und einem Zeitstempel gebildet. Auf diese Weise erhalten Sie eine Historie aller "Rückgängigmachungen".
Das Tolle daran ist, dass die Datei mit den rückgängig gemachten Änderungen dasselbe Format hat wie die Datei mit den Änderungen. Das heißt, wenn Sie die XML-Datei nicht von Hand prüfen wollen, um zu sehen, was es nicht in die Produktion geschafft hat, können Sie sie mit dem Delta-Tool laden...
Das Delta-Tool sagt uns, dass wir versuchen, die Attribute "HideAdvancedSearchLink" (und drei weitere) zu aktualisieren. Das Problem war, dass der MPR, der dies ermöglicht, noch nicht erstellt worden war.
In unserem Fall befand sich der MPR, den wir benötigten, in der ursprünglichen Änderungsdatei (kurz nach der Aktualisierung der PortalUIConfiguration) und ist nun in Produktion. Das bedeutet, dass wir die rückgängig gemachte Datei einfach wieder an das CommitChanges-Skript übermitteln können und damit Erfolg haben:
Wenn wir einen letzten Blick auf unser diff-Verzeichnis werfen, werden wir sehen, dass wir eine schöne Historie der berechneten Änderungen für unser "Release" haben; die Änderungen, die wir tatsächlich in die Produktion übernommen haben; und die Änderungen, mit denen wir Schwierigkeiten hatten:
Abschließend sollten Sie bedenken, dass dieser Prozess nicht nur für die Produktionsmigration gelten muss. Sie können ihn auch verwenden, um den Fortschritt innerhalb einer einzelnen Umgebung zu verfolgen. Der nächste Screenshot zeigt, wie eine Entwicklungsumgebung mit Konfigurationsexporten zu verschiedenen Zeitpunkten aussehen könnte (ignorieren Sie die Zeitpunkte der Dateiaktualisierung - es handelt sich um eine Simulation für den Blogbeitrag, beachten Sie die Verzeichnisnamen...)
Das Verzeichnis "Base3508" enthält einen Export einer frisch installierten und auf Build 3508 gepatchten Version der FIM-Service-Datenbank. Die anderen Verzeichnisse enthalten Exporte der Konfiguration zu den in den Dateinamen angegebenen Daten.
Mit diesen Informationen können wir den DiffConfig-Prozess zu zwei beliebigen Zeitpunkten ausführen:
- Wenn wir wissen wollen, wie unsere gesamte Konfiguration aussieht: Führen Sie "DiffConfig .\Base3508 .\Dev-20140429" aus.
- Wenn wir wissen wollen, was sich zwischen dem 24. und 28. März in der Konfiguration geändert hat: Führen Sie "DiffConfig .\Dev-20140324 .\Dev-20140328" aus.
Das funktioniert auch rückwärts:
- Wenn wir wissen wollen, wie wir die Änderungen zwischen dem 4. April und dem 28. März rückgängig machen können: Führen Sie "DiffConfig .\Dev-20140404 .\Dev-20140328" aus.
- Wenn wir nur einige der Änderungen zwischen dem 4. April und dem 28. März rückgängig machen wollen, können wir wie oben beschrieben vorgehen, aber die (rückwärtsgerichtete) Änderungsdatei durch das FIM-Delta-Tool laufen lassen und die Markierung der Dinge entfernen, die wir nicht rückgängig machen wollen.
- Wenn wir einige Änderungen, die nur in der Produktion vorgenommen wurden, zurückportieren wollen: Führen Sie "DiffConfig .\Prod-xxx .\Dev-xxx" aus. Auch hier können wir das Delta-Tool verwenden, um nur die Änderungen auszuwählen, die wir zurückportieren möchten, ohne andere Änderungen in der Entwicklung zu löschen, die noch nicht vorwärts gerollt wurden.
Der oben beschriebene Prozess ist zwar nicht perfekt, aber er ist eine große Verbesserung gegenüber der manuellen Durchführung. Ich habe festgestellt, dass Migrationen viel einfacher sind, wenn ich es verwende. Ich muss mich nicht mehr mühsam daran erinnern, welche Version der Datei changes.xml vor mir liegt. Ich erschaudere nicht mehr, wenn ich nur einige Konfigurationselemente von einer Umgebung in eine andere verschieben muss. Ich hoffe, Sie finden den oben beschriebenen Prozess und das aktualisierte FIM-Delta-Tool nützlich.
Nützliche Links:
Zip-Datei mit dem aktualisierten FIM-Delta-Tool und den PowerShell-Migrationsskripten: https://www.css-security.com/fdist/FimServiceMigration1.3.zip
Quellcode für das aktualisierte FIM-Delta-Werkzeug: https://github.com/RexWheeler/FIMDelta
TechNet-Artikel über die Migration der FIM-Konfiguration: https://technet.microsoft.com/en-us/library/ff400277%28v=ws.10%29.aspx
Microsoft FIM Migration PowerShell-Skripte: https://technet.microsoft.com/en-us/library/ff400275%28v=ws.10%29.aspx
Dokumentation für FIM PowerShell Cmdlets: https://technet.microsoft.com/en-us/library/ff394179.aspx
