This plugin monitors the Microsoft Exchange Server 2007/­2010 servers using a series of system commad and the software already installed on the system. For more information visit the following webpage: http://pandorafms.com/index.php?sec=Library&sec2=repository&lng=en&action=view_PUI&id_PUI=274

1. Pandora FMS
Administrator Manual
Microsoft Exchange Server Monitoring

2. Administrator Manual Microsoft Exchange Server Monitoring
© Artica Soluciones Tecnológicas 2005-2012
Index
1Changelog...........................................................................................................................................3
2Introduction........................................................................................................................................4
2.1.Exchange Environment: Server roles and optimum configurations..........................................4
3Compatibility Matrix..........................................................................................................................6
4Documentation provided by the requesting area................................................................................7
5Modules provided by the plugin.........................................................................................................8
6Requirements....................................................................................................................................10
6.1.Access Requirements to the Exchange Administration Shell..................................................11
7Installing...........................................................................................................................................12
7.1.Additional Configuration Settings ..........................................................................................12
7.1.1.Monitoring via Powershell..............................................................................................12

3. 1 CHANGELOG
Date Author Change Version
15/02/12 Tomas First version v1r1
Page 3

4. 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

5. 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

6. 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

7. • 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 “Scriptsnew-
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

8. • 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

9. ◦ 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

10. • 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 “Scriptsnew-
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

11. 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

12. 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
FilesMicrosoftExchange ServerBinexshell.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 programapandora_agentpandora_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

13. 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
FilesMicrosoftExchange ServerBinexshell.psc1" -command C:'<ruta-
plugin>Pandora_Plugin_Exchange_vx.y.ps1'
Page 13

14. 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:
ESTGVMSD201
ESTGVMSD202
ESTGVMSD401
ESTGVMST402
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

15. 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 : service
RequiredServices : {service1, service2}
CanPauseAndContinue : False
CanShutdown : True
CanStop : True
DisplayName : This is a Windows Service
DependentServices : {service3}
MachineName : .
ServiceName : service
ServicesDependedOn : {service1, service2}
ServiceHandle : SafeServiceHandle
Status : Stopped
ServiceType : Win32ShareProcess
Site :
Container :
Page 15