Configuring Windows Management Instrumentation (WMI)

To remotely monitor a Windows machine, some Foglight agents require access to the WMI services, and specifically to the WMIConnectionService. This section outlines potential issues that may be encountered by agents attempting to access WMI, and provides solutions or workarounds.

In order to access WMI, the user that the monitoring agent connects as must have sufficient credentials. Any user included in the Administrator group on the monitored machine already has the required access levels. For more information, see Minimum requirements for Windows Management Instrumentation. There are several OS and environment-specific issues that may arise when using a Foglight agent to monitor a Windows machine remotely. This section provides solutions for the following issues:

WMI IPv6 connection support

Starting with the Foglight Agent Manager version 5.9.1, the WMI connection with unique local IPv6 Address and link-local IPv6 Address is supported on the Agent Manager running on Windows, Linux, and Solaris.

Windows Firewall interference

Since the agent connects remotely (that is, from an external source) the Windows Firewall can interfere with operations. In such cases, it is recommended that you initially try disabling the firewall to determine if that allows the agent to connect. When the agent can connect with the firewall disabled, re-enable it and open the following ports:

  • TCP Port 135 (DCE/RPC Locator service, WindowsShellService, WMIConnectionService)
  • TCP Port 139 (NetBIOS Session Service)
  • TCP Port 445 (Windows shares)
  • “Dynamic RPC” local ports

Minimum requirements for Windows Management Instrumentation

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. By default, any user in the Local Administrators group on the monitored host has the required permissions. Therefore, the best practice is to use a Local Administrator account on the monitored host as the agent OS user.

Promoting remote users to administrators on local machines through the Domain Controller

The recommended way of making users the administrators of their local machines is through Active Directory on the domain controller. Using the Domain Controller, you can:

  • Set up local administrators for specific machines in the domain
  • Promote local users to administrators for specific machines in the domain
  • Make domain users administrators of all machines in the domain by adding them to the Domain Admins group
  • Make domain users administrators of specific machines in the domain by adding them to the Domain Admins group

To promote a user to an administrator on a local machine using the Domain Controller:

  1. Select Control Panel > Administrative Tools > Active Directory Users and Computers.
  2. In the Active Directory Users and Computers window that appears, in the left pane, under the domain node, click Computers.
  3. In the right pane, right-click the machine whose local user you want to promote to an administrator, and select Manage.
  4. In the Computer Management window that appears, select System Tools > Local Users and Groups.
  5. You can now do any of the following:
    • Using the Users node in the right pane, make an existing or a new user an Administrator.
    • Using the Groups node, add an existing user to the Administrators group.

Granting required permissions to individual remote users

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:

  1. Add the local user to the “Distributed COM Users” group and the “Performance Monitor Users” group.
  2. If the Agent Manager is installed on a UNIX machine:
    a. On the monitored host machine, at the Windows Run prompt, type DCOMCNFG and press Enter.
    b. In the Component Services window that appears, navigate to Component Services > Computers > My Computer.
    c. Right-click My Computer and click Properties.
    d. In the My Computer Properties dialog box that appears, open the COM Security tab.
    e. In the Access Permissions area, click Edit Defaults.
    f. In the Access Permission dialog box that appears, add the Distributed COM Users group to the list and grant it all permissions.
    g. Click OK to save your changes and close the Access Permission dialog box.
    h. In the Launch and Activation Permissions area, click Edit Defaults.
    i. In the Launch and Activation Permissions dialog box that appears, add the Distributed COM Users group to the list and grant it all permissions.
    j. Click OK to save your changes and close the Launch and Activation Permissions dialog box.
    k. In the My Computer Properties dialog box, click OK to close it.
    l. Close the Component Services window.

To grant minimum WMI permissions to a remote user:

  1. On the monitored host machine, right-click 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, open 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:
    • Execute Methods
    • Enable Account
    • Remote Enable
    • Read Security
  7. Click Apply and then click OK.

To add subsequent users, they only need to be added to the two groups, Distributed COM Users and Performance Monitor Users, since these groups are already granted the required permissions.

Even though the local user is now granted access to WMI with the above configuration, not all performance monitoring classes allow non-administrative users to access their instances. Some performance classes need special permission to enable non-administrative users to perform queries or execute methods on their object instances. Some of these queries can fail clearly with an error code (for example, by the Agent Manager service throwing a Java exception), but some of them can fail without returning any data or error codes. Therefore, this setup must be used carefully, as query results can be unpredictable. From the system security perspective, there is still only so much a non-administrative user can do.

Tuning WMI connections

The following parameters can be used to fine tune the Windows Management Instrumentation (WMI) connections made by Foglight agents. You can set these parameters for Foglight Agent Manager either in the baseline.jvmargs.config file as vmparameter options, or specify them directly as jvm options when starting up Foglight Agent Manager via command line. The values used for these parameters vary from environment to environment and so should be used as reference only.

  • Max Active Connections: Defines the number of simultaneous outbound connections that can be made by all agents running on a particular instance of Foglight Agent Manager. The default value is 100.
    Sample: -Dcom.quest.connection.regulator.maxActiveConnectionsCap=500
  • Expire connection based on no. of executions: Defines the number of executions that can be made by a connection before forcibly closing it. The default value is 50.
    Sample: -Dquest.debug.poolable.wmi.time.to.live.executions=200
  • Timeout by elapsed time: Defines the time (in milliseconds) after which a connection is expired. The default value is 600000 (10 mins). Sample: -Dquest.debug.poolable.wmi.time.to.live.timeout.millis=900000

Enabling agents to connect from UNIX machines

When an agent connects to a monitored Windows host from a UNIX machine, you must make certain registry changes in order to allow the required COM services to run.

To add the following registry key:

  1. Click Start > Run.
  2. Input regedit in the dialog box and click OK.
  3. Add the following registry key to Windows if it does not exist: HKEY_CLASSES_ROOT\AppID{76A64158- CB41-11D1-8B02-00600806D9B6}. Create a new string value named DllSurrogate under that key and leave it blank.
  4. Add the following registry key to Windows if it does not exist: HKEY_CLASSES_ROOT\CLSID{76A64158- CB41-11D1-8B02-00600806D9B6}. Create a new string value named AppID under that key and modify the data to: {76A64158-CB41-11D1-8B02-00600806D9B6}

To allow the agent to connect from a UNIX machine to a monitored Windows host:

  1. Enable the Remote Registry Service. Once the agent has successfully connected from a UNIX machine and the Agent Manager connection services have made the required changes, the Remote Registry Service can be disabled.
  2. Ensure that the Server service is running.

    Normally the Server service starts automatically. If it is stopped, or fails to start, it must be manually restarted before the Agent Manager can connect from a UNIX machine.

Disabling UAC

When an agent connects to a monitored Windows host from a UNIX machine, user access control (UAC) must also be disabled in order for WMI connections to succeed. This requirement affects: Windows Vista, Windows Server 2008, and Windows 7.

To turn off UAC on Windows 7:

  • Navigate to Control Panel > User Accounts and Family Safety > User Accounts > Change User Account Control Settings, and change the setting to Never Notify.

Granting access to dllhost.exe when Windows Firewall is enabled

When an agent connects to a monitored Windows host from a UNIX machine, and the Windows firewall is enabled, access to dllhost.exe must be allowed through the firewall.

To grant access to dllhost.exe:

  1. Issue the following command on the command-line of the monitored Windows host: netsh firewall add allowedprogram program=%windir%\system32\dllhost.exe name=Dllhost
  2. Ensure that Windows UAC is disabled. Refer to Disabling UAC for details.
  3. Restart the monitored host.

Enabling agents to connect locally on Windows

When a WMI agent connects to the same machine it is running on (that is, localhost) using credentials that explicitly specify a user other than the currently logged on user, you must make certain registry changes to allow the required COM services to run.

To allow the agent to connect locally on Windows:

  1. Enable the Remote Registry Service. Once the agent has successfully connected and the Agent Manager connection services have made the required changes, the Remote Registry Service can be disabled.
  2. Ensure that the Server service is running.

    Normally, the Server service starts automatically. If it is stopped, or fails to start, it must be manually restarted before the Agent Manager can connect locally using credentials for a user other than the currently logged on user.