Kürzlich hatte einer unserer Kunden ein Szenario, bei dem er die Historie des Attributs proxyAddresses zwischen zwei Microsoft Active Directory (AD)-Domänen verfolgen musste. Da FIM Sync Service keine Historie der Attributwerte speichert (da es sich lediglich um eine zustandsbasierte Synchronisations-Engine handelt), war hier ein wenig Nachdenken und Planung erforderlich.
Bei der Prüfung der Notwendigkeit, die Historie zu verfolgen, und der Erkundung von Optionen kamen wir auf die Lösung eines einfachen Mechanismus für die Historie mit einer Revision mit FIM Sync.
Ohne zu sehr in die Geschichte einzusteigen, beginnen wir mit einem kurzen Überblick über das Szenario. Es gibt zwei Active Directory (AD)-Domänen (nennen wir sie DomA und DomB) und die Benutzer werden von DomA nach DomB synchronisiert. Etwas komplizierter wird es dadurch, dass jede Domäne ihre eigene Exchange-Umgebung hat und jede Domäne dem Attribut proxyAddresses von E-Mail-aktivierten Benutzerobjekten eindeutige Werte hinzufügt. Bei dieser Konfiguration würde die Sync-Engine normalerweise die Werte im proxyAddresses-Attribut in DomB überschreiben und im Wesentlichen alle Werte löschen, die von der DomB-Exchange-Umgebung hinzugefügt wurden (siehe Abbildung 1).
In diesem Fall brauchten wir also eine Möglichkeit, Werte aus DomA hinzuzufügen, ohne die von DomB hinzugefügten Werte zu überschreiben. Um dies zu erreichen, mussten wir die neuesten Werte aus DomA irgendwo speichern. Indem wir sie in eine SQL-Datenbank einspeicherten, konnten wir sie als ein anderes Attribut in das Metaverse zurückbringen. Dies war eine gute Lösung, da wir sie während des Synchronisierungsprozesses referenzieren mussten, und der integrierte SQL Management Agent (MA) von FIM ermöglichte es uns, die Werte einfach in die SQL-Datenbank zu schreiben und von dort abzurufen (siehe Abbildung 2).
Mit den DomA-Werten in der Datenbank könnten wir auf sie verweisen, wenn sich die Werte in DomA ändern. Die Änderungen würden von DomA einfließen, wir würden die Logik, die wir in der Outbound-Synchronisation benötigen, auf DomB anwenden, indem wir uns auf die neuen Werte von DomA und die vorherigen DomA-Werte beziehen (die jetzt sowohl in der SQL-Datenbank als auch in einem neuen Attribut im Metaverse gespeichert sind). Damit hätten wir eine Historie mit nur einer Überarbeitung, was alles ist, was wir brauchen.
Um dies einzurichten, mussten wir die folgenden Elemente zu unserer FIM Sync-Infrastruktur hinzufügen:
- Zwei neue Tabellen zur Aufnahme der proxyAddresses-Werte (wenn es sich um ein einwertiges Attribut handeln würde, bräuchten wir nur eine Tabelle, aber da es sich um ein mehrwertiges Attribut handelt, benötigen wir zwei - eine für den Datensatz und eine für die mehrwertigen Werte des Datensatzes).
- Ein neues Attribut im FIM-Metaverse, das die einmalige Historie der ProxyAddresses-Werte aus DomA enthält (wir nennen es proxyAddressHistory).
- Eine neue SQL MA als Schnittstelle zu der/den neuen Tabelle(n).
- Ein neuer Teil der Bereitstellungslogik, um die neuen Einträge in der SQL-Tabelle zu erstellen.
- Neue Exportlogik in der DomB MA für das Attribut proxyAddresses
Für unsere Einrichtung haben wir dieselbe SQL-Instanz verwendet, die auch für den FIM-Synchronisierungsdienst vorhanden war. Wir hatten zuvor eine weitere Datenbank (mit der Bezeichnung FIMExtension) erstellt und fügten dort die neuen Tabellen für die proxyAddresses-Historie hinzu.
Für die Haupttabelle (nennen wir sie ProxyTracking) brauchen Sie wirklich nur eine Spalte für den Primärschlüssel. Ich hätte aber gerne etwas mehr Informationen, damit ich eine Vorstellung davon habe, was ich in der Datenbank sehe, wenn ich die Daten von dort abrufe. Sie können dies mehr (oder weniger) komplex gestalten, aber für die Zwecke dieses Blogeintrags werden wir nur die Tabelle erstellen, die einen Primärschlüssel (P_ID) und eine Mitarbeiter-ID enthält.
(
P_ID int PRIMARY KEY IDENTITY,
employeeID (15) NOT NULL,
);Nun benötigen wir eine weitere Tabelle, um die im mehrwertigen Attribut proxyAddresses gespeicherten Werte zu erfassen. Nennen wir sie ProxyTrackingRef. Für diese Tabelle benötigen wir eine Spalte, die auf den Primärschlüssel der Tabelle ProxyTracking (P_ID) verweist, eine Spalte, die den Namen des Attributs enthält, das wir verfolgen (in unserem Fall wird es immer proxyAddresses sein), und eine Spalte, die die Werte der proxyAddresses enthält.
(
P_ID int NOT NULL,
attributeName varchar(20) NOT NULL,
attributeValue varchar(100) NOT NULL
);
Nun müssen wir das neue Attribut im FIM-Metaverse erstellen, um den Verlauf der einen Revision zu speichern. Fügen Sie im FIM Sync Metaverse Designer ein neues Attribut zur Person mit dem Namen "proxyAddressHistory" hinzu. Legen Sie es als mehrwertigen String an, der nicht indizierbar ist (siehe Abbildung 3).
Als Nächstes benötigen wir einen MA, der aus den soeben erstellten SQL-Tabellen liest und in diese schreibt. Erstellen Sie auf der Registerkarte FIM Sync Management Agents einen neuen SQL Server MA mit dem Namen "Proxy History MA". Geben Sie die SQL Server-Instanz an, die unsere Datenbank und die neuen Tabellen enthält. Geben Sie "ProxyTracking" für die Tabelle/Ansicht und "ProxyTrackingRef" für die Option Multivalue Table ein (siehe Abbildung 4 unten).
Abbildung 4 - Erstellen der SQL MA
Vergewissern Sie sich im Abschnitt "Spalten konfigurieren", dass die Spalte P_ID als Anker eingestellt ist. Klicken Sie auf die Schaltfläche "Mehrwertig" und wählen Sie "attributeName" aus der Dropdown-Liste für den "Attributspaltennamen", klicken Sie auf "String-Attributspalte" und wählen Sie "attributeValue" aus der Dropdown-Liste, klicken Sie auf die Schaltfläche "Neu" und fügen Sie "ProxyAdressen" als neues mehrwertiges Attribut mit dem Typ "String" hinzu (siehe Abbildung 5 unten).
Sie müssen sich keine Gedanken über Verbindungsfilter oder Join- und Projektionsregeln machen.
Im Abschnitt "Configure Attribute Flow" richten Sie einen direkten Exportfluss vom Metaverse-Attribut proxyAddressCollection (hier werden Werte aus DomA gespeichert) zum SQL MA-Attribut ProxyAddresses und einen direkten Importfluss vom SQL MA-Attribut ProxyAddresses zum Metaverse-Attribut proxyAddressHistory (das wir zuvor erstellt haben) ein (siehe Abbildung 6 unten).
Führen Sie im Abschnitt "Configure Deprovisioning" eine Löschung des Objekts für den nächsten Exportlauf durch und stellen Sie sicher, dass der Name einer Regelerweiterung im Abschnitt "Configure Extensions" aufgeführt ist (Proxy History MAExtension.dll).
Bereitstellungslogik für den Proxy History MA erstellen
Nun müssen wir die Bereitstellungslogik in der MVExtension.dll erstellen (wenn Sie die Erweiterung für Bereitstellungsregeln noch nicht aktiviert haben, müssen Sie dies über das Menü Extras, Optionen tun). Erstellen Sie zunächst eine Unterroutine mit dem Namen "ProvisionToProxyHist" (siehe unten).
Sub ProvisionToProxyHist(ByVal mventry As MVEntry)
'---------------
Unterprogramm zur Bereitstellung der SQL-Tabelle, die die Proxy-Historie enthält
'---------------
Versuchen Sie
Dim PHistMA As ConnectedMA = mventry.ConnectedMAs("Proxy History MA")
If PHistMA.Connectors.Count <> 0 Then Exit Sub
Dim obCS As CSEntry
obCS = PHistMA.Connectors.StartNewConnector("Person")
Dim DN As ReferenceValue
DN = PHistMA.EscapeDNComponent(System.Guid.NewGuid().ToString)
obCS.DN = DN
obCS.CommitNewConnector()
Catch ex As Exception
Wurf ex
Versuch beenden
End Sub
Dann müssen wir diese Subroutine nur noch innerhalb der Provision()-Subroutine der MVExtension.dll aufrufen (siehe unten).
An ProxyHistory MA
ProvisionToProxyHist(mventry)
Damit und mit den Attributflüssen, die wir oben in der MA angegeben haben, werden die Proxy-History-Informationen an die SQL-Tabellen gesendet.
Exportlogik für DomB einrichten
Um den neuen Verlauf beim Export in die DomB-Domäne zu verwenden, müssen wir zwei Dinge tun. Erstens müssen wir den Exportfluss vom Metaverse zu DomB ändern und ihn von einem direkten Fluss zu einem erweiterten Fluss (Regelerweiterung) mit den beiden Variablen proxyAddressCollection und proxyAddressHistory als Metaverse-Attribute für DomB ausgewählt werden proxyAddresses Attribut (ich habe den Namen der Flussregel "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses" angegeben).
Als Nächstes müssen wir den Namen der Flussregel zu unserer Case-Anweisung in der Unterroutine MapAttributesForExport() der DomB MAExtension.dll wie folgt hinzufügen.
Fall "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses"
Fügen Sie alle smtp-Einträge aus dem
MV proxyAddressCollection ohne Überschreiben der Zieleinträge
Wenn es keine proxyAddressCollection in der MV gibt, ist es nicht nötig, fortzufahren.
If Not mventry("proxyAddressCollection").IsPresent Then Exit Sub
Dim aOrigCSProxyAddresses() As String = {}
Dim sp1(), sp2() As String
Dim bExists As Boolean
Die Werte des DomB-Verbindungsstücks werden übernommen, damit wir eindeutige Werte wieder hinzufügen können.
If csentry("proxyAddresses").IsPresent Then
aOrigCSProxyAddresses = csentry("proxyAddresses").Values.ToStringArray
csentry("proxyAddresses").Values.Clear()
Ende wenn
'... Die Logik zum Hinzufügen der primären (SMTP-)Adresse muss hier eingefügt werden
'... - ...
'... - ...
Als nächstes fügen Sie smtp-Adressen aus dem Metaverse zum Attribut "ausgehend" hinzu.
For Each pAddr As String In mventry("proxyAddressCollection").Values.ToStringArray
If pAddr.StartsWith("smtp:") Then
smtp(s) hinzufügen, die noch nicht in der Liste vorhanden sind
bExists = False
'Schleife durch jeden Eintrag in der ProxyAddresses
For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray
Die beiden zu vergleichenden Werte werden durch den Doppelpunkt (:) getrennt.
sp1 = Split(csPAddr, ":")
sp2 = Split(pAddr, ":")
If sp1(1).ToLower = sp2(1).ToLower Then
'die Adresswerte stimmen überein
'das Flag auf true setzen
bExists = Wahr
'keine Notwendigkeit, die Liste fortzusetzen, Beenden der Schleife
Ausfahrt für
Ende wenn
Weiter
'Wenn keine Übereinstimmung gefunden wurde, fügen Sie den Wert zur Liste hinzu.
If Not bExists Then csentry("proxyAddresses").Values.Add(pAddr)
Ende wenn
Weiter
Ersetzen Sie nun alle Einträge aus dem CS, die nicht in der MV von DomA enthalten sind.
If aOrigCSProxyAddresses.Length > 0 Then
For l As Integer = 0 To aOrigCSProxyAddresses.Length - 1
Überprüfen Sie zunächst, ob es sich nicht um eine primäre Adresse handelt (SMTP).
If Not aOrigCSProxyAddresses(l).StartsWith("SMTP:") Then
Als Nächstes prüfen wir, ob sie in der Verlaufsliste enthalten ist - falls ja, können wir
Sie brauchen es nicht neu hinzuzufügen, da es von DomA stammt.
If Not mventry("proxyAddressHistory").Values.Contains(aOrigCSProxyAddresses(l)) Then
Prüfen Sie als Nächstes, ob sie bereits in der Liste der ausgehenden Nachrichten enthalten ist.
If Not csentry("proxyAddresses").Values.Contains(aOrigCSProxyAddresses(l)) Then
das Flag auf false setzen
bExists = False
Schleife durch jeden Eintrag in den ausgehenden proxyAddresses unter Berücksichtigung der Groß- und Kleinschreibung
For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray
Die beiden zu vergleichenden Werte werden durch den Doppelpunkt getrennt.
sp1 = Split(csPAddr, ":")
sp2 = Split(aOrigCSProxyAddresses(l), ":")
If sp1(1).ToLower = sp2(1).ToLower Then
Die Adresswerte stimmen überein - Setzen Sie das Flag auf true
bExists = Wahr
'kein Grund zum Weitermachen. Beenden Sie die Schleife
Ausfahrt für
Ende wenn
Weiter
'wenn keine Übereinstimmung gefunden wurde, fügen Sie den Wert wieder hinzu
zur Liste
If Not bExists Then csentry("proxyAddresses").Values.Add(aOrigCSProxyAddresses(l))
Ende wenn
Ende wenn
Ende wenn
Weiter
Ende wenn
MA-Lauf-Reihenfolge
Der letzte Punkt, den wir beachten müssen, ist die Reihenfolge der MA-Läufe. Natürlich wollen wir die SQL-Tabellen nicht aktualisieren, bevor wir nach DomB exportieren, denn sonst würden wir dieproxyAddresses -Historie mit neuen DomA-Werten überschreiben - und somit die Historie verlieren. Stellen Sie also sicher, dass Sie von DomA importieren und synchronisieren, nach DomB exportieren (gefolgt von einem Delta-Import), dann in die Proxy History MA exportieren und schließlich die Proxy History MA importieren und synchronisieren, um die History-Werte wieder in das Metaverse zu bekommen. Dabei ist anzumerken, dass ich nur dann zuverlässige Ergebnisse vom Proxy History MA erhielt, wenn ich nach dem Import einen FULL-Sync durchführte.
(ignorieren)
Die Notwendigkeit, den Verlauf von Attributen zu verfolgen, sollte nicht sehr häufig vorkommen, und in diesem Fall wurde es durch die Tatsache erschwert, dass das Attribut mehrwertig ist.
