FIM Sync: So verfolgen Sie den Verlauf der ProxyAdressen-Attribute

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

Erstellen der SQL-Tabellen

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.

For the main table (let’s call it ProxyTracking), you really only need one column to hold the primary key. I like a little more info, though, so that I have an idea of what I am looking at in the database if I ever view the data from there. You can make this more (or less) complex, but for the purposes of this blog entry we will just create the table to hold a primary key (P_ID) and an employeeID. Create Table ProxyTracking
(
P_ID int PRIMARY KEY IDENTITY,
employeeID (15) NOT NULL,
);Now, we will need another table to keep track of the values stored in the multi-valued attribute proxyAddresses. Let’s call it ProxyTrackingRef. For this table, we need a column that refers back to the ProxyTracking table’s primary key (P_ID), a column to hold the name of the attribute we are tracking (in our case it will always be proxyAddresses), and a column to hold the values of the proxyAddresses. Create Table ProxyTrackingRef
(
P_ID int NOT NULL,
attributeName varchar(20) NOT NULL,
attributeValue varchar(100) NOT NULL
); Creating the New Metaverse Attribute

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).

Erstellen der neuen SQL MA

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

Then, all we have to do is call that subroutine from within the Provision() subroutine of the MVExtension.dll (as below).

‘To ProxyHistory MA
ProvisionToProxyHist(mventry)

With this in place, and the attribute flows we specified in the MA above, the proxy history information will be sent to the SQL tables.

Exportlogik für DomB einrichten

To use the new history when exporting to the DomB domain, we need to do two things. First, we need to modify the Export flow from the Metaverse to DomB and change it from a direct flow to an advanced flow (rules extension) with both the proxyAddressCollection and proxyAddressHistory selected as Metaverse attributes to the DomB proxyAddresses attribute (I specified the flow rule name of “proxyAddressCollection_proxyAddressHistory_to_proxyAddresses”).

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.

Case “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.