Code Sample

ShouldProjectToMV and boolean flag setting Example

, 0 Comments

Another thing that I messed about with while “making FIM fit”…

I wanted to manage certain non-real people accounts. I did not need them to be present in the portal, as the code would manage the accounts alone. Therefore I needed to project them to the MV for the code to take effect.

To do this, I created a copy of the person object, trimmed a few unnecessary attributes – the new object was called “functionalID”

Now, after bringing those ID’s in as functionalID’s, I realised that some of the administrative accounts needed access to the portal to manage the real user accounts. So, I exported all functionalID’s to the portal, they were not visible, as the portal did not know what to do with them. After fiddling about, extending the portal schema and creating MPR’s etc. I was able to view and manage those ID’s. However, I wanted the administrative ID’s to be able to log into the portal to do their day to day work.

Trying to login with an Administrative ID did not work! I made sure that all of the required attributes were present in the portal for those accounts (https://social.technet.microsoft.com/Forums/en-US/04ea0c9d-0e31-4027-b035-fc20b9501a46/enabling-fim-portal-access-for-a-regular-ad-user-account), but still the accounts could not login to the portal.

Now annoyingly I can’t find the link, but to summarise it stated that only person type objects could login to the portal! Thus, my copy of person type would never be able to login! Arrhhh!

So, a little rethink….. treat all functionalID’s as functional’s except those that were in the OU containing the Administrative ID’s that I wanted to have access to the portal – treat them as person objects – as shown below:

However, after all this I decided that it was far simpler to just treat all ID’s as person objects, and then flag those that were functional’s (with a boolean flag). That flag is then used to manage the accounts in code and can be used to exclude those accounts from view in the portal. Flag setting is done on the import from AD, using specific strings within the DN as the criteria:

Sample code for FilterForDisconnection

, 0 Comments

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

, 0 Comments

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

, , 0 Comments

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

, , 0 Comments

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

1 2 3