More complex objects (Part 4) : Manual Sets, criteria based Sets and Sync rules

So now you are very familiar with scripting, and the logic is always the same no matter which object you want to create. 

I would like now to share with you some other samples.. especially when some objects are just a bit more “complex” to script in FIM.

This example authorize “administrators” to create new activities in the portal :

This one is a bit more interesting. The goal here is to have a “SET” that contains the list of Built-in Group of AD. If you do it manually, of course you need to create a set, and then add one by one each Built-in Group. The reason I created it is that for me FIM is of course good in IAM and Advanced IAM solution, but it can also provide very good services to the infrastructure. The ability to interact with AD built-in groups (for example add Aproval and notification workflows when people enter/leave such group) is great value. But this is AD, what about Exchange, Office365, CRM.. or any kind of other product ? Having one script per Microsoft Product is very interesting, since they can load this configuration in a few seconds.

In the previous examples we have just created the objects. The logic was to create the object and set properties in the same process. In the script below we use another logic, which is pretty much create an empty object, and then, property by property, we “change” the object (mean add a new property). What is the difference? For our SET, we need to do it another way.

For the 3 first properties of our Set (ObjectType, DisplayName, Description) we could have used the previous logic. But we want here to load in a multievaluated property named “ExplicitMember” (List of groups in this SET) a long list of pointers to group objects. So we need to “code” the logic a different way.

Here is how we can achieve that job :

So now you have learned another way of coding in FIM.

This new example below is a Set, but based on a XPATH Query :

Note : I recommend to test your XPATH query first in the FIM portal, advanced view if needed. If the XPATH is for any reason bogus or not compatible with FIM, the PowerShell code will generate a “generic” error… since FIM web services will refuse the format (and you could think it is your code).

So now warm up is finished. We will see how to create a sync rule, which is a bit more challenging.

Note : After reading this part, maybe some of you will have ideas to enhance the approach. Feel free to contact me, always want to learn. What I mean here is that the below scripts work very well, but I have the feeling that we can enhance it.

So back to the reason I started to script in FIM, I wanted to set up an offer where we could automate FIM installation. Part of FIM, we have Synchronization Rules.

The methodology (we probably can enhance it) I used is to first configure FIM manually, so create my sync rules, test my configuration, tune it if need.. and then take this manual configuration as the basement to build my script.

Sync Rules are in fact a bit complex since they have many options (in, out, in/out), many properties, and also contains some complex data (the properties matching). So first let’s investigate a bit how is structured a Sync Rule in FIM via the FIM Portal (being autonomous)

Here is a screenshot of the sync rule I will use for this article. Supposed to sync users between FIM and AD :

If you go in the outbound TAB, you can see the matching, and also notice some properties marked as Initial flow only, Existence Text, .. etc. This is very important for the next part of the article !

If you go in advance view, you can see that FIM propose for the “Existence Test property” to download it as a text file. The reason is that this property contains a lot of data, and showing it in the FIM Portal would be very ugly.

The same approach is used for Initial Flow and Persistent Flow.

If you download one of these files, you understand that each “matching” in the FIM portal is in fact a line in the corresponding property, but for a reason I don’t know each matching line is separated with the next one with a line of “-“ when exported.

So now we see how this object is created in FIM.

The methodology I used to script in the context of my scenario is again to create the rule via the Portal and test it. But then, rather to hard code the value of each properties especially these complex “ExistenceTest/InitialFlow/PersistentFlow”, rather save the file on the hard disk to prevent errors (especially when properties contains stuff that could cause problem in the code such as quotes, double quotes..), and then have a “Load from file” approach in my script.

Let’s see the code now…

So first, I created 3 variables that contain the name of my 3 “flow” import files (again it facilitated the reuse of the code, copy and paste approach). I load the content of these files with the powershell Get-content command :

Then the beginning of this Sync Rule is classic, it follows the same logic has we have seen in the previous posts :

But at the end of this screenshot we want to set the “Persistent Flow” propertie.

To do this we have a basic “Loop” in the code that will parse the variable we have loaded in the beginning of the script, remove the “---“ lines and just then set the property.

At the end of this loop, we have our “new-fimImportChange” function that se the “PersistentFlow” Property.

Then we do the same with initial flow :

And with Existence Test :

Finally we create the Sync Rule object which contains all the parameters we want.

As you can see, Sync Rule is a bit more complexe since we have these “flow” properties. I have seen some other IT PROs that prefere to put the matching in their code (rather than import from text) but the main raison I did this is because it is so convenient to change something in the portal, test it.. then export the new flow in a file.. next time you use it it works without other effort (rather than changing a code). Remember ? I am not a PowerShell developer.

I hope these samples and explanations will be useful for you.