Declarative Provisioning in FIM and DN Values
Now that my customers are beginning to move forward with FIM 2010 implementations away from ILM 2007, I’ve begun to dig more deeply into configurations for “real life” scenarios and attempt to apply some of the lessons I’ve learned from my training in “ILM v2” (yes, it was that long ago when I took the course).
In once scenario, I’m deploying AD LDS as a kind of staging area for our administrators to test scripts and such. In theory, it’s rather easy. I read in objects from AD and provision them with a good number of attributes into the metaverse – including the Distinguished Name (DN) value into a string. I then use this string to push a mirror of the object with relevant values to the AD LDS instance. Easy, right?
Imagine my surprise when, as I’d been instructed and as all of the articles online say, I flowed my DN value to DN twice: once as “initial flow only” (which is absolutely necessary for object creation in the connected system) and once as persistent so that object renames (or moves) will be possible – and it didn’t work. Now, by “didn’t work” I mean that the objects appeared as advertised in AD LDS, but with some “exported-change-not-reimported” errors… on EVERY object. Not good.
What was going on here?
For reference, here was my relevant attribute flow:
Source (AD) |
Metaverse | Target (AD LDS) | ||
<dn> |
--> |
DNString |
--> |
dn (initial) |
<dn> |
--> |
DNString |
—> |
dn |
What was happening is that the object would be created correctly, but there was always an attempt to write to the DN the string value I had stored in the metaverse and then a corresponding “exported-change-not-reimported” every time. Every time. Because of this issue, moves also didn’t work. A user provisioned in one OU would simply stay there causing error after error – not unlike all the other user objects around.
Digging deeper, I finally found a reference on the internet to some strange “feature” of declarative provisioning. It seems that it works perfectly well if you create or evaluate the DN value before flowing it to the attribute – just not as a pre-built string stored directly in the metaverse. Like this:
Metaverse |
Function |
Target (AD LDS) | ||
DNString |
--> |
“CN=” + cn + newRDNvalue |
--> |
dn (initial) |
DNString |
--> |
“CN=” + cn + newRDNvalue |
—> |
dn |
This function (well, something more specific in actual implementation) always seems to work but the direct string flow doesn’t. Very odd. So, when this article (https://social.technet.microsoft.com/Forums/en-US/ilm2/thread/6095c934-33e8-4ee2-8333-b5e6ac9c701e) suggested I put a function in there (like Trim()) I tried it. Now, the flow looks like this:
Source (AD) |
Metaverse | Target (AD LDS) | ||
<dn> |
--> |
Trim(DNString) |
--> |
dn (initial) |
<dn> |
--> |
Trim(DNString) |
—> |
dn |
And what do you know? It works – and am I glad: 20,000 user objects bouncing back and forth with EREs coming and going every sync cycle takes up way too much time and computing resources. I just find it somewhat odd that this behavior exhibits itself. One hopes it is addressed in a future hotfix or release.
Sync time (with exports, syncs, and imports) went from about 5 or 6 hours round trip to about half an hour now.
Much better.