Monitoring Microsoft Servers with WMI

As mentioned in my inaugural post, one of the challenges faced by Cloud Services Providers and their customers is that business critical applications and the tools used to monitor them have been designed with a single, homogenous,  Enterprise in mind. This reliance on a single authentication domain creates challenges when determining architecture for off-premises deployments. This issue is best highlighted by the difficulty in using WMI to monitor Servers from external domains.

An Introduction to WMI

First, some background. Windows Management Instrumentation (WMI) is a collection of extensions through which system information is exposed and can be used for monitoring and notifications.  Many monitoring tools leverage WMI to provide critical server performance and health information. In Windows Server 2003/2008 (inc. R2) WMI can be managed using the WMI Control Panel ( Start > Run > wmimgmt.msc). WMI is queried for data in much the same way as a SQL Database.  Typically, the account used to connect to WMI must be a Local Administrator on the target server.

Additionally, the following ports must be open:

• tcp 445 (SMB, RPC/NP for Performance Counter Access)
• tcp 135 (RPC)
  -and- one of these ranges:
• tcp 49152-65535 (RPC dynamic ports — Win2008 and Vista)
  -or-
  tcp 1024-65535 (RPC dynamic ports — NT4, Win2000, Win2003)
  -or-
  a custom RPC dynamic port range (http://support.microsoft.com/kb/154596?wa=wsignin1.0)

To test a connection to WMI, open WMIMGMT on an external Windows Computer (Start > Run > wmimgmt.msc), right-click WMI Control (Local) > Connect to another computer… Add the name or IP of your target server and click OK. Once connected, right-click the server name and select Properties. You should see a successful connection with no error codes. Note that this connection will use the account credentials of the logged in user. Other tools (WBEMTEST) can be used to enter alternate credentials.

An in-depth dissertation on WMI is out of the scope of this post, but if you are interested you should read more on Technet (http://technet.microsoft.com/en-us/library/cc753534.aspx).

WMI and User Account Control (UAC)

The introdution of User Account Control (UAC) fundamentally changed the ability to connect to WMI on domain servers from an external source. By default, UAC token filtering treats local Administrator connections as Users (non-admin). This change results RPC and Access Denied Errors (note that many WMI/DCOM status codes may be misleading, RPC Server Unavailable may be retured for permissions issues).

This change presents challenges for monitoring given that the religion for years has been to favor agentless monitoring over agent-based tools. To use agentless monitoring tools, it has become common to define a service account on the monitoring system and a local administrator on the target with identical credentials. This method now requires extra steps in order to allow connectivity to WMI.

Connecting to WMI From Remotely

If you are attempting to connect to as Windows Server 2008 (or later) instance via WMI from an external source, the following options will allow connectivity (each of these options carry their own risks, please educate yourself on the implications of each).

1. Disable User Account Control
2. Disable UAC Token Filtering via the Windows Registry – Add key,  “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy”. Set to 1 to turn off UAC token filtering.

In addition to changing the UAC settings, the appropriate permissions must be given to the account used to connect from the remote server (these steps are performed on the target server):

Open appropriate ports on firewall devices (see port list above) and Windows Firewall.

From an administrative Command Prompt, type

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

Assign DCOM launch and activations permissions to monitoring account.  (http://msdn.microsoft.com/en-us/library/windows/desktop/aa393266(v=vs.85).aspx)

1. Click Start, click Run, type DCOMCNFG, and then click OK.
2. In the Component Services dialog box, expand Component Services > Computers. Right-click My Computer and click Properties.
3. In the My Computer Properties dialog box, click the COM Security tab.
4. Under Launch and Activation Permissions, click Edit Limits.
5. In the Launch Permission dialog box, select your user and group in the Group or use names box. In the Allow column under Permissions for User, selectRemote Launch and select Remote Activation, and then click O
6. In the Launch Permission dialog box, click Add.
7. In the Select Users, Computers, or Groups dialog box, add your name and the group in the Enter the object names to select box, and then click

Assign WMI Namespace Permissions to monitoring account.

1. In the Control Panel, double-click Administrative Tools.
2. In the Administrative Tools window, double-click Computer Management.
3. In the Computer Management window, expand the Services and Applicationstre and double-click the WMI Control.
4. Right-click the WMI Control icon and select Properties > Security tab.
5. Click the ROOT namespace and click Security.
6. Assign the monitoring service account the appropriate permissions.
7. Repeat step 6 in CIMV2 and WMI namespaces.

Some applications may require additional namespace permissions. Please check your vendor’s documentation.

WMI is an incredibly powerful tool for the sysadmin, and becoming familiar with it will open doors to very pewerful health and performance metrics for your systems. If you are considering a move to off-premises hosting for your Microsoft Servers, it is important to understand how to connect to WMI to perform monitoring of mission-critical services and applications.

About these ads