Access denied errors when connecting to the Remote Server

Redgate Monitor reports connection errors such as "Monitoring Stopped" and Show log reveals "incorrect credentials or "insufficient permissions and "access is denied" error messages. Often encountered when testing a connection to a new monitored server. It indicates insufficient permissions assigned to the account being used to connect to the monitored server. You will see 0x80070005 E_ACCESS_DENIED for DCOM-level permissions, or 0x80041003 WBEM_E_ACCESS_DENIED, for WMI permissions.

NOTE: These problems are Windows DCOM or WMI connection errors, not Redgate Monitor errors. You will be able to reproduce the error by running connection tests externally to Redgate Monitor, using wbemtest or PowerShell. The guidance that follows summarizes our previous experiences with these problems, typical underlying causes, and possible resolutions that have worked for other customers. Beyond this, Redgate cannot provide further support for these environmental issues. Once you fix the external problem, the connection error will be resolved in Redgate Monitor.

0x80070005 E_ACCESS_DENIED – Access is denied

You will see the 0x80070005 error reported in the Redgate Monitor logs (Configuration - Diagnostics - Retrieve log files) using the affected server name as reference. You will also be able to reproduce the same error independently of Redgate Monitor (see Reproducing the error externally to Redgate Monitor at the end of the article).

The following screenshot shows the error, as reported by wbemtest:

The Facility: Win32 indicates this is a DCOM-level security problem. The user account being used to connect to the remote server does not have DCOM permissions to access the remote machine using WMI.

What is reported for OpenNamespace: indicates the operating context of the request. For example, OpenNamespace:Root indicates the problem occurred at the root WMI namespace level meaning that the account used by the Redgate Monitor to access the remote entity did not have DCOM permissions required to connect to the root namespace on the target entity.

0x80041003 WBEM_E_ACCESS_DENIED – Access Denied

You will see the 0x80041003 error reported in the Redgate Monitor logs (Configuration - Diagnostics - Retrieve log files) using the affected server name as reference. You will also be able to reproduce the same error independently of Redgate Monitor (see Reproducing the error externally to Redgate Monitor at the end of the article).

The following screenshot shows the 0x80041003error as reported by wbemtest:

The Facility: WMI indicates this is a WMI-level security problem; the user account does not have the WMI permissions required to access the specified WMI namespace.

Possible resolutions

Redgate Monitor connects to remote Windows machines and SQL Server instances using WMI, either over DCOM or WinRM. Therefore, the account that the base monitor service uses to make this connection needs permission both to access the remote computer over DCOM (or WinRM) and to access WMI classes on the remote machine and run WMI queries, so that Redgate Monitor can collect monitoring data.

If the account does not have DCOM or WMI permissions, then you will see "access is denied" errors. When monitoring a cluster, you may find the account has access rights and permissions for an individual node in the cluster, but not to the cluster name.

The following checks and actions have helped other customers resolve these problems but may not be the correct solution in your case. Please share the following suggestions with your own system administration team, along with the detailed error messages and WBEMtest results, and act on their advice.

1. Check permissions assigned to "non-admin" accounts

'Access denied' errors for remote connections are especially common if the user account making the connection cannot be a member of the Administrators group on the remote machine. In such cases, you'll need to manually assign to it the 'minimum necessary' DCOM and WMI permissions required to connect remotely to the machine you wish to monitor and access the required WMI classes. If any of these are missing, you will see 'access denied' errors.

The full set of permissions are listed here: Monitoring host Windows machines without admin permissions.

1. If you are seeing the 0x80070005 error, then you need to set DCOM Remote Launch, Remote Activation and Remote Access for Anonymous Login permissions for the account, on the target machine. For information on how to assign these permissions, see: Securing a Remote WMI Connection.
2. If you are seeing the 0x80041003 error, then you need to set the required WMI permissions, as also shown in Securing a Remote WMI Connection.
   1. Establish Remote Enable and Enable Account permissions for the WMI namespaces CIMV2, Root and MSCluster (if relevant).
   2. Ensure that the account is a member of the Performance Monitor Users group on the target machine and so has permission to access the WMI performance counters.

3. If the connection to the remote server works but you are not seeing the SQL instance you expect to see, the account being used to connect to the remoter server may not have the required permissions to access the SQL Server instances in its Access Control List (ACL). Assigning the required permissions is described in steps 5-7 of Monitoring host Windows machines without admin permissions.
   1. In step 7, change the service name to the service name of the SQL instance service that isn't showing up (to get the service name, Start > Run > Services.msc and then review the properties for the SQL Server service).

4. If you cannot access a cluster name, or you connect to a node and it does not recognize it is part of a Windows Server Failover Cluster (WSFC), you may need to grant that the user account access to the WSFC, which it needs to identify and monitor cluster resources. This is covered in step 8 of Monitoring host Windows machines without admin permissions. On the monitored machine, run the following PowerShell as an administrator, substituting in the account you are using for monitoring:

Import-Module FailoverClusters
Grant-ClusterAccess -User <accountname> -Full

2. Check for UAC filtering

These errors can occur if the account is a local admin on the remote machine, and you have UAC filtering for local accounts enabled. The local admin account is designed for local users. When being using for remote connections, UAC will reduce the privileges of local admin accts unless a registry value is set. See: User Account Control and WMI.

If the tests outlined in the section below called Reproducing the error externally to Redgate Monitor work when run on the local machine but fail when connecting from the base monitor to the remote server, then it may be a UAC problem.

1. Check if the UAC is enabled. There are several ways to do it. This page shows how to do it from the command prompt (and so also gives you the registry key you can check using regedit, if you prefer): https://superuser.com/questions/192216/uac-status-from-command-line.
2. If the UAC is enabled on the remote machine, then you will need to set the LocalAccountTokenFilterPolicy registry value as described here: https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction.

Reproducing the error externally to Redgate Monitor

To reproduce the exact error externally, use the WBEMTest tool. You can also re-run these tests after making any of the permissions adjustments described above. If they succeed, the problem will be resolved in Redgate Monitor.

Follow the steps described in the documentation for The wbemtest tool is for DCOM connections only. The PowerShell tests on the same page will work over DCOM or WinRM.

• In Step 5 of Testing a WMI Connection using WBEMTest, you enter the namespace. What you enter will depend on the namespace reported in the error.
  • If you are monitoring a WSFC then you will also need to test the connection to the cluster name (\\myserver.example.com\root\mscluster) because Redgate Monitor uses it to discover the cluster nodes and SQL instance names (as well as testing the connection for individual nodes using \\myserver.example.com\root\cimv2).
• In Step 6, make sure that the packet privacy is enabled under Authentication level.
• In Step 7, you run the query that will test access permissions for that namespace, on the remote machine. Again, the query you run depends on the error. For example:
  
  • If you see the DCOM error (0x80070005) error against "root", when connecting to a cluster, you can test access to the MSCluster namespace using:
    

    SELECT Name FROM __Namespace.

• • If you see the WMI error (0x80041003) for the cluster name or can connect to the cluster name but not a node, you can query the MSCluster_Cluster or MSCluster_ClusterToNode classes, respectively.
  • You can test access to the all the SQL Server instances using the query:
    

    SELECT * FROM MSCluster_Resource WHERE Type = 'SQL Server'