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.