Regenerating Expected Rule Entry (ERE) resources

So you’re setting up a FIM lab and you’re shooting from the hip because this is the envisioning phase of your project (i.e. you haven’t written your design yet).  You’ve setup an outbound synchronization rule (OSR), a workflow (WF) and a management policy rule (MPR) to run the WF.  The public documentation refers to this as a “synchronization triple”.  The MPR is a set transition MPR, ST-MPR, the target set is “All Active People”.  You already have a bunch of users in the FIM Service that are already members of the all active people set.  OK, you run a delta import on the FIM MA followed by a full synchronization (as your SRs have changed because you’ve just imported a new SR).  Declarative, a.k.a. codeless, provisioning doesn’t occur.  The metaverse (MV) objects are not provisioned into the connector space (CS) of your target system (connected data source, CDS or managed identity system).  Why not?  Well, two reasons immediately spring to mind:

  1. Declarative provisioning isn’t enabled.  You enable this via the FIM Synchronization Service Manager.  Click the management agent (MA) tab, click tools then options (Ctrl + Shift + O) and select “Enable Synchronization Rule Provisioning” (fig. 1, below).
  2. You don’t have an expected rule entry (ERE) resource.  This is the crux of this blog post.  Basically, your users are already members of the transition-in set in your ST-MPR definition therefore the WF to add the target users to the OSR didn’t fire.

Figure 1: Enable Synchronization Rule Provisioning

How to make this fire?  In the lab, go back to your WF definition and enable “Run on policy update”.  Now disable the ST-MPR and immediately enable it again.  Check the request log (All Requests, hit search).  You’ll see one “System Event Request” for each resource in the set.  In addition you’ll see a “Create ExpectedRuleEntry: ‘<SR name>’ Request” followed by the System Event Request’s child request: “Update to Person: ‘<Target>’ Request”.  The system creates an ERE and updates the target of the system event.  If you inspect the request you’ll see that the previously created ERE has been written to the Expected Rules List (ERL) attribute of the target user.

Now, when you import and synchronise the FIM MA again you’ll get a projection for each ERE followed by outbound provisioning and synchronisation into the CS of the MA in question.

So what’s the point of this blog post?  Well, it’s a reasonably common question on the FIM forum.  We’ve utilised retroactive policy application to reapply an Action WF and regenerate (or in the case of the above example, generate) EREs.  The same approach can be used to regenerate EREs if you’ve made changes to your OSR and you are making use of Synchronization Workflow Parameters (these values are actually embedded in the ERE itself and are not configured attribute flows that flow through the MV object).

So what happens if I’ve not used a set transition MPR?  That is, what if I’ve used a request MPR?

Well, this is easy.  You just need to fire the MPR.  To do that a valid requestor (a user in the defined set of requestors) must perform whatever action is defined by the MPR, e.g. create a user and ensure that the display name attribute is part of the create request.  For Synchronization Rule activity WF instances however, set transition MPRs are best.  As you have the ability to utilise retroactive policy application (run on policy update) to reapply the WF if you ever need to and you abstract yourself from the underlying request that causes the transition, e.g. you can fire on not just a create but also certain modification operations, without an all-encompassing request MPR that could misfire.

Wrap-up

I mentioned a bunch of FIM concepts in this post.  If you want to do some more reading on any of these things check out the following documentation:

Understanding Data Synchronization with External Systems (which provides links to the following too).

  1. Introduction to Inbound Synchronization
  2. Introduction to Outbound Synchronization

Introduction to User and Group Management

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM and tagged , , , , , , , , . Bookmark the permalink.

One Response to Regenerating Expected Rule Entry (ERE) resources

  1. Pingback: #FIM2010 R2 Scoped Sync Rules – Part 1 (The Vision) | IdM for Real

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s