Recently, one of our clients had a scenario that required them to keep track of the proxyAddresses attribute history between two Microsoft Active Directory (AD) domains. Since FIM Sync Service doesn’t retain any history of attribute values (as simply a state-based synchronization engine), this required a bit of thought and planning.
Examining the need to keep track of the history and exploring options, we came down to the solution through a simple one-revision history mechanism with FIM Sync.
Without getting into too much history, let’s start with a brief overview of the scenario. There are two Active Directory (AD) domains (let’s refer to them as DomA and DomB) and users are being synchronized from DomA to DomB. Where it gets a little complicated is that each domain has its own Exchange environment, and each adds unique values to the proxyAddresses attribute of mail-enabled user objects. With this setup – the Sync engine would normally overwrite the values in the proxyAddresses attribute in DomB, in essence deleting any values added by the DomB Exchange environment (see Figure 1).
So, in this instance, we needed a way of adding values from DomA without overwriting any values added by DomB. To accomplish this, we would need to store the latest values from DomA somewhere. Putting them into a SQL database, we were able to bring them back into the Metaverse as a different attribute. This was a good solution because we would need to reference them during the synchronization process, and the built-in SQL Management Agent (MA) from FIM would allow us to easily write and retrieve the values to and from the SQL database (see Figure 2).
With the DomA values in the database, we could refer to them if the values in DomA changed. The changes would flow in from DomA, we would apply the logic we needed in the out-bound sync to DomB by referring to the new values from DomA and the previous DomA values (now stored in both the SQL database and a new attribute in the Metaverse). This would give us a one-revision history, which is all we needed.
To set this up; we needed to add the following items to our FIM Sync infrastructure:
- Two new tables to hold the proxyAddresses values (if this were a single-value attribute, we would only need one table, but because it is multi-valued we need two – one to hold the record, and one to hold the record’s multi-values).
- A new attribute in the FIM Metaverse to hold the one-revision history of the proxyAddresses values from DomA (we will call proxyAddressHistory) .
- A new SQL MA to interface with the new table(s).
- A new bit of provisioning logic to create the new entries in the SQL table.
- New export logic in the DomB MA for the proxyAddresses attribute
For our setup, we used the same SQL instance that was in place for the FIM Synchronization Service. We had previously created another database (called FIMExtension), so we added the new tables for the proxyAddresses history there.
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
Now we need to create the new attribute in the FIM Metaverse to hold the one-revision history. From the FIM Sync Metaverse Designer, add a new attribute to person called “proxyAddressHistory.” Make it multi-valued string, non-indexable (see Figure 3).
Next, we need an MA to read from and write to the SQL tables we just created. From the FIM Sync Management Agents tab, create a new SQL Server MA called “Proxy History MA.” Specify the SQL server instance that holds our database and new tables. Type in “ProxyTracking” for the Table/View, and “ProxyTrackingRef” for the Multivalue Table option (see Figure 4 below).
Figure 4 - Create the SQL MA
On the “Configure Columns” section, make sure that the P_ID column is set as the Anchor. Click the Multi-value button and select “attributeName” from the drop-down for the “attribute column name”, click “String attribute column” and choose “attributeValue” from the drop-down, and click the New button and add “ProxyAddresses” as a new multi-value attribute as Type “String” (see Figure 5 below).
There is no need to worry about Connector Filters or Join and Projection Rules.
In the “Configure Attribute Flow” section, setup a direct export flow from the Metaverse attribute proxyAddressCollection (this is where we are storing values from DomA) to the SQL MA attribute ProxyAddresses, and a direct import flow from the SQL MA attribute ProxyAddresses to the Metaverse proxyAddressHistory attribute (that we previously created) (see Figure 6 below).
Now we need to create the provisioning logic in the MVExtension.dll (if you have not already enabled the Provisioning Rules Extension, you will need to do so from the Tools, Options menu). First, create a subroutine called "ProvisionToProxyHist” (as below).
'To ProxyHistory MA
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.
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”).
Next, we need to add that flow rule name to our Case statement in the DomB MAExtension.dll’s MapAttributesForExport() subroutine as below.
The last thing we need to address is the MA run sequence. Obviously, we don’t want to update the SQL tables before we export to DomB or we would be overwriting theproxyAddresses history with new DomA values – therefore losing the history. So make sure that you Import and Sync from DomA, Export to DomB (followed by a Delta Import), then Export to the Proxy History MA, and then finally Import and Sync the Proxy History MA to get the history values back into the Metaverse. One thing to note here is that I only got reliable results from the Proxy History MA when I ran a FULL sync after importing.
The need to keep track of attribute history shouldn’t be very common, and we complicated this one with the fact that the attribute was multi-valued, but hopefully the example will help anyone that finds themself in a similar situation.