This is a problem we just solved, which was causing us to not be able to hit the remote registry via the virtual server name for a clustered SQL Server. You may wonder why that's important. Well, if you want to make sure you're monitoring the right server from remote, you want to use the virtual name because it could be on any particular physical node. One of our monitoring tools wasn't working at all. It connects via the registry to get performance counters and the like. Everything had been working, up until about 3 weeks ago.

In troubleshooting, the first think you look at is what changed. Two things had changed that we could account for: Microsoft security patches had been applied and all the SQL Server 2005 instances had been removed (SQL Server 2008 was also installed). We had other clustered SQL Servers in a similar configuration that weren't exhibiting the issue and they had been patched at the same time so it likely wasn't the patches. So that meant it was likely the uninstalls of SQL Server 2005, but a lot happens during an uninstall, so exactly what change did it was unclear. So here were the symptoms:

• You could hit the registry remotely using the physical server name.
• You could hit the registry remotely using the IP address.
• You could hit the file share using the virtual server name (such as the administrative shares for the drives).
• You could run nbtstat -a <virtual name> and that worked.
• You couldn't connect to the registry remotely using the virtual server name if it was a SQL Server virtual server.
• You could connect to the registry remotely using the virtual server name if it was the cluster name or the MS DTC NetBIOS name.

Our server guys found a blog post that seemed to steer us in the right direction. Basically, the NoRemapPipes key was missing from HKLM\Control\CurrentControlSet\Services\LanmanServer\Parameters. It should be present and it should have three values: winreg svcctl eventlog. When I saw the values, I quickly tested connecting to the event log. No go. So this gave us more symptoms:

• You could hit the event log using the physical server name.
• You could hit the event log using the IP address.
• You could't hit the event log using the virtual server anme if it was a SQL Server virtual server.

Since the server admins wanted to go ahead and make the change, I didn't test coming through the Service Control Manager, but I assume it, too, would have failed. They made the change and we were immediately able to connect. Our thoughts are that when the last SQL Server 2005 instance was uninstalled, it took this key with it. Of course, you wouldn't expect SQL Server 2005 to be aware of SQL Server 2008 instances on the servers, and this is what likely is why we had issues.