Installing SharePoint Foundation on a Domain Controller

It’s been a long time since I blogged about SharePoint, and that’s largely because I haven’t had a need to develop anything custom on top of the platform for quite some time.

If you’ve been following along for a long time, you may recall that back at the start of last year I installed SharePoint foundation on a Windows 7 Virtual Machine at home for testing purposes and, while I didn’t blog about it explicitly, when I upgraded my home server last August I replaced that Windows 7 virtual machine (which ran on my laptop) with an always-on Windows 2008 R2 VM, again running SharePoint foundation.

As my home network continued to evolve I turned that Windows Server VM into a domain controller, and this broke my SharePoint installation – but by then it wasn’t all that important and I didn’t need it for work anymore, so I simply uninstalled it.

Recently, I’ve been missing having SharePoint’s functionality at home. In particular, I wanted a shared calendar for Flo and I, and a place for shared documents. We can achieve much of this with Google calendar and our existing shared folders (and I already have a tool deployed that makes our network shares available from outside our home network), but it all feels a little kludged together and it’s lacking features like NTLM based SSO and an easy way to edit files from the web-interface that SharePoint provides out of the box. I looked at a couple of alternativesolutions and wasn’t satisfied.

Previously I’d deployed SharePoint foundation in standalone mode. This installs and runs all the required components on a single machine. It’s not recommended for a full-scale deployment, but it’s perfect for our home network. The problem is that this simply isn’t an option if you install it on a domain controller, and instead you have to install a server farm. In googling around, the consensus online seemed to be that it wasn’t possible to install SharePoint on a single server if that server was also acting as the domain controller.

Not so.

It is possible, and in fact it’s pretty easy. I made a couple of missteps by attempting to follow along with what some other people had done, but the solution was actually extremely simple: first you need to install SQL Server 2008 R2 SP2 express (and it has to be at least this version), then you install SharePoint Foundation 2010. For all the discussion online, I actually didn’t have to do anything other than accept the default options to install SQL server. When I installed SharePoint it doesn’t give me the option to install in Standalone mode, but I simply pointed it to the SQL Server instance I had installed and that was all there was to it.

That being said, things are not all that rosy. Just because this setup is possible, doesn’t mean it’s recommended – and this is certainly not Microsoft’s recommended way of doing things.

Microsoft advocate for a separation of server duties, and having different, unrelated services running on different machines. Now that I’ve entirely eschewed that philosophy I can see why it’s important: SharePoint is running well and performance is snappy, but general internet performance on our home network has suffered, and I believe the fact my single Windows server is also the DNS server for the network is the problem – DNS lookups are slow.

I may try and solve this by trying to install a slave DNS server on the Linux server we have, but if not then I think SharePoint will have to go away in the interests of DNS performance.

Or, maybe I just add a second physical server and move a few of the VMs to that? We’ll see.

Comments & Discussion