What other objects in FIM ? Being autonomous (Part 3)

One of the things I learned working in IT is that being autonomous is key. What I mean here is the ability to “discover” how to do something yourself, for example in case something is missing in the documentation.

In the previous article I showed how to script FIM with basic examples.. but what about the other objects in FIM ? In the FIM schema, you have a lot of objects, and each of these objects have a lot of properties:

So I would like now to show you how I “discovered” how to do it a few month ago.

Let’s suppose that you want to create a security group in FIM using PowerShell.. but that it is not documented (I mean no sample to download). The first thing to do is in fact to create this group the normal way, via the FIM portal. We do this in order to see what FIM Portal has created in terms of objects and properties.

Here is the example of the group I will use for this article:

All HR Group is a “manual” (not criteria based) security group. In the “Member” tab we have a few users :

.. you can see here that I have 4 people in that group.

The first approach to “learn” is to click the “advanced” view button in the portal. Then the web interface will display all the properties of that specific object. As you can see below, the interface is nice but we could have problems with the names displayed (not in fact the name of the properties). As an example, my interface is in FR and that is definitely not the name of the properties :

Second possibility is to go in the REQUESTs section of the portal, and look at the request.

But I have a better approach for you: scripting !! Look at this script :

With this script I ask FIM to export the configuration of an object where its type is a GROUP, and where the DisplayName is “All HR”. This is in fact what we call an XPATH request (sort of SQL for the IAM solution). The convert-FIMexportToPSObject will format the text displayed.

Executing this script will show us this result:

As you can see we have the exact name of the properties and of course the corresponding value. It is again very easy to use Copy and Paste and prevent mistyped variables in the script.

On this screenshot you can see some properties, such as an account name, a display name, a domain, etc. These properties are in fact the ones we need to set when we create a security group.

You can also see “ugly” things starting by “URN”. These properties are “references” (a pointer) to another object in FIM. For example, “Creator” point to a “user object” in the FIM database which is in fact the account that has created this object.

Once you have this, then you just need to create the PowerShell script based on the previous examples. You understand now how this “extract” code is important to discover how FIM works.

But let’s use another example to continue this article: Create an MPR.

Here is the extract script again (This MPR in my scenario means “Arrival of a new employee”):

You can see some new properties such as actiontype, TransitionIn… etc. A nice exercise would be to edit this MPR in the portal, and identify the corresponding properties. This helps to “link” the Portal view and the one displayed by the script.

If you look carefully, we still have those “ugly” “URN” links. Same as previous, the “MPR Object” contains pointers that are important here, for example “the Action Workflow Definition” that contains all the workflows you execute with this MPR and also others such as RerouceFinalSet.

So now that we have observed that “dump” of a working MRP, how can we script it. Here is an example :

If you observe the script correctly, you instantly understand that prior to execute it, we need to create a few other objects. Especially the “SET” that will be used as the trigger to wake up this MPR, but also the “workflows” that we want to execute in this MPR (be patient, we can also script). As we have seen in the previous dump, the SET and the WORFLOWS are not in fact a property of the MPR object. The MPR contains just pointers to these objects.

 

I would recommend now to play a little bit with this nice “extract” code and dump a few standard objects such as a User, a Distribution Group, a Workfow, .. etc.