Setting up a DCOM connection for WMI (Windows Management Instrumentation) on host machines (4295692)

Setting up a DCOM connection for WMI (Windows Management Instrumentation) on host machines

How can a DCOM connection for WMI access be set up on target hosts?

What are the minimum requirements for Windows WMI OS monitoring in situations to avoid using the local Administrators group?

Why does a Windows credential fail with the error message, "Access is denied (0x80070005) while connecting as DOMAIN/USERNAME.  Ensure that the the remote machine has been prepared to accept incoming DCOM connections and that the username/domain/password are correct"?

WMI resides on the top of DCOM. In order for the agent OS user to have access to the WMI for questioning the OS and DB system metrics, it needs permissions to be set on DCOM first. By default, the local user in the local admin group of the monitored host has the required permissions for both DCOM and WMI components. When the OS user used by the agent is not a member of the monitored host local admin group, it will require adjusting the permissions on both DCOM and WMI components.

The most common case related to this is when using a remote user that exists in the Active Directory. This user is not a member of any of the local groups in the monitored host and will require special attention when it comes to configuration Windows accordingly.

WMI uses a standard Windows security descriptor to control access to WMI namespaces. When connecting to WMI, it connects to a specific namespace. These current namespaces and sub-namespaces must have the CIMV2 security enabled and remote enabled for the account to access the system through WMI.

The following two namespaces are used for monitoring:

• ROOT\CIMV2
• ROOT\MSClUSTER

WinRM is the preferred connection mechanism for monitoring Windows servers.

IMPORTANT:  A single Linux Foglight Agent Manager can handle up to 75 Windows agents (either SQL Server agent or Infrastructure agents) using WMI.
As a result, the number of Linux Foglight Agent Managers (FglAMs) is determined by the number of Windows agents pided by 75; for example, monitoring 300 Windows agents requires at least four (4) Linux Foglight Agent Managers.

This limitation does not apply to Windows Agent Managers. Quest R&D has successfully tested up to 2000 agents using WMI (i.e. 1000 database agents + 1000 WindowsAgents) using a single Windows Agent Manager.
If you are monitoring more than 75 agents using on a Linux FglAM, the monitored hosts should be configured to use WinRM.
Please consult the latest version of the Foglight Agent Manager User Guide for more details on configured WMI and WinRM to monitor Windows hosts.

Windows registry changes are often necessary on the monitored Windows server for WMI connections from Linux-based FglAMs to be successful.

Setting up WMI connections

In order for the agent to have access to query WMI to collect OS and database metrics, the agent must have permission to access both DCOM and WMI.

The SQL Server cartridge installer (DBSS - Installer) and database agents both require Local Administrator access through DCOM/WMI to query Windows Services to create SQL Server agents and run the OS usability connection. Consult the Foglight for Infrastructure cartridge guide "Advanced system configuration for WinRM" section for instructions on an alternative configuration using WinRM.

Note: Enhancement ID FOG-2006 has been added to use non-Administrator accounts for Windows OS monitoring using database cartridges beginning in the 6.3.0.10 and higher SQL Server cartridges.

 

A. PREREQUISITE: Verify that the Remote Registry, Server, and the Windows Management Instrumentation services are running

1. Click Start

2. Click Run

3. Type services.msc and press "Enter". This will open the Services window

4. Scroll down to the Remote Registry service. Verify that the server is started and is set to Automatic.
   
   

If the Remote registry service is off, you will see either of the following two errors:

Access is denied

or

Message not found for errorCode: 0xC0000034

By default even if the Remote Registry service is started Windows 7 and above systems will deny remote access to the registry.

1. Scroll down to the Server service. Verify that the service is started and set to Automatic.
   
   

2. Scroll down to the Windows Management Instrumentation service. Verify that the service is started and set to Automatic.

The best practice is to use a Local Administrator account on the monitored host as the agent OS user. 

Where this is not possible, use the procedures to grant permissions for a remote user, even if this account is a member of the Domain Administrator group.

• All windows workstations must have the same local user name and password
• If on a workgroup, the workgroup name and a backslash must be included before the username (e.g. WORKGROUP/User)
• Local user account on the target computer must have explicit DCOM and WMI namespace access rights granted specifically for emote connections
• Local security policies must be enabled for  "Classic - local users authenticate as themselves

 

B. Grant the minimum WMI permissions to the remote user:

This limits users other than those configured from remotely accessing WMI. 

If the named Windows account does not have all of these permissions, you might see one of the following errors

Access is denied
or
Error=800706BA The RPC server is unavailable. SWbemLocator
or 
Error=80070005 Access is denied SWbemLocator 

1. On the monitored host machine, right-click on My Computer, and navigate to Manage | Services and Applications | WMI Control.
   
   

2. Right-click WMI Control and click Properties.

3. In the WMI Control Properties dialog box, click the Security tab. 

4. Expand the Root node and select CIMV2, then click Security. 
   
   

5. In the Security for ROOT\CIMV2 dialog box, add the Distributed COM Users group.

6. Grant the required permissions to the remote user by enabling the following check boxes in the Allow column: 

   1. Execute Methods

   2. Enable Account

   3. Remote Enable

   4. Read Security
      
      
      

7. Click Apply and then click OK.

 

C. To grant DCOM permissions to a remote user

When making users the administrators of their local machines is not possible, you can grant required permissions to individual remote users using the following procedures.

To grant DCOM permissions to a user in Windows:

Add the local user to the "Distributed COM Users" group and the "Performance Monitor Users" group.

If the Agent Manager is installed on a Unix or Linux machine:

1. On the monitored host machine, at the Windows Run prompt, type DCOMCNFG and press Enter.

2. In the Component Services dialog box that opens, navigate to Component Services | Computers | My Computer.

3. Right-click My Computer and click Properties.

4. In the My Computer Properties dialog box, click the COM Security tab.

5. Under Access Permissions, click Edit Defaults.

6. In the Access Permission dialog box that appears, add the Distributed COM Users group to the list and grant it all permissions.
7. Click OK to save your changes and close the Access Permission dialog box.
8. In the Launch and Activation Permissions area, click Edit Defaults.
9. In the Launch and Activation Permissions dialog box that appears, add the Distributed COM Users group to the list and grant it all permissions
10. Click OK to save your changes and close the Launch and Activation Permissions dialog box.
11. In the My Computer Properties dialog box, click OK to close it.
12. Close the Component Services window.
13. Click OK and close the dialog boxes.

 

D. Enable Classic Security policies for Windows Systems that are not part of a domain

1. Open the Control panel, and go to Administrative Tools | Local Security Policy.

2. The  Local Security Settings window appears.
   
   

3. Go to Local Policies | Security Options.

4. Change the value of "Network access: Sharing and security model for local accounts." to Classic.
   
   

 

E. Open the Windows firewall for WMI traffic 

Enter the following in the command prompt:

netsh advfirewall firewall set rule group=”windows management instrumentation (wmi)” new enable=yes

WMI uses RPC which listens on port 135 but then allocates a dynamic port for further communications. A rule must be configured on the Firewall to always allow the TCP port 135 and either the dynamic or static RPC ports. Please refer to KB 114559 for details on configuring Windows to use static port for WMI.

If there is a problem with the firewall on port 135 then this error may occur:

ERROR: Message not found for errorCode: 0xC0000001

 

F. Grant permissions to the Windows Registry

Please refer to KB 4229811 for details on granting specific permissions to the Windows Registry for WMI monitoring

 

G. Monitoring a host that is not in a domain

The following steps will disable the remote UAC for a workgroup member computer. This disables the remove UAC and does not disable local UAC functionality.

1. Logon the host using an Administrator account

2. Open the registry editor (regedit)

3. Expand the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

4. Locate or create a DWORD entry named LocalAccountTokenFilterPolicy and provide a DWORD value of 1.
   Change this value back to 0 to re-enable remote UAC
    

H. Appendix: Turn off the UAC if the above still doesn't help...

In some cases, such as when monitoring a host that is in a workgroup and is not a domain member, modifying the Registry as described above doesn't help. In such a case, disabling User Account Control (UAC) can solve the issue or at least point to Windows permissions issue which should be checked on the Windows platform itself. In order to disable UAC (from Microsoft):

1. Click Start, and then click Control Panel.

2. In Control Panel, click User Accounts.

3. In the User Accounts window, click User Accounts.

4. In the User Accounts tasks window, click Turn User Account Control on or off.

5. If UAC is currently configured in Admin Approval Mode, the User Account Control message appears. Click Continue.

6. Clear the Use User Account Control (UAC) to help protect your computer check box, and then click OK.

7. Click Restart Now to apply the change right away, or click Restart Later and close the User Accounts tasks window.

 

 

The full control for these registry keys are required since Foglight needs to write values to them according to COM specification. Below are values we write for each key: * HKEY_CLASSES_ROOT\AppID\{key}: Need to write the DllSurrogate string value * HKEY_CLASSES_ROOT\CLSID\{key}: Need to write the AppID string value whose data is the key value. Providing the full control permissions to FglAM user is the easiest(automatic) way for writing these values. However, if the user doesn’t want to provide the full control permissions to FglAM user, then the user needs to add those values to those keys manually. Here is an article(http://j-interop.org/faq.html#A6) which has a detailed explanation on how to configure DCOM connection. Though it's a doc from J-Interop(the third-party lib we use for DCOM connection), it has well explained why we need to write those values and the ways on how to write them.