Hi

I'm looking for some guidance and examples please.

I have a classic FIM 2010 R2 installation with an SQL MA acting as the primary source for my users.  This works fine and users are provisioned to AD without issue. The problem started when I was informed we needed to also provision some users via the FIM Portal (those that come into the business as consultants or contractors and bypass HR). 

I've tried various methods to get this to work but I simply don't know how to get the DN constructed for AD for a user that has been created via the portal. 

When a user is created in the portal and imported into the Metaverse, the object never arrives.  The object appears to  get as far as the connector space for the FIM MA (I can find it if I search the connector space), but when I do a sync, I get the following error:

"Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: The DN must be set before calling CSEntry.CommitNewConnector."

My outbound sync rule to AD generates the DN in the classic way by contactenating various values but, I guess when you add a user via the FIM Portal, these values aren't in the Metaverse yet which is why the sync fails.

I thought I might be able to work around this and I guess I've followed the trail of many who have gone before me learning that you can't do certain things with the FIM MA.

Currently I'm thinking that I should create a rule extension for the Metaverse - I'm very experienced with VB.NET but I've not worked with rules extensions before and I'm finding it difficult to get up and running quickly. Pehaps I'm running down the wrong alley but my current thinking is that I should write an extension that queries the FIM MA connector space, checks thet Metaverse and creates a unique DN from the values in the connector space as the object passes through to the MV.

So I guess my question is:

How would I construct a unique DN for each user object that is added via the FIM Portal so that they can be provisioned to AD?

In addition, may you please point me at some real primers that get you started on coding rules extensions using VB.NET  (or some examples of what I actually want to do.

Thank you for any help you can provide.

• Changed type Markus VilcinskasMicrosoft employee, Owner Wednesday, February 13, 2013 8:38 PM

Hello,

Based on what you described it shouldn't be difficult to fix, bottom line is that you either need to somehow provide all the attributes that are required by your provisioning code (this is where you're generating the DN) - those attributes would need to get populated in the portal and you just set up flows from the portal to MV (when viewing the Portal CS object you see which attributes are available) ... or in your provisioning code you need to determine where is the object coming from (by looking at some attributes for example) and then have different provisioning logic and generate the DN in a different way.

Either way, you will probably need to modify your provisioning code to take under consideration this new scenario.

Hope this helps a bit.

Piotr

Hi

Thank you for your reply.  I read your comments, particularly "those attributes would need to get populated in the portal and you just set up flows from the portal to MV "

This perhaps is where my knowledge runs thin.  You suggested attribute flows from the FIM MA to the MV.  To the best of my knowledge, the FIM MA is limited in terms of codeless configuration and the only place you can configure flows is in the actual MA itself.  So I'm looking and wondering "how to do this"?  Below are my currentl flows:

As you can see, all the attributes flow into the CS (except for the <dn> and Expected Rules List).  How do I configure attribute flow to the MV for this MA please as you can't add the same attribute a second time to the above list and set it to "import" (I've tried).  Because of my limited experience I don't know where to configure the attribute flow from the portal to the MV - are you able to give me some pointers please. 

Is it because the attribute flow is only set to inbound that they're not making into the MV from the Portal please?

Thank you for your help again.

• Edited by pm620wh Monday, February 04, 2013 12:12 PM

Just a quick add-on; if you want to do "codeless" provisioning without Sync Rules, you could have a look at my old framework for provisioning - http://blog.goverco.com/2012/12/fim-mre-is-now-on-codeplex.html

It should definitely be possible to add import flows for attributes that already have an export flow set up - the above screen is exactly where you'd need to configure those. Try with one, and then please make sure you go to the MV schema, find the attribute you just added an import for and check the precedence rules (on the right hand side) .... the FIM Service MA should probably have the lowest priority not to overwrite values for users coming in from HR.

Anyway, if you stick to legacy provisioning code, like I wrote above, you will probably have to edit the provisioning code anyway to handle this new scenario.

Piotr

You know - I swear I tried adding attributes to flow to the MV via the Management Interface and it told me the "attrbitue was already configured" but, I've just tried again and it works!!  My apologies for having trouble you on this.

In the meantime, I really woudl love to get up and running on writing extension rules.  May you guide me towards some real primers and introductions that don't jump in at the middle please?

Many thanks and kind regards

Not trying to revive an old thread, but just leaving a breadcrumb here as a fix for the same error message I encountered today.  Couldn't find anyone suggesting it's an issue with a different MA if you have multiple MA's involved for provisioning users.

My FIM 2010 R2 Portal has been creating and provisioning users into AD without issue for a few years now.

Yesterday - we added Office 365 (Azure AD) provisioning.  Azure AD users' DN is being built based on their b64'd objectGUID, which we stored in the MV.  Opened the floodgates yesterday and provisioned 5000 users no problem.  Job done - or so I thought.

Then today ran into 3 users with the same  "DN must be set" issue as above. 

Issue turned out to be when a new hire came into FIM, FIM was making ERE's to provision those users into AD and Azure.  The Azure's DN is built on a objectGUID, that hadn't been created by AD yet, because the user wasn't in AD.  :)

Quick solution was to have AD flow in a constant "1" as AzureADEnabled into the MV.  FIM has a set of "Azure Enabled" users with the usual MPR/Sync/Set triple.  I have my HR system flowing in the same value of "0" with a lower precedence.

Now a new hire comes in from HR, has 0 for Azure AD.  FIM will provision the user to AD.  Then the "1" comes back eventually and FIM will now provision the user into Azure without issue because they've transitioned into the Azure Enabled set.

I poked around at using dependent sync rules but seems these can't do an "initial flow" which you would need for a DN, so I couldn't make it depend on the AD Outbound Sync Rule.

Bottom line: Check any and all Sync Rules that have a DN outbound to make sure they actually have the information they need to construct their DN.