Using Ryan Newington’s Lithnet FIM PowerShell Module to improve performance of group membership (ComputedMember) reports

In my earlier post about Automatic Group management via the portal (, I provided a sample script to get the ComputedMembers of my auto groups:

While this script did the job, it took a rather long time to process, it was an overnight job. If it had failed overnight, I had to wait another day before doing the comparison against production auto groups.

In the August FIM Team User Group, Ryan Newington presented his work –

I had been planning to try out the PowerShell module (, so yesterday I got the chance!

Here is the re-written script:

In terms of performance, the Lithnet PowerShell module is much faster. My standard script took ~7 hours to run, while the Lithnet script only took 3 hours!

I can see that I’m going to get a lot more use out of the module in terms of making changes as well as getting information from the portal. Thanks Ryan!

So, as per the comments, Ryan’s suggestion really improves performance of the script! Here is the new script for reference:

Defining a Unique Email Address and Validating Mail Suffix

In addition to creating a valid and unique email address – as defined here:

I also need to detect where those addresses might need to be changed. The AD and Exchange infrastructure supports a number of different tenant organisations, each with their own needs. There is regular horizontal movement of users between these organisations.

So I have added to my code to define a unique email address – the additional content starts at Line 72 – statement “If mventry.Item(“mail”).IsPresent Then“. Note that attributes are set on the import from HR to define who is entitled to an MBX and those who should just be mail enabled. The current code just logs out those things for action, but I have also included making these events throw an exception to the Sync Engine.

It was interesting to see just how many people are not really entitled to a mailbox, but who have one anyway!

Full WBADMIN backup script

Script to do a full backup using WBADMIN to a local staging drive and then copy the resulting files to another server. The clean-up script (called within my script) can be found here:

This resulting backup files from this script allows me to do a bare metal restore of a virtual domain controller within ~30 minutes. This assumes complete meltdown of your domain – catastrophic failure, schema issues, compromise, etc. – where you need to restore it from scratch – this is a last resort action!. Once restoration is complete move onto the rest of the recovery process. Of course this script will also do nicely for just backing up all critical drives and registry on any other server or client!

ShouldProjectToMV and boolean flag setting Example

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 (, 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

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.