Skip navigation

I’ve been using and developing against the product that has become known as FIM 2010 R2 since 2003. This particular piece of software started life at a company called Zoomit and was developed originally by a guy named James Booth. (Please correct me if I have the backstory wrong.) Zoomit was acquired by MS and they changed the name to Microsoft Metadirectory Services. I encountered this in the form of MMS 2.2 and I helped migrate a large IT department to the first version of what would become the FIM Synchronization Service, MIIS 2003, in 2003. The next revision was in 2007 and came with another name change, Identity Lifecycle Manager 2007. The product was essentially unchanged in that it was a synchronization engine that could be extended with C# or VB.Net to sync data  between LDAP, SQL, flat files, Lotus Notes…you name it. I found this extensibility really empowering. It’s the main reason that I ended up focusing on development instead of system administration.  Despite the sort of “can do” attitude that it fostered in administrators and developers, when polled, end users kept telling MS to “get the coding” out of the product. The next release would add “declarative provisioning” capabilities to accommodate this desire. I think the results are mixed. It would also have another name change. The product had been moved into the Forefront brand group, containing such “winning” pieces of software as IAS. (Yes, that IAS…the “proxy server of doom.”)

FIM 2010 provided some very compelling use cases. Secure Self Service Password Reset is a feature that can provide a single unified password reset experience whether it’s performed from the GINA/Credential Provider, that’s the CTRL+ALT+DEL prompt to the rest of the world., or from a web based portal. The Synchronization Service could now be controlled via declarative rules in a SharePoint based portal that also included the ability to trigger workflow tasks when an object changed state. It also allowed delegated user and group administration. This was improved in the R2 release and then again with the SP1 that came out in early 2013.  There are still some rough edges, however.

MIIS 2003 could be customized by providing implementations of .Net interfaces packaged in a .Net DLL extension. The sync service scans a directory for extensions and loads them when it starts. This provided extensibility for every part of the sync cycle.  When mapping an attribute in AD to an internal object the service would call into your DLL and you could process it any way that you liked with the full capabilities of the .Net Framework. There were guidelines about the kinds of things that one shouldn’t do while the engine was doing its work, but it was the definition of flexible. While in the sync manager UI you could even have it create a Visual Studio project for you with skeleton code for you to customize. All of that functionality remains, but there are some problems with this approach. Don’t get me wrong, I loved working on this stuff, but it’s requirements are becoming a “non-starter” in lots of IT shops. Namely, to work with the sync management service you have to logon to the console of the server via RDP. Not a big deal, but as of Server 2012 the official default deployment model is Server Core. You can’t use the sync service on Server Core. You need the full UI. In addition to this, if you want to debug any errors that you run into you need Visual Studio installed on the server. In 2003, it was recommended for production servers…I still do it to trap errors in the debugger that only arise with the full production data set. This really isn’t a good model going forward.

But what about declarative provisioning you ask? Wouldn’t that eliminate the need for having custom code in the sync service? I’m sure that there is an 80th percentile case where yes, it would do just that. The problem is, though, the real utility of this software has been its flexibility in an area of IT that is rife with idiosyncrasies. The process of discovering, processing, and then syncing changes to and from the different identity “silos” around an enterprise can be incredibly complicated. This is often for reasons that are more political than technical, but because of that you might need to take steps that you might not otherwise. So, for instance, you may have an attribute in a database view exposed by PeopleSoft that needs to be modified ever so slightly before it’s considered “gold” and ready to be sync’d to other systems, like AD. (And maybe the PeopleSoft guys hear “Microsoft” and tell you that they are afraid that it will “break” their database. Seriously.) Currently, FIM 2010 R2 provides some limited means of manipulating it with some functions like “TRIM()” or “LEFT()” but the experience is akin to writing JavaScript in notepad after you have become used to using Visual Studio. Did it work? Who knows until you actually get the new “sync rule” into the engine via an import and start synchronizing….then its entirely possible that the “expected rule entry” that links every object to it’s particular matching sync rule could just say “unapplied”. Without going into the guts of how sync works on FIM 2010 (I’m saving that for another post) lets just say that in some ways the current declarative system is easier for most things, but when you want to do something that it can’t do you are in the weeds. Just how far in the weeds is kind of amazing…like I said, I’m saving that for another post, but wow. Just wow. I earn a living working with this software and every now and then it occurs to me just how much weird behavior that I have grown accustomed to over the years.

Anyway, as of a few months ago the Forefront brand is no more. Most of the products in it’s line up have been killed. “Endpoint Protection” has been moved to the System Center line of products. I expect that the next major release will continue the pattern of name changes that have accompanied every major release. I’ve been giving some thought to what the future of this thing should look like…at least if someone cared what I thought about the subject.  Smile

First off, it needs to run in Server Core. There needs to be a “development version” that you can run on your workstation where you can model the desired behavior for your environment and then upload it to the actual sync server. The current SharePoint portal just isn’t a good way to configure this incredibly complex software. It’s fine for delegating access to users and groups (as long as you don’t need to do much customization), but when you are doing admin or development work it is really death by a thousand cuts. They use AJAX wherever possible in the UI, but it’s always loading something…and even though it uses AJAX it still blocks the UI! This is due to the main thing that needs to be taken out and shot in the head. The “FIM Service”.

FIM 2010 introduced a new component called the “FIM Service”. This provided a new database separate from the meta-directory database that the sync manager operates on. It also provides a hosted workflow engine via Windows Communication Foundation and Windows Workflow Foundation. This interacts with the SharePoint based portal via a WCF soap-based web service. The portal surfaces that functionality in the web service, so while you do your administration and configuration through the portal you are actually using the web service. Awesome, right? That must mean that you can fire up your favorite development tools and customize it to fit perfectly into your environment, right? No. Well, you could. If you were really a hardcore WCF developer, I’m sure this would be easy. No one, let me repeat, no one who works with this software is a hardcore WCF developer. No one. For that matter, even hardcore WCF developers don’t want to be WCF developers. WCF made writing web services incredibly easy compared to DCOM. Open heart surgery is easy and agile compared to DCOM, so that’s kind of a low bar.

It seems like FIM 2010 specs were designed by well meaning people. There are lot’s of things about it that one would have thought were a good idea. It’s web service is the most standards compliant I have used. You could use it from Java if you were so inclined. It uses SharePoint, which lots of people use, right? It uses Kerberos constrained delegation. It has it’s own Secure Token Service to issue claims for the web portal. Lot’s of buzz in those words there. The problem  is that while this was going on the world shifted to light weight REST based web services that humans can use and understand. Microsoft has another Secure Token Service called ADFS that works pretty well from what I hear. No one uses the web service in a way that warrants the added complexity. Because of SharePoint and the web service together the portal always feels slow. It has it’s own little AJAX spinner to let you know its loading data from the service…learn to love that little spinner. That’s all I can say. The workflow stuff is genuinely useful, but they have another workflow engine that is getting a great deal more development energy…It’s called System Center Orchestrator and it’s awesome.

System Center has it’s own self-service platform called Service Manager that can be coupled with SC Orchestrator to do everything from provision servers to running arbitrary PowerShell code. You can define service offerings and expose them to your enterprise customers and  tie that all together with approvals and notifications. Service Manager can integrate with SC Operations Manager to open a ticket if there’s something wrong with a service. FIM can do approvals. FIM can do custom workflow’s. (Like I said, there’s a future post coming on the pains of developing for FIM.) FIM can run PowerShell by an unsupported workflow module developed in the community. There are a couple, in fact. The problem here is that the System Center products are getting the major energy and focus at MS. That’s really what I see happening in the future. It’s something that I will be investigating in my own dev lab very soon, as well.  The sync engine could be paired with Service Manager and Orchestrator to do everything that the current FIM solution does…and more. All without that painful SharePoint portal. Did I mention that you get a Service Manager license with FIM 2010 R2 for logging? Hmmm….The Forefront brand is dead. Other Forefront products have been transferred to System Center. Service Manager is already integrated with FIM…It doesn’t take a crystal ball to see where that’s going. In fact, I’m pretty sure that I could build a passable replacement for the “FIM Service” components my self in the mean time.

I’ve been working with this software since it came out and recently I’ve gotten as deep into this thing as you can get without the source code. It’s been really, really painful. The next post will just be about what I would like to see if I were building some future version.

Advertisements

One Comment

  1. I liked this post very much and it made my smile more than a few times. 🙂 I was working for Microsoft for 7 years and I have worked with nearly every version and release of the MMS/MIIS/ILM/FIM (there was also the foster child called IIFP coming as a feature pack for Windows Server 2003 back then) family and I share most of your pain and agree with most of your observations here.
    IAS is really ISA, though (Internet Acceleration Server) and that wasn’t that bad at all… 😛


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: