FIM Portal in a SharePoint farm–why you should not do this

That is correct.  You read the title of this post correctly.  I am, officially, on a mission to save you from making one of the biggest FIM Portal deployment mistakes you can make.  Do not, I repeat, do not use a SharePoint farm!  Even if you have multiple nodes.  Use multiple standalone SharePoint instances and load balance the requests using your preferred mechanism.

Why?

Well ask yourself this – what does a SharePoint farm actually give you?  Other than a serious headache when patching and more operational maintenance in the form of SQL databases and more complexity around backup and restore (or rebuild) and patching SharePoint itself (and modifying web.config).

I have deployed two multiple node farms – once on WSS 3 and once on SharePoint 2010.  I regret it.  Why did I do it?  Because I didn’t have a compelling argument either way and was talked into it by the customers.  One argument – WID isn’t for enterprises; the other – the simplification of deploying customisations.  I bet the former complicated their AD FS 2.0 deployment using the same argument too.  But I digress.  I’m not bitter.  I’m just wiser; a little older, a little more experienced and now, thanks to this topology, showing the first signs of grey hair!  Smile

I now have a somewhat compelling argument (although until you’ve sat in hours of meetings regarding patching you can’t really appreciate some of my sentiments):

I have to patch my four nodes sequentially, and the process takes quite a bit longer than a standalone node.  The reason?  Each time we patch we retract the solution pack and deploy the new one.  The benefit of using a farm is that you deploy the solution pack once.  Right.  But the FIM installer isn’t optimised for a farm – there isn’t a portal installer and a service installer, there’s one patch for both.  So you have to patch the portal for each node even though you don’t have to.  And this causes downtime.  Each time you retract and deploy a solution pack in SharePoint all application pools related to SharePoint are recycled.  Each time you patch FIM the service must be stopped.  Is it easy to run with fewer nodes and patch sequentially – no, you need to get all nodes on the same build ASAP and the more nodes there are the longer the SharePoint retraction is.  And the retraction and redeployment is global (to SharePoint) so that downtime affects all nodes in the farm – you can’t drop one out of the NLB array, patch, add back, drop the next, etc.

I have to patch all four nodes when patching language packs.  This is where it gets really nasty.  The language packs comprise some file system files for the FIM Service and SharePoint solution packs.  Again, one installer.  Nice!  It actually takes us ~6 hours to patch the LP on one node, and I have to sequentially apply four patches.  Yep, that’s a full day or at least two working days if there aren’t shift-staff.  And, all the time the application pools are being recycled.  So you need scheduled downtime.

I also have three or four database in my SQL instance that now require more management than the optimised WID files that are totally expendable.

And again, what benefit am I getting?  It’s a little easier to redeploy my CSS changes.  True, but scripting that copy operation on all nodes is not exactly hard.  We’re certainly not getting the benefit of a deploy once for many node solution pack.  Also, it’s harder to modify the web.config file of the portal – technically you now have to do this via PowerShell (or .NET) otherwise processes that actually manage the web.config can loose your changes or cause indirect breaking changes.

I have been involved in quite a few FIM Service and Portal design and deployment projects now – various levels of involvement, from owning and authoring the design and deployment documentation and synchronisation and WF code including actually doing the installation to writing the design and running for the hills, including being called in to save a failing project and migration/upgrade planning and technical documentation review.  In all of these cases I can’t think of a single compelling argument for a farm.  True, there were arguments on one of my most recent projects that meant I was in agreement at the time but hindsight has only strengthened my position – truly bolstered it actually.

Humbly happy to understand arguments for a farm via comments, forum or group posts or e-mail.

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM and tagged , , , , , , , , . Bookmark the permalink.

6 Responses to FIM Portal in a SharePoint farm–why you should not do this

  1. Pingback: Editing the FIM Portal web.config in a farm topology | Yet another identity management blog

  2. Scott Eastin says:

    So what are your thoughts about FIM and SharePoint 2013? Does the stand alone recommendation still hold or is it better to use farm mode as demonstrated in Ross’s article?

    http://www.fimspecialist.com/fim-portal/installing-fim-2010-r2-sp1-portal-on-sharepoint-foundation-2013/

    Thanks and great article on SP 2010

    • My thoughts haven’t changed. 🙂

      This week I’ve been working with a customer with a farm who needed to fix broken LPs by re-aligning the LP build with the Service and Sync engine builds and it has been a painful process. Made more painful by the farm. In fact, LP patching in the farm is the worst aspect of all. I’ve learned my lesson – the advantages, few as they are, are massively outweighed by the disadvantages.

      The issue is not SharePoint but FIM, and more specifically how the FIM MSPs are not really suited to a farm, assuming standalone.

      As for SharePoint version, I typically defer to what is permitted, i.e. while I initially opted to use SP2013 I was unable to do so due to lack of support on WS2012. Now that we have that support I assume moving forwards I will always use 2013 unless something compelling shows up that forces me back to 2010. But whether I use 2010 or 2013 I will always be deploying on standalone WID-based instances.

  3. Scott Eastin says:

    Thanks Paul you confirmed my thoughts as well. Keep up the great blog, you always have good stuff!

  4. Paul,

    I really enjoy you illustrating your painful experiences so that the rest can benefit.

    However, some raise concerns about doing a Stand-Alone SharePoint for FIM. SharePoint MVP, Spencer Harbar, among them. I wrote a blog post wherein I “moderate” the debate. I would love for you to read it and weigh in through comments or on your blog. I have also proposed some alternatives (they have trade-offs, of course).

    http://blog.ilmbestpractices.com/2014/05/to-farm-or-not-to-farm-that-is-question.html

    • Quality post David. I’m going to see if I can respond via another blog post soon. In the customer case I reference we have two farms, which has advantages and disadvantages, but overall I am a standalone guy, so I’ll re-read your post and check out what Spencer has to say and then weigh that up with our experience of patching (we have just done it all again, and our experience from last time made it easier this time).

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