I think I figured out how I blew up my SharePoint on my test box a couple weeks ago.  I mentioned in my previous post that I blew up SharePoint while testing an upgrade scenario.  Of course, being a typical tech working on a test box, I was guilty of changing too many things at once – including changing the SharePoint config and applying patches.  I know, I know – whip me, beat me, and send me to my room . . .

I’m doing a little server consolidation here getting ready to move our servers in to a data center.  So I did a clean install of Windows Server 2003 R2 on what is destined to be my new web server.  I proceeded to get SharePoint, SQL, and all of my other stuff installed, then updated the box via Microsoft Update.  About 50 updates (including Win2k3 SP2 – yes, I am a glutton for punishment) and a few reboots later, the server was fully patched and humming right along.  I opened SharePoint 3.0 Central Administration and after a few seconds was presented with a nice 404 Page Not Found error.

WTF?

I verified my services were running, then went to check out the Event Viewer.  In the Application Event Logs, I saw a slew of SharePoint errors with Event ID 5586 with details about being unable to connect to the database.  Looking up this error on EventID.net, there wasn’t much there – and I wasn’t particularly keen on running psconfig -cmd upgrade -force and then uninstalling / reinstalling SharePoint.

Googling on “SharePoint event id 5586″ wasn’t very helpful either.  I encountered a number of threads that all referenced the hotfix from KB 932091 not installing correctly, and recommending extracting the update and manually running it again.  I had tried this a couple weeks ago on my test box to no avail, and found several others in the threads that this didn’t work for.  Just to be safe, I tried it again on this box, but it still didn’t work.

One difference with this server is that I am actually running full SQL 2005 (instead of SSEE on the test box), so I could access my database via the SQL Management Studio.  When I opened the Management Studio and attempted to connect to my database instance, after a long pause the Management Studio threw an error that it wasn’t able to connect to the database instance – I discovered I received the error whether I was trying to connect via Windows or SQL Authentication, which was an interesting tidbit of information I hadn’t found when troubleshooting the issue on the test box with SSEE.

On a whim, I decided to check the SQL Client Configuration – since I remembered seeing something similar in the past with Microsoft Retail Management System when it couldn’t connect to the database.  I went to Start | Run and   cliconfg  

This is what your cliconfg should show:

 

This is what cliconfg showed on this server:

 

I enabled TCP/IP and Named Pipes, then selected “Enable shared memory protocol.”  After clicking OK and rebooting – Voila!  SharePoint is back in business and SQL Management Studio can connect to my database instance via both Windows and SQL Authentication.

I’m not sure which update broke this, but considering in the course of 3 reboots I MU’d approximately 50 updates (including SQL2k5 SP1, 932091, and Win2k3 SP2) – it’s hard to know exactly what disabled my SQL client protocols.  But it was an easy fix, and it’s working now – so I’m happy  smile_regular