To Farm or not to Farm Part 2

March 29, 2018

In the original To Farm or Not to Farm post I discussed the pros and cons of setting up FIM on a SharePoint farm or using Stand Alone. Well we now have SharePoint 2016 and it isn’t possible to install Stand Alone, although you can do a single server farm. Also, absolutely everything is virtualized and so we tend to share lots and lots of processing so we can’t really think of a server as having spare cycles, because we share those processors with lots of other VM’s.

This first point got me thinking and the last point now has me convinced that we shouldn’t do Stand Alone on SharePoint 2013 Foundations or any other, because it adds the overhead of SQL Express when we can get better overall performance by using the real SQL Server, even if the SharePoint databases share it with all of the MIM databases. However, the patching issues brought up by Paul Williams are still real.

I think a lot of people have been sticking with the free option – SharePoint Foundations 2013. Which is possible to install on Windows Server 2016 even if it is not exactly supported. So a lot of folks have avoided thinking about SharePoint. Here are some points to consider

The challenge has to do with the way MIM does its updates. If you separate MIM Service from the MIM Portal then you are better off when it comes to the MIM updates if you are in a multi-server farm.
I have not seen any guidance from Microsoft Identity about what roles are needed in SharePoint 2016. However, it appears to me that the MIM solution is essentially a content farm which perMSFT would require 3 roles or 2 servers with shared roles, or the single server farm: Front End, Application and Distributed Cache.
For Zero Downtime patching to apply you need to be in a Highly Available solution. With Min Role that takes 4 servers. Unfortunately, I don’t know if that will allow you to update the MIM solution pack without downtime. One of the changes that the SharePoint team made is to keep stored procedures in the SharePoint databases backwards compatible. I don’t think the MIM product group has made any such guarantees. So when we patch MIM Service it will update the database and the MIM Service. At that instant only updated MIM Service instances should talk to the database (they might work, but no guarantees), and only updated Portals should talk to the update MIM Service Instance. So I think we still end up with downtime, the key is to minimize it. The Zero downtime patching would certainly reduce it when you patch the actual SharePoint binaries. But we could accomplish the same thing with two single server farms load balanced through NLB.

Anyone else have any thoughts or experiences to share?

So for now, I recommend essentially a single server farm on SharePoint 2013 Foundations, and to use your own variant of Spencer Harbar’s scripts to configure it. If you want to do that don’t check this box: