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.
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!
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.