A really weird situation happened yesterday at work.
We wanted to move the Virtual Machine that serves as a SQL Server for our development SharePoint environment, from one host computer to another host computer. No renaming, no changes…it should have been really transparent to SharePoint.
Well, it wasn’t.
Once we moved and restarted the server, the SharePoint refused to work. We were starting to dig within the log files and we found out that the front-end was trying to contact a fixed IP address as a SQL Server. This was the old IP address of the database server virtual machine before it was moved. We scanned the Registry for references to this IP address but none was found.
We even made a brand-new virtual machine with SharePoint 2007 and tried to connect it to the SQL Server. It did, but the dreaded error connecting the old IP address persisted. So, we deduced that the culprit IP was stored somewhere in SharePoint databases.
The solution to this problem was simple, once we found out what it was. The network card on the database server was set to multicast IP with the old IP address as a “second identity” for the card. In this way, SharePoint could connect itself to the databases using the bad IP address.
Once we got into Central Administration, we removed the server that showed as bad IP address in Server Topology page. Furthermore, we did a STSADM –o renameserver to change the references from the old IP-address name to fully-qualified domain name of the server. Bravely, we removed the alternate IP from the database server NIC card settings and did an IISRESET on the SharePoint side.
Worked as a charm. Two days lost fixing this, though :-(
In this case, cut the right hand of the SharePoint administrator who first added the reference to the database server by IP address alone. (Just kidding, of course).