[edit: I forgot to save after updating the post with the relevant registry path. Apologies.]

Last weekend I was tasked with installing a cumulative update on two SharePoint servers and then joining them to two different farms. Pretty basic stuff, except for one thing: the servers were configured to be connected to two older farms, but the old farms were no longer online. On the first server everything went smoothly: I disconnected the server, installed the cumulative updates and then connected it to the new farm.

On the second server, things were less pretty. The PSConfig GUI got stuck in the first step. Running PSConfig on the command line simply hanged.

I took a peek at the PSDiagnostics log file in the LOGS directory of the 12 hive, and the last message was “Calling SPFarm.Local and SPServer.Local to get the local farm objects”. It seemed that the problem was trying to determine the state of the current farm — but that didn’t seem a necessary step, after all, I was trying to disconnect from the farm. So I fired up Reflector to see what SPFarm.Local actually does, and traced the problem: it was trying to connect to a database server that was no longer there.

After figuring out where the connection string was located (the exact path is “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDb” and the relevant key is “dsn”), I was tempted to change it to point directly to the new server, but then I took a closer look at it. It was a standard SQL Server connection string, but the timeout value was set to 0. I changed the value to 10 and ran PSConfig -cmd configdb -disconnect. After ten nervous seconds of waiting, PSConfig began to show signs of progress, and lo and behold, the server was disconnected from the old farm.

Lesson learned: if you’re planning to re-use a server, disconnect it from the farm before taking the rest of the farm offline.

Popularity: 3% [?]