Have you ever had to do something that you knew (you just KNEW) that lots of folks were going to scream – and scream loud – about? This is one of those cases – I can just feel it!
Ok, here goes. There have been several recent newsgroups postings concerning why we require domain accounts to install PowerPivot for SharePoint. Why must the farm account and the various service accounts be domain accounts. This causes lots of heartache for users that want to install demo or evaluation servers because we don’t support a standalone server. Well, we do support standalone, but it a different kind of standalone. Let’s get right into it.
First, let’s compare and contrast this requirement with SharePoint. SharePoint has two types of installations: standalone (which they do NOT support in production) and complete/farm. The standalone installation is for demo and evaluation purposes only. It has uses NETWORK SERVICE as the service account for many of its internal processes. It is right up front that it is NOT expandable into a production system; it has security issues acting across servers; etc. However, it gives you a nice “toy” to play with. Let’s be right up front about it – PowerPivot does not install nor does it support a SharePoint standalone server installation. And, oh while we are on the subject, SharePoint does not support local machine accounts within a farm configuration. In the SharePoint world, once you go to domains – you go all of the way with domains.
PowerPivot’s philosophy for the NEW FARM case is that it is a complete farm that just happens right now to be on a single machine. We take a production-view of the single server. We would expect that it would natural that at some time in the future that the SharePoint administrator would move the content and config databases off of this server and put them on their own dedicated SQL Server machine. After all, this is a best practice for SharePoint to have a dedicated (or consolidated) SQL resource off of the WFE and App Servers. And just as the RDBMS traffic is very likely to grow beyond a single combined “all-in-one” server; so would the app server requirements continue to grow and it is perfectly natural for a second, third or more app server to be added to the farm; likewise as the server becomes more main stream, there is a high-availability requirement that will become more important and multiple WFEs will be come important.
The bottom like is that proper capacity planning begins with your first installation. And thus we require domain accounts right from the very beginning.
Yes, this does impact those folks who are doing demos and evaluation. You have two options: (1) install a domain controller on your image and thus local accounts are domain account; or (2) install the server into a domain and possibly then disconnect from it (see an earlier posting from me on this topic). Approach #1 is what most users do. If you look at all of the “All-Up” VMs that Microsoft produces for other products, you will see that a self-contained domain within the VM is the way that most folks go. I personally use technique #2 because I do demos in a very constrained environment and having to modify the workbooks that I am demoing with is fine.
< OK – Let the screaming begin 
>
