Printed 2017/07/21 09:30PM

Can't Hit the Remote Registry through the Virtual Name


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:

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:

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.

Copyright © 2002-2017 Redgate. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.