Code Sample

Sample code for FilterForDisconnection

While implementing FIM, I was looking for ways to filter out old records from the HR database. Note that this code is no longer used (the SQL view providing the data does it for me), but it provides a nice simple example of how to use the FilterForDisconnection function.

I used the following bit of code in the HR MA, to filter out all users whose end date had passed plus 190 days. Those that matched those criteria were made disconnectors.

Sanitizing employeeEndDate

The source of my “HR” data does not always return consistent data.

A classic example of this is employeeEndDate, where the time value returned by the HR DB is often 00:00:00, but could be anything else!

The result of this is that if the user disablement rule says – use date/time of now – compare it to the employeeEndDate; if the end date has passed, then disable the account. Thus if the time value is inconsistent, you will get inconsistent user disablement’s occurring

So, to fix this in code, I did this – on the import from HR:

Now all employeeEndDate times are consistent “T23:59:59.000”

Defining a Unique Email Address

While looking at how we were going to define an email address, there were a couple of options.

Many accounts already have a mailbox, so I just want to provide an email address and the other required attributes to those who fall into scope and did not have a mailbox already.

Note that the compulsory attributes required for a basic mailbox are: homeMDB, msExchHomeServerName & mailNickname. By adding the mail attribute, I am defining the primary SMTP address that the person will get. See here for more details: https://technet.microsoft.com/en-us/magazine/ff472471.aspx

Initially, we planned to use and Exchange Email Address policy: https://technet.microsoft.com/en-gb/library/bb125155%28v=exchg.141%29.aspx.

However, there was some fear that if enabled it might have some undesirable effects on those existing mailboxes. So, I went back to code to do the work. The use of Utils.FindMVEntries is not necessarily expensive in this case as the number of people falling into scope at any one time should be low and the likelihood of the first choice not being unique is also relatively low.

Because my organisation is multi-tenant and multi site, there are a number of rules defined to get to the correct suffix and then a valid prefix/ suffix pair.

The MV attribute “provisionExchangeMailbox” is defined in the MV as the person is sync’ed from “HR” via an advanced flow rule. Here is the code:

Logging

When I was developing the code to define an initial password for new accounts that were due to be provisioned, I needed a way of seeing the password string that was generated.

I found it quite difficult to pick through the documentation around the subject (logging) in order to get this working, so have provided a generic example below.

I ended up using the logging dll throughout the project, to record certain anomalies.

The log will be written to the MAData folder of the MA that the code resides in. The documentation states that the file location can be changed, but I never got it to work. I’m happy with the default it is written to anyway.

Note that you need to add the logging dll to the project before you make use of it:

References