Monitoring Windows Servers and Applications with GroundWork Monitor Enterprise 6.7 Product Application Guide October 8, 2012
Table of Contents Introduction...3 Definitions and Abbreviations...3 GroundWork Windows Monitoring Components...5 Windows Monitoring Component Descriptions...5 Related Notes...10 Solution Architecture...10 References...10 Appendix A Plugins and Profiles for Windows Server Monitoring...11 Windows WMI Profiles and Plugins...11 PowerShell Profiles and Plugins...12 Exchange Profiles 2007 2010...12 Page 2
INTRODUCTION The GroundWork Monitor Enterprise product family is designed to provide comprehensive monitoring of storage, networks, servers, and applications particularly in heterogeneous multi-vendor environments. This requires that the product provide all of the monitoring components, and software functionality to monitor Microsoft Windows servers and applications in accordance with the various standards and protocols created by Microsoft and industry for this purpose. The purpose of this document is to describe the various methods and techniques that are provide with GroundWork Monitor for this purpose as an aide to selecting the best techniques for a particular customer s Windows environment. Definitions and Abbreviations Microsoft Operating Systems, Clusters, Hypervisors, Database Managers, and Application Software Products contain features that are designed to permit them to be managed and monitored effectively. With much appreciation to Wikipedia and publically available Microsoft documentation, we offer the following somewhat historical overview. Over the years, Microsoft has introduced a number of different monitoring tools to help monitor Windows environments including the following: SNMP (MIB Polling and Traps) This technique is no longer recommended for monitoring of Microsoft products by Microsoft or by GroundWork. SYSTEM MONITOR (sysmon.exe) is a program in Windows 95, 98 and ME that is used to monitor various activities on a computer such as CPU usage or memory usage. The equivalent of System Monitor on Windows 2000 and XP is called Performance Monitor (perfmon.msc or perfmon.exe). Despite this, the original System Monitor can be run on XP. PERFMON provided about 400 counter type performance measures that could be accessed via a remote terminal session or through local agents. EVENT LOG is the message logging function provided on Microsoft Windows servers to record process starts and stops and operational errors of various kinds. A very common monitoring technique is to collect and concatenate Event Logs from multiple Windows servers and applications into a single Event Management where messages can be sequenced, de-duplicated, filtered, correlated, and analyzed both during and after incidents. WMI (Windows Management Instrumentation) is a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF). There are eight different data types of WMI instrumentation. GroundWork is the author of a complete set of Nagios plugins, which are capable of Page 3
monitoring any of the roughly 4000 different WMI parameters. PERFMON data is subsumed within WMI data structures. WINDOWS POWERSHELL is Microsoft s task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the.net Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems. In PowerShell, administrative tasks like monitoring are generally performed by cmdlets (pronounced command-lets) specialized.net classes implementing a particular operation. Sets of cmdlets may be combined together in scripts, executables (which are standalone applications), or by instantiating regular.net classes (or WMI/COM Objects). These work by accessing data in different data stores, like the file system or registry, or [event log], which are made available to the PowerShell runtime via Windows PowerShell providers. Microsoft Operations Manager is a Microsoft cross-platform data center management product that utilized management packs in order to provide detailed monitoring of Microsoft servers and applications. It was originally released in 2000. This product was later re-written with a new code base and released as System Center Operations Manager 2007 (SCOM). System Center Operations Manager 2007 (SCOM) uses a single interface that shows state, health and performance information of computer systems. It also provides alerts generated according to some availability, performance, configuration or security situation being identified. The basic idea is to place a piece of software, an agent, on the computer to be monitored. The agent watches several sources on that computer, including the Windows Event Log, for specific event or alerts generated by the applications executing on the monitored computer. Upon alert occurrence and detection, the agent forwards the alert to a central SCOM server. This SCOM server application maintains a database that includes a history of alerts. The SCOM server applies filtering rules to alerts as they arrive; a rule can trigger some notification to a human, such as an e-mail or a pager message, generate a network support ticket, or trigger some other workflow intended to correct the cause of the alert in an appropriate manner. Page 4
GROUNDWORK WINDOWS MONITORING COMPONENTS The following Windows monitoring components are available for use with GroundWork Monitor: Passive Self-Scheduling Agents (Windows GDMA). NET Based GroundWork Child Servers WMI Plugin Library PowerShell Plugin Library Event Log Collection and Parsing with Syslog NG SCOM 2007 R2 Universal Connector Windows Monitoring Component Descriptions The following paragraphs describe the windows monitoring components that are included in the standard GroundWork Monitor Enterprise subscription and can be combined to meet particular architectural requirements of GroundWork customers. Passive Self-Scheduling Agents (Windows GDMA) GroundWork Distributed Monitoring Agents (GDMA) are available for Windows as well as Unix and Linux. The Windows GDMA consists of the following components: A standard PERL environment A configuration file containing control directives A number of disk resident plugins (Plugins are simple programs written in Visual Basic or PowerShell that when supplied with particular arguments provided in the configuration file, collect one or more monitoring parameters and compare them to warning and critical thresholds that are provided as arguments.) An in-memory polling program which supplies the arguments and then runs the plugins on a schedule determined by the configuration file directives and writes the results to a spooler file An in-memory spooler program that reads the spooler file and communicates the results to the central GroundWork server subject to various telecommunications directives that are also included I the configuration file. A configuration update program which when called by the poller program initiates requests to the central GroundWork server for updates to the configuration file and the plugin set and when these are available, updates these data elements. GDMA s are installed by the standard GroundWork installer, which can be configured for either manual or unattended operation. They can be configured to be installed with their final configuration directives and plugin set or with a preliminary version which is Page 5
subsequently updated through either auto-configuration or auto-registration actions taken on the GroundWork Server. The Windows GDMA is associated with the WMI and PowerShell Plugin libraries since these are the plugins that it executes. The use of GroundWork agent based monitoring of Windows servers and applications is illustrated in the figure below. Agent based monitoring has certain well-known advantages involving security and scalability. Agent-less monitoring has the advantage of reducing to a minimum the overhead loading imposed on the monitored server. This is provided for with the GroundWork.NET Based Child Server which is described below. GDMA s are available for 64 bit Windows systems. They are fully compatible and supported for use in hypervisor based virtual servers.. NET Based GroundWork Child Servers In order to provide agent-less monitoring for Windows servers and applications, the GroundWork product family includes a dedicated Windows child server on which a multihost version of the GDMA software has been installed. Instead of a single configuration file, the multi-host version of the GDMA contains a configuration file for each of the Windows servers, which are to be monitored without resident agents. The Windows child server or servers are authenticated to the.net environment by interfacing the system to Active Directory. Multiple threads are employed with the poller to achieve the required parallelism needed to maintain the monitoring schedule. The GroundWork Windows Child Server(s) can be installed either as a virtual server running on a hypervisor as a standalone Windows Server. The figure shown below illustrates the.net Based GroundWork Child Server architecture. Page 6
WMI Plugin Library The WMI data set contains eight basic data types. GroundWork has written one powerful plugin for each of these data types, which is made sufficiently flexible through the use of arguments, that the eight plugins can be configured to collect all of the 4000 different parameters that are included in the WMI set. Of course, WMI is not fully supported in the most recent versions of some Microsoft products like Exchange 2010 and others. For these products, only PowerShell cmdlets can be used to collect monitoring parameters and for that matter the number and type of monitoring information that is available is also different. WMI Plugins and their associated service profiles are listed in Appendix A. PowerShell Plugin Library Because PowerShell is a complete object oriented shell environment for Windows, it isn t feasible to collect large numbers of different parameters with a small number of plugins with added arguments. This change in approach is needed however to provide adequate monitoring coverage for newer generation Microsoft products like Microsoft Exchange 2010, Windows Server 2008 R2, Microsoft SharePoint 2010, and Lync 2010. GroundWork is continuously developing new PowerShell plugins for the other Microsoft products that require them. PowerShell plugins and their associated service profiles are listed in Appendix A. Page 7
Event Log Collection and Parsing Available PowerShell cmdlets can be used to create PowerShell plugins for use with GDMA or GroundWork Child Servers that select Event Log messages to be delivered directly to the GroundWork Monitor Enterprise system without transferring the entire log file. Alternatively, Microsoft.NET utilities to transfer the complete Event logs to the GroundWork Windows child server for concatenation and subsequent transfer to the GroundWork Monitor Enterprise system. On the GroundWork system Event log messages would be presented for operator action on the GroundWork Event Console. That said, GroundWork believes that monitoring best practices normally indicate that better monitoring results are obtained from scheduled periodic monitoring checks using plugins rather than processing all events in system logs. SCOM 2007 Universal Connector System Center Operations Module (SCOM) requires the placement of a data collection agent on each of the monitored systems. When GroundWork Monitor Enterprise is deployed as a manager of monitors, it is often necessary to input the monitoring results of a SCOM system into a GroundWork Monitor Enterprise system. The relevant architecture is shown in the following figure. Page 8
SCOM 2007 is able to send alerts back and forth with GroundWork Monitor Enterprise with the SCOM 2007 universal connector. After Operations Manager 2007 R2 forwards an alert to GroundWork Monitor Enterprise, the alert data may be synchronized throughout the lifetime of the alert if desired. This data synchronization creates a seamless systems management environment. This environment enables cross-organization support processes to take advantage of the resources and strengths of formerly independent support groups. Sharing data between Operations Manager 2007 R2 and GroundWork Monitor Enterprise enables correlation of events from Windows-based systems, hardware, network, and UNIX systems. Correlating these events allows IT staff to determine the causes of issues and reduce the time to resolution of IT outages. Synchronization of data between Operations Manager 2007 R2 and Groundwork Monitor Enterprise enables operational groups to use familiar management interfaces. Users update an alert by using their management tool, and the data is updated in tools that are used by other operational groups. The following diagram outlines how the universal connector is implemented: The universal connector is installed on the SCOM 2007 server and it becomes an integrated part of the console. In the console, administrators can configure communications for Operations Manager 2007 R2 servers with Groundwork Monitor Enterprise. The configuration allows for mapping SCOM alert properties to properties of the remote system s events. The connector service gathers alerts from SCCM 2007 and sends them to the Interop Provider that is installed on the Groundwork Monitor Enterprise server. The connector service also receives updates from the Interop Provider for Groundwork events that were created from Operations Manager alerts. Page 9
The Interop Provider is installed on the Groundwork Monitor Enterprise server in order to receive alerts from the connector service. The alerts are then processed and integrated into the Groundwork console. If desired, Groundwork can also utilize the Interop Provider to send updates on the events back to the connector service. The connector service will send the information to SCOM, which will update the original alert. Related Notes GroundWork notes that it is also possible to use active Monitoring Agents such as NSClient++ and NRPE to monitor Windows systems. Active agents receive triggering commands from the GroundWork Monitor Enterprise system and return the plugin results in response. While recommended for use with Nagios legacy systems, these agents can also make use of GroundWork WMI and PowerShell plugins. SOLUTION ARCHITECTURE Microsoft Windows Server and Application monitoring is fully supported by the product functions and components previously described. In Manager of Monitor solutions, GroundWork has out of the box integration modules for use with SCOM. In heterogeneous environments, GroundWork can monitor the Microsoft elements of the infrastructure with a combination of single agent GDMA s and.net based GroundWork Child systems to securely achieve both agent and agent-less monitoring. For optimal results, GroundWork recommends that planned monitoring architectures be reviewed with GroundWork professional services. REFERENCES The following references support the preparation and use of this document GDMA Product Description System Center Operations Manager 2007 R2 Connectors Deployment Guide Page 10
APPENDIX A PLUGINS AND PROFILES FOR WINDOWS SERVER MONITORING Windows WMI Profiles and Plugins In the following list of Windows WMI Profiles and Plugins, the Nagios server uses the Nagios Remote Plugin Executor (NRPE) to communicate with the WMI proxy server. This proxy server queries the monitored Windows server for measurements and status using WMI. In addition to the list information below, you may want to refer to the WMI Agentless Plugins Project documentation. This project consists of a collection of script monitors (.vbs for starters) that use the Microsoft.Net Framework and WMI to retrieve performance data from remote Windows hosts without the need for agents on the remote hosts. WMI Citrix Profile This profile monitors a Windows Citrix Server using Windows Management Instrumentation (WMI). WMI Domain Controller (DC) Profile This profile monitors Domain Controller performance metrics on a Windows server using Windows Management Instrumentation (WMI). WMI Domain Name Service (DNS) Profile This profile monitors Domain Name Services on a Windows server using Windows Management Instrumentation (WMI). WMI Exchange Profile This profile monitors Exchange Mail Server on a Windows server using Windows Management Instrumentation (WMI). WMI Exchange Virus Profile This profile monitors Exchange Virus Services on a Windows server using Windows Management Instrumentation (WMI). WMI File Transfer Protocol (FTP) Profile This profile monitors a File Transfer Protocol server on a Windows server using Windows Management Instrumentation (WMI). WMI Hyper Text Transfer Protocol (HTTP) Profile This profile monitors HTTP services on a Windows server using Windows Management Instrumentation (WMI). WMI Hyper Text Transfer Protocol Secure (HTTPS) Profile This profile monitors HTTPS services on a Windows server using Windows Management Instrumentation (WMI). WMI Internet Information services (IIS) Profile This profile monitors IIS services on a Windows server using Windows Management Instrumentation (WMI). WMI Internet Message Access Protocol (IMAP) Profile This profile monitors IMAP services on a Windows server using Windows Management Instrumentation (WMI). WMI MSSQL 2005 Server Profile This profile monitors several statistics for Windows 2005 MSSQL servers via WMI. WMI Microsoft SQL (MSSQL) Profile This profile monitors a Microsoft SQL Server using Windows Management Instrumentation (WMI). Page 11
WMI Post Office Protocol 3 (POP3) Profile This profile monitors a POP3 server on a Windows server using Windows Management Instrumentation (WMI). WMI Proxy Profile This profile monitors the WMI proxy server using Windows Management Instrumentation (WMI). WMI SMTP Profile This profile monitors a SMTP server on a Windows server using Windows Management Instrumentation (WMI). WMI Windows Profile This profile monitors a Windows server using Windows Management Instrumentation (WMI). PowerShell Profiles and Plugins Running Modes Single-host GDMA: As the Windows GDMA is considered to be the highest value method of monitoring with GroundWork; the profiles will all include externals definitions assigned to the services that allow their use with GDMA. This means that the actual active service checks are disabled by default, and that the service check command defined is a gdma_check_fresh command, rather than an active check such as check_nrpe. Multi-Host GDMA (Windows Child Server): The Windows child server uses remote access methods like WMI to read the metrics from remote windows servers. This means that credentials must be passed to the target host, via the GDMA service login or on the command line. Active Direct NRPE: An active version of the service profiles can optionally be produced that runs against an NRPE_NT installation on the monitored Windows server. In this case the active check command is enabled, there is no service external, and the command line will encapsulate the plugin command with the correct escaping to allow it to be run easily. Active Indirect NRPE: In this optional mode, the plugin is run on a Windows proxy server running NRPE_NT, and uses account information stored with either the NRPE service login or supplied at the command line to check remote MS Windows hosts. This requires the use of WMI or remote protocols for accessing metrics on another MS Windows host (DCOM,.Net, etc). This means the plugins or the mode of use of the plugins for this running mode are the same as for the Multi-host GDMA. Windows Servers and Client Workstations Base Profile Exchange Profiles 2007 2010 Service Profile MS Exchange Any Server This profile includes monitoring of metrics common to all MS Exchange server roles. It is applied to each server in a multi-server deployment, in addition to the role-specific profiles listed below. Exchange Client Access Server This profile will include monitoring of TCP ports for Page 12
POP3 and IMAP. It also includes various counters. Edge Transport Server Monitoring The ETS provides protection from Internet-based attack vectors like DDOS and viruses, and runs services that insulate the rest of MS Exchange from these threats. Hub Transport server Monitoring The HTS provides mail routing between locations. Mailbox Server Monitoring Unified Messaging Server Monitoring This role provides voice-messaging integration with Exchange. Page 13