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 alternative
solutions 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.

Leave a Reply