Welcome to Part 2 of the “Sync Rule Walk Through” series. In
we talked about an inbound user synchronization rule from AD into MIM. Now that we have users in the portal, the next logical step is getting them
. As with the inbound sync rule example, this one will be connecting to AD and, please remember, there are subtle differences between connected data sources. Also worth noting is there are two types of outbound sync rules: traditional (based on a sync policy with a set, workflow and MPR) and system scoping filter based. In this scenario, we will be focusing on the latter.
As before, click on “Administration” in the bottom left-hand corner. This will open the “Administration” screen. Here, select “Synchronization Rules”. When the “Synchronization Rules” screen opens, at the top, select “New”:
As before, enter a
and, optionally, a
Data Flow Direction
, this time select “Outbound”. Now, we must choose how to apply; “to specific metaverse resources of this type based on Outbound Synchronization Policy” or “To all metaverse resources of this type according to Outbound System Scoping Filter”. For a discussion on the primary differences between these two, please
. Click “Next” to continue.
As with the ISR, we must defined the scope. In similar fashion, for
Metaverse Resource Type
, select “person”. For
select your AD, and for
External System Resource Type
select “user”. Now, however, we must define an
Outbound System Scoping Filter
. This scoping filter will determine to which user objects this rule applies and, as such, which will get synced out to AD.
Here, I am using the filter “email
@adatum.com”. The logic for this is such: during my new hire onboarding process, there are several stages where approval is required. A new employee may be hired, but prior to having their account created in AD or their mailbox created, they must complete new hire training for HR. Once that has been completed, the final box gets checked and an email adderss is created for them in the portal. Seeing as, in my environment, email address creating in MIM is the final step, I now know this user is ready to be created in AD (and anywhere else they may exist). Again, please note this will be specific to your environment. I don’t know your business or your data and can’t tell you what to use here.
As before, we must now define the
. Also as before, in this example I will be using the (custom) attribute “PoliticianID” in MIM mapped to “employeeID” in AD. Also, where we checked
Create resource in FIM
before, we must now check
Create resource in external system
. Failing to do so will result in a user not being provisioned to AD. Again, you didn’t tell it to create the object, so it didn’t (no error generated).
As with the ISR, attribute flows must be defined. Also, as with the ISR, please be aware of the differences in attributes between MIM and your connected data source (i.e., firstName –> givenName).
Here is a significant difference between
sync rules: initial flows. There are certain attributes that we should flow initially. For example, I like to flow an integer value of 0 to “pwdLastSet”. This will force my newly provisioned user to change their password the first time they login to AD. Likewise, I use a custom expression to set an initial value for “unicodePWD”. This is their default password the first time they log in to AD. The other significant point to note here is the necessity to build the
for a newly provisioned user. This can be either a static path or, as shown below, dynamically built by a series of attributes. While I may cover this more in-depth at a later date, for the time being I will not. Again, please remember these are just example flows from my environment and are not meant to be taken as the word of law.
Once you have reviewed everything on the “Summary” tab, click “Submit” to create your outbound system scoping filter based OSR.
Questions? Comments? Love FIM/MIM so much you can’t