Pandora FMSAdministrator Manual

Microsoft Exchange Server Monitoring

Administrator Manual Microsoft Exchange Server Monitoring

© Artica Soluciones Tecnológicas 2005-2012

Index1Changelog...........................................................................................................................................32Introduction........................................................................................................................................4

2.1.Exchange Environment: Server roles and optimum configurations..........................................43Compatibility Matrix..........................................................................................................................64Documentation provided by the requesting area................................................................................75Modules provided by the plugin.........................................................................................................86Requirements....................................................................................................................................10

6.1.Access Requirements to the Exchange Administration Shell..................................................117Installing...........................................................................................................................................12

7.1.Additional Configuration Settings ..........................................................................................127.1.1.Monitoring via Powershell..............................................................................................12

1 CHANGELOG

Date Author Change Version

15/02/12 Tomas First version v1r1

Page 3

2 INTRODUCTION

This document has as main aim to describe the Microsoft Exchange Server 2007-2010 servers

monitoring . We have selected a series of “base” module based on our experience in system

monitoring and the needs of some of our clients.

To extract the information we use:

• The software already installed in the system (WMI, Exchange Management Shell,

Powershell), for the monitoring done by the plugin without having to install libraries or

third part utilities.

• An already existing log parser (the one of Pandora) to process the Exchange alert logs.

• One series of basic checks “by default”. But they could be deleted or customized.

• An “open” interface(the one of Pandora, as extension of the administration section) to

specify free SQL queries.

• The system, that is integrated with the Windows agent and has the capacity of distribute file

colections, so it is posible to distribute the plugin by one way and also the file colections in

an individual way-by agent-and/or by policy.

It is important to say, that as with the rest of the monitoring with Pandora FMS, the Exchange

monitoring plugin could be used to collect information kind “text string” (to manage it as events) or

kind numeric (to do performance management).

2.1. Exchange Environment: Server roles and optimum configurations

An Exchange server has grouped its different functionalities in the server roles. These server roles

are the following:

Mailbox Server: Contains the Mailbox and Public Folder databases.

Client Access Server: Gives connectivity between the clients and the mail boxes.

Hub Transport Server:Responsible for the mail flow between the organization.

Edge Transport Server: A server of special transport though for its implementation in DMZ

networks to provide an entry/exit mail flow that would be sure for the organization

Unified Messaging Server: Gives voice and telephony integration in Exchange.

In small environments the usual thing to do is a typical Exchange installing in a single server that

include the roles of Mailbox, CAS and Hub Servers.

For bigger environments the usual thing to do is to install the CAS and HUB server roles in the

same machine and separate them from the Mailbox servers.

Anyway and as a general rule, in big organizations usually each Exchange role is separated in

Page 4

servers dedicated for each one, to increase the flexibility and the performance. This way we manage

to scale them in an apropiate way.

We reach the conclusion that we can gather these roles between our servers in different ways:

• We can set several server roles that coexist in the same machine, but each of the should be

managed as separated entities.

• We can set the server roles in an individual way in dedicated servers.

• The Edge Transport Server server role could not coexist in the same machine with any of

the other roles of the Exchange server.

3 COMPATIBILITY MATRIX

Page 5

The plugin compatibility matrix is the following:

Systems where it has been tested• Windows Server 2003, Exchange 2007• Windows Server 2008, Exchange 2010

Systems where it should work • Same system or higher.

Depending on the operative system, the format in the Powershell scripts to extract the information

that you want could change, so it will be necessary to adapt the plugin according with those

circumstances.

4 DOCUMENTATION PROVIDED BY THE REQUESTING AREA

The requesting area must provide the following information:

Page 6

• Machine with Powershell and Echange Management Shell installed.

• It is necessary that the user with which the Pandora FMS agent is executed, that is the user

that will execute the plugin, has the following permissions of the system:

◦ Exchange administrator, Exchange administrator for reading only, or customized rol

with permission to use Remote Powershell and each of the Powershell cmdlets used by

the plugin without restrictions(Organization Management, View-Only Organization

Management, Custom Role.

◦ User of the domain (Domain Users)

◦ Administrator of Domain controller (optional).

• It is necessary that the Exchange server where the plugin is going to be executed would be

in the following groups:

◦ Domain Computers

◦ Exchange Servers

◦ Exchange Trusted Subsystem

• It should be an user extest_xxxxxxxxxxxxx member of Domain Users to do the Powershell

tests. This is checked being Domain Administrator, executing “Scripts\new-

TestCasConnectivityUser.ps1”.

• The plugin will automatically get the path of each Exchange instance and will call to the

Exchange administrator shell to do several queries to get information.

• It should be posible to have access to the internal and external OWAs from the CAS server.

5 MODULES PROVIDED BY THE PLUGIN

The plugin generates the following modules:

Page 7

• Global Exchange Monitoring

◦ MSExchangeServiceHost

• CAS Exchange Monitoring

◦ MSExchangeAB, MSExchangeADTopology

◦ MSExchangeFBA, MSExchangeFDS, MSExchangeImap4

◦ MSExchangeMailboxReplication, MSExchangePop3

◦ MSExchangeProtectedServiceHost, MSExchangeRPC

◦ MSExchangeW3SVC

• HUB Exchange Monitoring

◦ MSExchangeADTopology, MSExchangeAntiSpamUpdate

◦ MSExchangeEdgeSync, MSExchangeProtectedServiceHost

◦ MSExchangeTransport

◦ MSExchangeTransportLogSearchAttendant

• Mailbox Exchange Monitoring

◦ MSExchangeADTopology

◦ MSExchangeIS, MSExchangeMailboxAssistants

◦ MSExchangeMailSubmission, MSExchangeMonitoring

◦ MSExchangeRepl, MSExchangeRPC, MSExchangeSA

◦ MSExchangeSearch, MSExchangeSearchB

◦ MSExchangeThrottling

◦ MSExchangeServerExtensionForWindowsServerBackup

◦ MSExchangeTransport, MSExchangeTransportLogSearchAttendant

• Public Folder Exchange Monitoring

◦ MSExchangeADTopology

Page 8

◦ MSExchangeIS, MSExchangeMailboxAssistants

◦ MSExchangeMailSubmission,

◦ MSExchangeRepl, MSExchangeRPC, MSExchangeSA

◦ MSExchangeSearch, MSExchangeSearchB

◦ MSExchangeThrottling

◦ MSExchangeTransport, MSExchangeTransportLogSearchAttendant

6 REQUIREMENTS

The requirements for this monitoring works correctly are the following:

• To install the Pandora FMS server in version 3.2.1 or higher.

Page 9

• To have an Exchange server (minimum 2007 SP1, because before SP1 several cmdlets such

as Get-Queue or Get-MessageTrackingLog, for example, can not be used in the plugin due

to a bug documented by Microsoft that is corrected from the SP1) installed in the machine

where it is going to be monitored, with the basic tools (Powershell, Exchange Management

Shell).

• It is necessary that the user with which the Pandora FMS agent is executed, that is the user

that will execute the plugin, has the following permissions of the system:

◦ Exchange administrator, Exchange administrator for reading only, or customized rol

with permission to use Remote Powershell and each of the Powershell cmdlets used by

the plugin without restrictions(Organization Management, View-Only Organization

Management, Custom Role(compulsory).

◦ User of the domain (Domain Users) (compulsory)

◦ Administrator of Domain controller (optional).

• It is necessary that the Exchange server where the plugin is going to be executed would be

in the following groups:

◦ Domain Computers (compulsory)

◦ Exchange Servers (compulsory)

◦ Exchange Trusted Subsystem (compulsory)

• It should be an user extest_xxxxxxxxxxxxx member of Domain Users to do the Powershell

tests. This is checked being Domain Administrator, executing “Scripts\new-

TestCasConnectivityUser.ps1”.

• The plugin will automatically get the path of each Exchange instance and will call to the

Exchange administrator shell to do several queries to get information.

• It should be posible to have access to the internal and external OWAs from the CAS server.

6.1. Access Requirements to the Exchange Administration Shell

The plugin needs to be executed by an user with permissions to connect to the Exchange

administration shell depending on the server to which we want to connect. This user should have

enough priviledges to use the necessary cmdlets to get information.

To prepare the use of the Exchange administration shell it is necessary to have an user with access

Page 10

priviledges for some of the cmdlets.

It will be enough if we have the necesary permissions, with an installation by default of the Pandora

agent. We will not need to configure anything more.

Page 11

7 INSTALLING

Copy the plugin to the agent plugin directory, distributing it through file collections. The same with

the conf. File. The call from the agent will be similar to this, but using the paths where the plugin

and the conf are installed.

module_plugin "<ruta-powershell>\powershell.exe" -PSConsoleFile "E:\Program Files\Microsoft\Exchange Server\Bin\exshell.psc1" -command C:\'<ruta-plugin>\pandora_exchange.ps1'

7.1. Additional Configuration Settings

NOTE: It is extremely important to consider that the configuration files though for the plugin in

WINDOWS should be edited and stored with carriage returns kind “WINDOWS” and that if we

use carriage returns kind “UNIX” the plugin will not work well.

There are some specific checks that have its own configuration “tokens”, that are described next:

7.1.1. Monitoring via Powershell

Starting from the basis that we have already installed and configured both Pandora and the Exchange server, we are going to explain how to get information about the server status in general, from the activity of the different services, and aslo the Exchange probes that through different cmdlets have to check critical elements of our systems

For this case we should install both a Pandora software agent and the Exchange plugin in the Exchange server machine. The Exchange plugin in Powershell is an agent plugin used by Pandora.

Summarizing, an agent plugin is one scrip that is executed in the local machine where the software agent is installed, and that extracts an useful information in XML format that the agent will send after to the Pandora server in order to be processed).

To do that the Pandora software agent that we have installed in our server to monitor executes this script, we should edit the agent configuration file and do the call to the plugin through the module_plugin. configuration token

We are going to edit the Pandora agent configuration file from the Pandora FMS administration console. Before doing this, we should have activated the remote_config option in the same file to 1.This file is located by default at:

C:\Archivos de programa\pandora_agent\pandora_agent.conf

Considering that we could edit the configuration remotely, we should go to the Administration →

Agent management and click on the remote configuration icon of the

Page 12

agent that we want to configure.

We introduce the following at the end of the configuration file:

# Plugin for monitoring Microsoft Exchange Server

module_plugin "<ruta-powershell>\powershell.exe" -PSConsoleFile "E:\Program Files\Microsoft\Exchange Server\Bin\exshell.psc1" -command C:\'<ruta-plugin>\Pandora_Plugin_Exchange_vx.y.ps1'

Page 13

We save the file and start the Pandora agent.

Once it has been configured, we have to distribute the necessary files through file collections .

These are file packages that are sent to all the agents that have them assigned (either by separate or

because it is included in a policy with file collections assigned) through a centralized distribution

system integrated in Pandora FMS.

This process will be explained in detail through the document:

One of the most powerful features of the plugin in Powershell is the posibility of specifying instead

of the complete list of servers and do the same check for each one, to select one list of servers in

order the plugin does only one check and module for all the servers contained in this list. We

should put this list in the same folder where the plugin is, with the name mailbox_servers.txt

Let's see an example of its content:

ESTGVMSD201ESTGVMSD202ESTGVMSD401ESTGVMST402

Containing these servers mailbox_servers.txt, for all the modules that checks all the server lists.

Instead this, it will do the query only of these four servers and will do the modules in base of the list

given by us. For the development of any other plugin that extracts information via Powershell, it is

important to consider the cmdet use:

Page 14

select-object -property *

We're able to add this cmdlet after any other one which return statistics by using a tube ( | ). This

way, the final execution will return to the standard output information regarding all the properties

this cmdlet contains, even when the execution of the first cmdlet without using any parameter only

returned the information from a default list.

This way our posibilities of monitoring using Powershell are notably extended.

In case that we want to add new modules to our plugin, before doing anything, try to execute the

cmdlet from which we want to extract information with the previously mentioned, to get all the

posible information.

An example of the use of this command woul be the following:

Get-Service | Select-Object -Property *

Usually, the result of the Get-Service cmdlet would be a list in table format of all services with their

description and status. But, when we apply this second cmdlet, we get for each service information

about all the propieties that this service have available:

Name : serviceRequiredServices : {service1, service2}CanPauseAndContinue : FalseCanShutdown : TrueCanStop : TrueDisplayName : This is a Windows ServiceDependentServices : {service3}MachineName : .ServiceName : serviceServicesDependedOn : {service1, service2}ServiceHandle : SafeServiceHandleStatus : StoppedServiceType : Win32ShareProcessSite :Container :

Page 15