Troubleshooting Remote Registry Read Problems During Environment Discoveries And Refreshes (KBA1552)

Remote Registry service 

On the remote host, there is a Remote Registry service to check. You can start the Windows Services list GUI with the command Services.msc, or you can click the Services icon from the Administrative Tools group icon from Control Panel:

- The third column is startup type - make sure it is set to automatic. It's a "Trigger Start" so don't worry if not running, it'll start again when a query is made remotely to the registry. However, you can start it for the purposes of testing. If Disabled or set to Manual and not in started state, please start to test.

Registry permissions 

If the windows service isn't the issue make sure the permissions on the windows host registry itself are adequate for reading by the Delphix OS (operating system) user designated for the Source environment discovery. You can check this by opening the regedit.exe utility on the remote windows host (source host), and under the Edit menu open Permissions. The Delphix OS user must have at least Read permissions for them to query (read) the registry.

- You can easily test remote read access from the DelphixConnector host, as the Delphix OS user for the source host, by opening regedit.exe, select from the menu File and select Connect Network Registry... and enter the name of the source host for the connection.

- If read access is available you'll be able to successfully navigate the registry keys. If not, you'll need administrative assistance to grant the necessary Read permissions to the user for this access.

Network connectivity 

If the service and permissions aren't the issue, then you need to start troubleshooting the port 445, which provides inbound access to the remote registry service on the remote host. You'll want to run some generic Powershell commands in order to test remote registry access from the DelphixConnector host. 

I recommend running these Powershell commands from powershell console or ISE:

- To test the ability to check port 445 is open on the target side from Windows host running DelphixConnector use this powershell command. Please note, if the remote host is a cluster, use the cluster address to test (the hostname/ip address used in the environment discovery):

PS C:\windows\system32> New-Object System.Net.Sockets.TcpClient("RemoteHost.com", "445")
New-Object : Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, 
or established connection failed because connected host has failed to respond 10.100.30.100:445"
At line:1 char:1
+ New-Object System.Net.Sockets.TcpClient("RemoteHost.com", "445")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo     : InvalidOperation: (:) [New-Object], MethodInvocationException
  + FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand

In this case, port 445 is unreachable from this windows host

- For general host access (yes, sometimes this can be the issue, especially in cluster setups), use this command to check that the host itself is reachable if you haven't already tested using nslookup or other commands. This powershell command is typically used by our current Delphix installations:

PS C:\windows\system32> [system.net.dns]::GetHostEntry("RemoteHost.com")

HostName             Aliases       AddressList                      
--------             -------       -----------                      
RemoteHost.com   {}         {10.100.30.100}                    

You can run this and previous command from connector host to the remote host and in the case clusters are involved against the individual cluster nodes and also cluster address to pinpoint and isolate where problem occurs.

- You can also run this command to test remote registry access as it is called from our powershell scripts:

[Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("LocalMachine", "RemoteHost.com")
SubKeyCount : 7
View    : Default
Handle   : Microsoft.Win32.SafeHandles.SafeRegistryHandle
ValueCount : 0
Name    : HKEY_LOCAL_MACHINE

An error presents itself similar to how we see it from the cluster discovery.

Keep in mind testing using OpenRemoteBaseKey is more for user access to the registry, whereas the TcpClient class is testing access to the remote system's listener port 445, which among other things provides access to remote registry reading. But, OpenRemoteBaseKey can fail for network reasons - when calling it in powershell, if the issue is network related (hostname has no access to the registry), the error will throw after about one minute. If it is a permission issue local on the machine, the error is throw almost immediately.

Membership of Backup Operators group 

Some failures will present a "requested registry access is not allowed" error, instead of the "network path was not found" error described above:

Exception calling "OpenSubKey" with "1" argument(s): "Requested registry access is not allowed."
At C:\Program Files\Delphix\DelphixConnector\564de705-c619-fbf4-6c5c-c1f815f5e816-staging-1352\SCRIPT\GetInstancePort.ps1:97 char:1
+ $sqlServerKey = $rootkey.OpenSubKey("SOFTWARE\Microsoft\Microsoft SQL Server")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo     : NotSpecified: (:) [], MethodInvocationException
  + FullyQualifiedErrorId : SecurityException

This suggests that the configured Environment User for this Environment is not a member of the Windows "Backup Operators" group. On Windows Clusters, this group membership should be configured on every Cluster node.

Resolution 

There are various resolutions based on the nature of the problem which are mostly environment related: