Platform: Windows Server 2003 (including R2)
Application: Windows Sharepoint Services (in this case version 2.0)

Best practices are to try upgrading in a lab before taking the plunge with new apps. We're in the process of moving our old Sharepoint Team Services app up to version 3.0, and I wanted to tinker with it in a lab environment before I went for it.

Fortunately, most of our environment is currently virtual machines (VMWare). So, I found a downtime to copy those guests over to my desktop, set up an isolated network (vmnet2) and bound the NICs to that network. I copied over my IIS server with sharepoint on it, Created a separate SQL Server and restored recent backups of the sharepoint databases, and one of our domain controllers/dns servers so the other 2 machines had a DC to talk to.

I kept getting the dreaded "#50070: Unable to connect to the database." error in the system log of the Sharepoint server for the Sharepoint Timing service. Lots of people get this error, and it's frequently related to connectivity issues. I dug through a lot of the options presented on EventID.Net and none seemed to match my situation.

Eventually I started checked the user permissions on the SQL server, and realized I couldn't browse the network. WTH! The Sharepoint server could see the network (remember this is my sandbox that really only has 3 machines). Then a big lightbulb came on when I realized I had not joined the SQL server to the sandbox network! I had created it from scratch, installed SQL server, restored my database backup, but never did I join it to the domain so all the Sharepoint services did not work, nor was I able to connect (got another error there).

So, if you ever find yourself in this situation, make sure the darn SQL Server is in the domain! :-)