PowerShell MA and the FIM Service

I was working on a FIM2010 R2 project where the customer wanted to manage a bunch of DFS groups in the FIM Service / Portal.

However, all the groups (1.600+) would continue to start their life in Active Directory based on some scripts. Therefore we wanted to bring all groups from Active Directory and in to the FIM Service just once and from there on manage all attributes including membership filters from the FIM Service.

Due to precedence, we could not use the FIM MA to create the groups in the FIM Service, so we had to come up with another solution. Again, my PowerShell MA came to the rescue.

Here is how we did it -

1. We created another standard Active Directory MA scoped to the few OU's that contained the groups in question. We set that MA to only import and project a new metaverse type (dfsGroup) and import a few attributes, such as sAMAccountName, displayName, description and such.
2. We then created a PowerShell MA (PSMA) for use with the FIM Service. For this we used my PowerShell MA.
3. We wrote provisioning code to provision all dfsGroup metaverse objects to the FIMService PSMA.
4. We wrote fairly simple scripts to read / write the new dfsGroups to the FIM Service as normal FIM Service Group objects
1. The creation was merely to create a simple security group in the FIM Service. We utilized Craig's Martin's great PowerShell modules for this.

Now we just set the schedules and watched the Synchronization Engine bring in the groups from AD, project them to the metaverse and have them be provisioned to our FIMService PS MA - where the export script elegantly created them in the FIM Service.

On the next import from the standard FIM MA, the new groups would be projected to the metaverse as normal group objects and the groups imported in the normal AD MA could now join - and bum, membership was now maintained using the filters applied when creating the groups using our FIMService PowerShell MA.

Sounds interesting? Get the PowerShell MA here and the scripts here - oh, and don't forget to get the latest cersion of Craig's FIM PowerShell module (although I included the version we used in the download bundle). You may have to change a few lines in the PSMA scripts for logging and such, but beyond that they should be pretty much functional out-of-the-box.

As always, I'm interested to know if you find this useful.

Thoughts: FIM is now MIM

Today, Microsoft announced the new name for FIM2010 or Forefront Identity Manager vNext. Future versions of FIM2010 R2 will be known under the Microsoft brand, and so the next release will be known as Microsoft Identity Manager.

I can not help giving this announcement some thoughts.

A published roadmap like this (http://blogs.technet.com/b/server-cloud/archive/2014/04/23/forefront-identity-manager-vnext-roadmap-now-microsoft-identity-manager.aspx) is reassuring for customers running FIM2010 today - and also for customers considering utilizing FIM2010 for their identity management needs. Their technology choice now proofs sound as Microsoft is continuing investments in the product.

Also, the major investment areas mentioned in the article above gives me confidence that Microsoft is gonna take the product to a new level where it makes sense to really put this tool into play in your infrastructure.

With the current version, I've already built some great solutions that really supported organizations needs. If I read correctly between the lines, I have no doubt that I will be able to leverage all the new features in the next version with existing FIM2010 installations - and make these even better. And I'll have a lot of new stuff to help build great identity management solutions.

I'm really looking forward to more information on timelines for preview programs and the release schedule which is  to be released later in this year.

Let's stay tuned...