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.

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!

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!

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.

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:

'Those people who need to administer FIM, need a user account in the portal, so treat them as such and Project!

MVObjectType="person"

ShouldProjectToMV=True

ElseIf csentry("employeeID").IsPresent Then

'Real users - e.g. those created by the User Office process and those historical users no longer in CDR (Initial Pre-Load) - But CDR is authoratative for all new users - so Projection occurs there also - this handles "normal" users - e.g. those fed from CDR directly.

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:

Boolean Flag Setting Example

Visual Basic .NET

1

2

3

4

5

6

7

8

9

10

11

Case"functionalIDFlag-ADMA-Import"

If csentry.DN.ToString.ToLower.Contains("functional")Then

mventry("functionalID").Value="True"

ElseIf csentry.DN.ToString.ToLower.Contains("ou=fim")Then

mventry("functionalID").Value="True"

ElseIf csentry("employeeID").IsPresent Or csentry("stfc-pid").IsPresent Then

'Real users - e.g. those created by the User Office process and those historical users no longer in CDR

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.