Récemment, l'un de nos clients a été confronté à un scénario qui l'obligeait à conserver l'historique de l'attribut proxyAddresses entre deux domaines Microsoft Active Directory (AD). Étant donné que FIM Sync Service ne conserve aucun historique des valeurs d'attributs (il s'agit simplement d'un moteur de synchronisation basé sur l'état), cela a nécessité un peu de réflexion et de planification.
Après avoir examiné la nécessité de conserver l'historique et exploré les différentes options, nous avons trouvé la solution en mettant en place un mécanisme simple d'historique à une seule révision avec FIM Sync.
Sans entrer dans l'histoire, commençons par un bref aperçu du scénario. Il y a deux domaines Active Directory (AD) (appelons-les DomA et DomB) et les utilisateurs sont synchronisés de DomA à DomB. Là où les choses se compliquent un peu, c'est que chaque domaine possède son propre environnement Exchange et ajoute des valeurs uniques à l'attribut proxyAddresses des objets utilisateurs compatibles avec la messagerie. Dans cette configuration, le moteur de synchronisation devrait normalement écraser les valeurs de l'attribut proxyAddresses dans le DomB, supprimant ainsi toutes les valeurs ajoutées par l'environnement Exchange du DomB (voir Figure 1).
Ainsi, dans ce cas, nous avions besoin d'un moyen d'ajouter des valeurs provenant de DomA sans écraser les valeurs ajoutées par DomB. Pour ce faire, nous devions stocker les dernières valeurs de DomA quelque part. En les plaçant dans une base de données SQL, nous avons pu les ramener dans le Metaverse sous la forme d'un attribut différent. C'était une bonne solution car nous aurions besoin de les référencer pendant le processus de synchronisation, et l'agent de gestion SQL intégré (MA) de FIM nous permettrait d'écrire et de récupérer facilement les valeurs dans la base de données SQL (voir Figure 2).
Avec les valeurs de DomA dans la base de données, nous pourrions nous y référer si les valeurs de DomA changeaient. Les changements viendraient de DomA, nous appliquerions la logique dont nous avons besoin dans la synchronisation sortante vers DomB en nous référant aux nouvelles valeurs de DomA et aux valeurs précédentes de DomA (maintenant stockées à la fois dans la base de données SQL et dans un nouvel attribut dans le Metaverse). Cela nous donnerait un historique d'une seule révision, ce qui est tout ce dont nous avons besoin.
Pour ce faire, nous avons dû ajouter les éléments suivants à notre infrastructure FIM Sync :
- Deux nouvelles tables pour contenir les valeurs de proxyAddresses (s'il s'agissait d'un attribut à valeur unique, nous n'aurions besoin que d'une seule table, mais comme il s'agit d'un attribut à valeurs multiples, nous en avons besoin de deux - une pour contenir l'enregistrement et une pour contenir les valeurs multiples de l'enregistrement).
- Un nouvel attribut dans le Metaverse FIM pour contenir l'historique d'une révision des valeurs proxyAddresses de DomA (que nous appellerons proxyAddressHistory).
- Un nouveau SQL MA pour interfacer avec la (les) nouvelle(s) table(s).
- Un nouvel élément de logique de provisionnement pour créer les nouvelles entrées dans la table SQL.
- Nouvelle logique d'exportation dans le DomB MA pour l'attribut proxyAddresses
Pour notre installation, nous avons utilisé la même instance SQL que celle qui était en place pour le service de synchronisation FIM. Nous avions précédemment créé une autre base de données (appelée FIMExtension), et nous y avons donc ajouté les nouvelles tables pour l'historique proxyAddresses.
Pour la table principale (appelons-la ProxyTracking), vous n'avez vraiment besoin que d'une seule colonne pour contenir la clé primaire. J'aime bien avoir un peu plus d'informations, afin d'avoir une idée de ce que je regarde dans la base de données si jamais je consulte les données à partir de là. Vous pouvez rendre cela plus (ou moins) complexe, mais pour les besoins de cet article de blog, nous créerons simplement la table pour contenir une clé primaire (P_ID) et un numéro d'identification de l'employé.
(
P_ID int PRIMARY KEY IDENTITY,
employeeID (15) NOT NULL,
);Nous allons maintenant avoir besoin d'une autre table pour garder une trace des valeurs stockées dans l'attribut multi-évalué proxyAddresses. Appelons-la ProxyTrackingRef. Pour cette table, nous avons besoin d'une colonne qui renvoie à la clé primaire (P_ID) de la table ProxyTracking, d'une colonne qui contienne le nom de l'attribut que nous suivons (dans notre cas, il s'agira toujours de proxyAddresses) et d'une colonne qui contienne les valeurs de proxyAddresses.
(
P_ID int NOT NULL,
attributeName varchar(20) NOT NULL,
attributeValue varchar(100) NOT NULL
) ;
Nous devons maintenant créer le nouvel attribut dans le Metaverse FIM pour contenir l'historique d'une révision. Dans le FIM Sync Metaverse Designer, ajoutez un nouvel attribut à la personne appelé "proxyAddressHistory". Faites-en une chaîne à valeurs multiples, non indexable (voir Figure 3).
Ensuite, nous avons besoin d'un agent de gestion pour lire et écrire dans les tables SQL que nous venons de créer. Dans l'onglet Agents de gestion FIM Sync, créez un nouvel agent de gestion SQL Server appelé "Proxy History MA". Spécifiez l'instance du serveur SQL qui contient notre base de données et les nouvelles tables. Saisissez "ProxyTracking" pour la Table/Vue et "ProxyTrackingRef" pour l'option Multivalue Table (voir la figure 4 ci-dessous).
Figure 4 - Création de la base de données SQL MA
Dans la section "Configuration des colonnes", assurez-vous que la colonne P_ID est définie comme ancrage. Cliquez sur le bouton Multi-valeurs et sélectionnez "attributeName" dans la liste déroulante pour le "nom de la colonne d'attributs", cliquez sur "colonne d'attributs de type chaîne" et choisissez "attributeValue" dans la liste déroulante, puis cliquez sur le bouton Nouveau et ajoutez "ProxyAddresses" en tant que nouvel attribut multi-valeurs de type "chaîne" (voir la figure 5 ci-dessous).
Il n'est pas nécessaire de se préoccuper des filtres de connexion ou des règles de jointure et de projection.
Dans la section "Configure Attribute Flow", configurez un flux d'exportation direct depuis l'attribut Metaverse proxyAddressCollection (c'est là que nous stockons les valeurs de DomA) vers l'attribut SQL MA ProxyAddresses, et un flux d'importation direct depuis l'attribut SQL MA ProxyAddresses vers l'attribut Metaverse proxyAddressHistory (que nous avons précédemment créé) (voir la Figure 6 ci-dessous).
Dans la section "Configurer le déprovisionnement", supprimez l'objet pour la prochaine exportation et assurez-vous qu'un nom d'extension de règles figure dans les sections "Configurer les extensions" (Proxy History MAExtension.dll).
Créer une logique de provisionnement pour l'historique Proxy MA
Nous devons maintenant créer la logique de provisionnement dans MVExtension.dll (si vous n'avez pas encore activé l'extension des règles de provisionnement, vous devez le faire à partir du menu Outils, Options). Tout d'abord, créez une sous-routine appelée "ProvisionToProxyHist" (comme ci-dessous).
Sub ProvisionToProxyHist(ByVal mventry As MVEntry)
'---------------
'- Sous-programme de provisionnement de la table SQL contenant l'historique du proxy
'---------------
Essayer
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
Lancer l'ex
Fin de l'essai
End Sub
Il suffit ensuite d'appeler cette sous-routine à partir de la sous-routine Provision() de MVExtension.dll (voir ci-dessous).
To ProxyHistory MA
ProvisionToProxyHist(mventry)
Avec cela en place, et les flux d'attributs que nous avons spécifiés dans le MA ci-dessus, les informations sur l'historique du proxy seront envoyées aux tables SQL.
Mise en place d'une logique d'exportation pour DomB
Pour utiliser le nouvel historique lors de l'exportation vers le domaine DomB, nous devons faire deux choses. Premièrement, nous devons modifier le flux d'exportation du Metaverse vers le DomB et le faire passer d'un flux direct à un flux avancé (extension de règles) avec les deux éléments suivants proxyAddressCollection et proxyAddressHistory sélectionnés comme attributs du Metaverse dans le flux DomB proxyAddresses (j'ai spécifié le nom de la règle de flux "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses").
Ensuite, nous devons ajouter le nom de la règle de flux à notre instruction Case dans la sous-routine MapAttributesForExport() de DomB MAExtension.dll, comme indiqué ci-dessous.
Cas "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses"
'Ajouter toutes les entrées smtp de la base de données
MV proxyAddressCollection sans écraser les entrées cibles
S'il n'y a pas de proxyAddressCollection dans le MV, il n'est pas nécessaire de continuer.
If Not mventry("proxyAddressCollection").IsPresent Then Exit Sub
Dim aOrigCSProxyAddresses() As String = {}
Dim sp1(), sp2() As String
Dim bExists As Boolean
'Saisir les valeurs de l'espace du connecteur DomB afin de pouvoir ajouter des valeurs uniques.
Si csentry("proxyAddresses").IsPresent Alors
aOrigCSProxyAddresses = csentry("proxyAddresses").Values.ToStringArray
csentry("proxyAddresses").Values.Clear()
Fin Si
La logique permettant d'ajouter une adresse primaire (SMTP) doit être placée ici.
'... - ...
'... - ...
Ensuite, ajoutez les adresses smtp du métavers à l'attribut de sortie.
Pour chaque pAddr en tant que chaîne de caractères dans mventry("proxyAddressCollection").Values.ToStringArray
If pAddr.StartsWith("smtp :") Then
'Ajouter les smtp(s) qui n'existent pas encore dans la liste
bExists = False
Boucle sur chaque entrée du fichier proxyAddresses
For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray
'sépare les deux valeurs que nous comparons sur les deux points ( :)
sp1 = Split(csPAddr, " :")
sp2 = Split(pAddr, " :")
Si sp1(1).ToLower = sp2(1).ToLower Alors
les valeurs des adresses correspondent
'Mettre le drapeau à true (vrai)
bExists = True
Il n'est pas nécessaire de continuer à parcourir la liste, quittez la boucle.
Sortie pour
Fin Si
Suivant
'si aucune correspondance n'a été trouvée, continuer et ajouter la valeur à la liste
If Not bExists Then csentry("proxyAddresses").Values.Add(pAddr)
Fin Si
Suivant
Remplacez maintenant toutes les entrées du CS qui ne figurent pas dans le MV de DomA.
Si aOrigCSProxyAddresses.Length > 0 Alors
For l As Integer = 0 To aOrigCSProxyAddresses.Length - 1
Tout d'abord, vérifiez qu'il ne s'agit pas d'une adresse primaire (SMTP).
If Not aOrigCSProxyAddresses(l).StartsWith("SMTP :") Then
Ensuite, vérifiez s'il figure dans la liste de l'historique.
Il n'est pas nécessaire de le réajuster car il provient de DomA.
If Not mventry("proxyAddressHistory").Values.Contains(aOrigCSProxyAddresses(l)) Then
Ensuite, vérifiez s'il figure déjà dans la liste des sorties.
If Not csentry("proxyAddresses").Values.Contains(aOrigCSProxyAddresses(l)) Then
'Mettre le drapeau à faux
bExists = False
boucle sur chaque entrée des proxyAddresses sortantes en respectant la distinction entre les majuscules et les minuscules
For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray
'divise les deux valeurs que nous comparons sur les deux points
sp1 = Split(csPAddr, " :")
sp2 = Split(aOrigCSProxyAddresses(l), " :")
Si sp1(1).ToLower = sp2(1).ToLower Alors
'les valeurs d'adresse correspondent - mettre l'indicateur à true
bExists = True
Il n'est pas nécessaire de continuer. Quitter la boucle
Sortie pour
Fin Si
Suivant
Si aucune correspondance n'a été trouvée, continuer et ajouter la valeur.
à la liste
If Not bExists Then csentry("proxyAddresses").Values.Add(aOrigCSProxyAddresses(l))
Fin Si
Fin Si
Fin Si
Suivant
Fin Si
Séquence d'exécution du MA
La dernière chose que nous devons aborder est la séquence d'exécution de MA. Il est évident que nous ne voulons pas mettre à jour les tables SQL avant d'exporter vers DomB, sinon nous écraserions l'historique de ProxyAddresses avec de nouvelles valeurs de DomA, ce qui entraînerait la perte de l'historique. Assurez-vous donc d'importer et de synchroniser à partir de DomA, d'exporter vers DomB (suivi d'une importation Delta), puis d'exporter vers le Proxy History MA, et enfin d'importer et de synchroniser le Proxy History MA pour récupérer les valeurs de l'historique dans le Metaverse. Une chose à noter ici est que je n'ai obtenu des résultats fiables du Proxy History MA que lorsque j'ai effectué une synchronisation complète après l'importation.
(ignorer)
La nécessité de suivre l'historique d'un attribut ne devrait pas être très fréquente, et nous avons compliqué ce cas avec le fait que l'attribut était multivalué, mais nous espérons que l'exemple aidera tous ceux qui se trouvent dans une situation similaire.
