Pandora FMS: Exchange Enterprise plugin
0 likes859 views
The document serves as an administrator manual for monitoring Microsoft Exchange Server 2007-2010 using Pandora FMS, outlining system roles, compatibility requirements, and installation guidelines. Key components include the configuration of PowerShell scripts for data extraction, user access permissions, and module generation for various Exchange roles like mailbox and client access servers. It emphasizes the need for proper setup to enable effective monitoring of critical system elements and ensures integration with the Pandora framework.
Pandora FMS: Exchange Enterprise plugin
- 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