configuring and monitoring microsoft applications implementer's guides...configuring and...

Configuring and Monitoring Microsoft

Applications

eG Enterprise v5.6

Restricted Rights Legend

The information contained in this document is confidential and subject to change without notice. No part of

this document may be reproduced or disclosed to others without the prior permission of eG Innovations,

Inc. eG Innovations, Inc. makes no warranty of any kind with regard to the software and documentation,

including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.

Trademarks

Microsoft Windows, Windows NT, Windows 2000, Windows 2003 and Windows 2008 are either registered

trademarks or trademarks of Microsoft Corporation in United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective

owners.

Copyright

© 2013 eG Innovations, Inc. All rights reserved.

Table of Contents CONFIGURING AND MONITORING AN ACTIVE DIRECTORY SERVER ...................................................... 1

1.1 Administering the eG Manager to monitor an Active Directory Server ............................................................ 1

1.2 Monitoring the Active Directory Server............................................................................................................ 5

CONFIGURING AND MONITORING EXTERNAL ACTIVE DIRECTORY (AD) SERVERS .......................... 6

2.1 Administering the eG Manager to Work with an External AD Server .............................................................. 6

2.2 Monitoring the External AD Server .................................................................................................................. 7

CONFIGURING AND MONITORING THE ACTIVE DIRECTORY (AD) CLUSTER SERVICE ..................... 8

3.1 Administering the eG Manager to Work with an AD Cluster Service .............................................................. 8

3.2 Monitoring the AD Cluster Service................................................................................................................... 9

CONFIGURING AND MONITORING WINDOWS DOMAIN CONTROLLERS ............................................... 11

4.1 Administering the eG Manager to work with a Windows Domain Controller ................................................ 11

4.2 Monitoring the Windows Domain Controller ................................................................................................. 13

CONFIGURING AND MONITORING THE WINDOWS INTERNET NAME SERVICE (WINS) ................... 15

5.1 Administering the eG Manager to work with a WINS Server ......................................................................... 15

5.2 Monitoring the WINS Server .......................................................................................................................... 19

CONFIGURING AND MONITORING TERMINAL SERVER .............................................................................. 20

6.1 Administering the eG Manager to work with Terminal servers ...................................................................... 20

6.2 Monitoring the Terminal Server ...................................................................................................................... 23

CONFIGURING AND MONITORING BIZTALK SERVER 2000 ........................................................................ 24

7.1 Administering the eG Manager to work with a BizTalk Server ...................................................................... 24

7.2 Monitoring the BizTalk Server ....................................................................................................................... 25

CONFIGURING AND MONITORING BIZTALK SERVER2010 ......................................................................... 26

8.1 Administering the eG Manager to work with a BizTalk server2010 ............................................................... 26

8.2 Monitoring the BizTalk server2010 ................................................................................................................ 27

CONFIGURING AND MONITORING DHCP SERVERS ...................................................................................... 28

9.1 Administering the eG Manager to work with a DHCP Server ........................................................................ 28

9.2 Monitoring the DHCP Server .......................................................................................................................... 29

CONFIGURING AND MONITORING MICROSOFT PROXY SERVERS .......................................................... 31

10.1 Administering the eG Manager to work with a Microsoft Proxy Server ..................................................... 31

10.2 Monitoring the Microsoft Proxy Server ...................................................................................................... 33

CONFIGURING AND MONITORING MS PRINT SERVERS .............................................................................. 34

11.1 Administering the eG Manager to work with an MS Print Server ............................................................... 34

11.2 Monitoring the MS Print Server .................................................................................................................. 35

CONFIGURING AND MONITORING MS FILE SERVERS ................................................................................. 37

12.1 Administering the eG Manager to Monitor an MS File Server ................................................................... 37

12.2 Monitoring the MS File Server ................................................................................................................... 38

CONFIGURING AND MONITORING ISA PROXY SERVERS ............................................................................ 40

13.1 Administering the eG Manager to Work with the ISA Proxy Server .......................................................... 40

13.2 Monitoring the ISA Proxy Server ............................................................................................................... 44

CONFIGURING AND MONITORING MICROSOFT RADIUS SERVERS ......................................................... 45

14.1 Administering the eG Manager to Work with the Microsoft Radius Server ............................................... 45

14.2 Monitoring the Microsoft Radius Server ..................................................................................................... 46

CONFIGURING AND MONITORING THE MICROSOFT REMOTE AUTHENTICATION SERVICE (RAS)

........................................................................................................................................................................................ 47

15.1 Administering the eG Manager to Work with the MS RAS Server ............................................................. 47

15.2 Monitoring the Microsoft RAS Server ........................................................................................................ 48

CONFIGURING AND MONITORING WINDOWS CLUSTER ............................................................................ 49

16.1 Monitoring the Windows Cluster Server .................................................................................................... 51

CONFIGURING AND MONITORING MICROSOFT FAST SEARCH SERVER............................................... 52

17.1 Administering the eG Manager to monitor a Microsoft Fast Search Server ................................................ 52

17.2 Monitoring the Microsoft Fast Search Server ............................................................................................. 59

CONCLUSION ............................................................................................................................................................. 60

Table of Figures

Figure 1.1: Viewing the list of unmanaged Active Directory servers ...................................................................................................... 2 Figure 1.2: Managing an Active Directory server .................................................................................................................................... 2 Figure 1.3:List of unconfigured tests for an Active Directory server ....................................................................................................... 3 Figure 1.4: Configuring the ADServer test .............................................................................................................................................. 3 Figure 1.5: List of tests that are yet to be configured for the Active Directory server.............................................................................. 4 Figure 1.6: Configuring the Active Directory Checks test ....................................................................................................................... 4 Figure 1.7: Configuring the Global Catalog Search test .......................................................................................................................... 5 Figure 2.1: Adding an External AD server .............................................................................................................................................. 6 Figure 2.2: The list of unconfigured tests for an External AD server ....................................................................................................... 7 Figure 3.1: Adding an AD Cluster ........................................................................................................................................................... 9 Figure 3.2: A segment containing the cluster service and the AD servers ............................................................................................... 9 Figure 4.1: Selecting the Windows Domain Controller to manage ........................................................................................................ 12 Figure 4.2: Managing the Windows Domain Controller ........................................................................................................................ 12 Figure 4.3: List of unconfigured tests for an Domain Controller server................................................................................................. 13 Figure 4.4: Configuring the Window Authentication test ...................................................................................................................... 13 Figure 5.1: Selecting the WINS server to manage ................................................................................................................................. 16 Figure 5.2: Managing the WINS server ................................................................................................................................................. 16 Figure 5.3: List of unconfigured tests for an WindowsProcesses test .................................................................................................... 17 Figure 5.4: Configuring the Windows Processes test ............................................................................................................................. 17 Figure 6.1: Selecting the Terminal server to manage ............................................................................................................................. 21 Figure 6.2: Managing the Terminal server ............................................................................................................................................. 21 Figure 6.3: Unconfigured tests of the Terminal server........................................................................................................................... 22 Figure 6.4: Configuring the TerminalAuthentication test ..................................................................................................................... 22 Figure 7.1:Adding a new BizTalk component ....................................................................................................................................... 25 Figure 8.1:Adding a new BizTalk server2010 component ..................................................................................................................... 27 Figure 9.1: Viewing the list of unmanaged DHCP servers .................................................................................................................... 29 Figure 9.2: Managing a DHCP server .................................................................................................................................................... 29 Figure 10.1: Viewing the list of unmanaged Microsoft Proxy servers ................................................................................................... 32 Figure 10.2: Managing an Micosoft Proxy server .................................................................................................................................. 32 Figure 11.1: Viewing the list of unmanaged MS Print servers............................................................................................................... 35 Figure 11.2: Managing an MS Print server ............................................................................................................................................ 35 Figure 12.1: Viewing the list of unmanaged MS File servers ................................................................................................................ 38 Figure 12.2: Managing an MS File server ............................................................................................................................................. 38 Figure 13.1: Viewing the list of unmanaged ISA Proxy servers ............................................................................................................ 41 Figure 13.2: Managing an ISA Proxy serverList of unconfigured test for the ISA Proxy server .......................................................... 41 Figure 13.3:List of unconfigured test for the ISA Proxy server ............................................................................................................. 41 Figure 13.4: Configuring of the Windows Processes test ...................................................................................................................... 42 Figure 14.1: Adding a Microsoft Radius server .................................................................................................................................... 46 Figure 15.1: Adding a Microsoft RAS server ........................................................................................................................................ 48 Figure 16.1: Selecting the config layer of the IIS Web server ............................................................................................................... 49 Figure 16.2: Selecting the Windows Cluster from the Disassociated Layers ....................................................................................... 50 Figure 16.3: Associating the Windows Cluster to the top layer of the IIS Webserver ......................................................................... 50 Figure 16.4: Viewing the Cluster related tests in the Agents-Tests Configuration page ....................................................................... 51 Figure 17.1: Adding the Microsoft Fast Search Server .......................................................................................................................... 52 Figure 17.2: List of unconfigured tests to be configured for the Microsoft Fast Search Server ............................................................. 53 Figure 17.3: Configuring the Log Monitor test ...................................................................................................................................... 53 Figure 17.4: Configuring the Windows services test ............................................................................................................................. 57

Conf igu r ing and Mon ito r ing an Act ive D irectory Serve r

1

Configuring and Monitoring an Active Directory Server The eG Enterprise suite provides extensive monitoring support to the Active Directory (AD) server operating

on Windows 2000, 2003, and 2008. The specialized monitoring model that the eG Enterprise offers

periodically executes a number of tests on the AD server to extract a wide gamut of metrics indicating the

availability, responsiveness, and overall health of the AD server and its underlying operating system. Using

this model, Active Directory servers can be monitored in an agent-based or an agentless manner.

This section discusses how to administer and monitor an Active Directory server.

1.1 Administering the eG Manager to monitor an Active Directory Server

An Active Directory server is an integral part of a Windows 2000 server installation.

1. If an Active Directory server is automatically discovered by the eG Manager, it can be managed by the

COMPONENTS - MANAGE/UNMANAGE page that appears when the Infrastructure -> Components ->

Manage/Unmanage menu sequence is used. The screens below will guide you through this process. If

an Active Directory server is not discovered automatically, then the ADD/MODIFY COMPONENTS page can

be used to manually add an Active Directory server for monitoring. In such a case, the manual

management procedure can be dispensed with, as the eG Enterprise system automatically manages

added components.

For more details on managing components, refer to Configuring and Monitoring Mail Servers

document.


2

Figure 1.1: Viewing the list of unmanaged Active Directory servers

Figure 1.2: Managing an Active Directory server


3

2. Try to signout of the eG administrative interface. Figure 1.3 will appear prompting you to configure a

list of tests.

Figure 1.3:List of unconfigured tests for an Active Directory server

3. The Active Directory Server test monitors the availability and response time from clients of an Active

Directory server. To configure this test, click on the test name in Figure 1.3. Figure 1.4 then appears.

Figure 1.4: Configuring the ADServer test

4. Specify the following in Figure 1.4:

TEST PERIOD - How often should the test be executed

HOST - The IP address of the machine where the Active Directory is installed.

PORT – The port number through which the Active Directory communicates. The default port

number is 389.

DOMAIN - The default value of the DOMAIN parameter will be none. In Windows 2003

environments however, the ADServerTest will function effectively only if a "fully qualified domain

name" is provided in the DOMAIN text box.

USER - Provide the name of a domain user in the USER text box. This can be none for

Windows 2000 environments.

PASSWORD - Provide the password for the domain user specified above, in the

PASSWORD text box. This can be none for Windows 2000 environments.

CONFIRM PASSWORD – Confirm the PASSWORD by retyping it here.

CONNECTTIMEOUT - By default, this is set to 30 seconds. This implies that by default, the test

will wait for 30 seconds to establish a connecton with the target Active Directory server. If a

connection is established within the default 30 second period, then the test will report that the

server is available; if the test is unable to connect to the server within the default period, then it

will report that the server is unavailable. If it generally takes a longer time for clients to connect

to the AD server in your environment, then, you may want to change the CONNECTTIMEOUT

period so that, the test does not time out before the connection is established, and consequently

present an "untrue" picture of the availability of the server.


4

ISPASSIVE – If the value chosen is Yes, then the Oracle server under consideration is a passive

server in an Oracle cluster. No alerts will be generated if the server is not running. Measures will

be reported as “Not applicable’ by the agent if the server is not up.

5. Click the Update button in Figure 1.4, and try to signout of the eG administrative interface. A list of

unconfigured tests will appear as shown in Figure 1.5.

Figure 1.5: List of tests that are yet to be configured for the Active Directory server

6. Click on the Active Directory Checks test in Figure 1.5 to configure it.

Figure 1.6: Configuring the Active Directory Checks test

7. Specify the following in Figure 1.6.




number is 389.

DOMAINNAME, USERNAME, PASSWORD, and CONFIRM PASSWORD: In order to execute

the DCDIAG command, the eG agent has to be configured with a domain administrator's

privileges. Therefore, specify the domain name and login credentials of the domain

administrator in the DOMAINNAME, USERNAME and PASSWORD text boxes. Confirm the

PASSWORD you provide by retyping it in the CONFIRM PASSWORD text box.

DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG Enterprise suite

embeds an optional detailed diagnostic capability. With this capability, the eG agents can be

configured to run detailed, more elaborate tests as and when specific problems are detected. To

enable the detailed diagnosis capability of this test for a particular server, choose the On option.

To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if

the following conditions are fulfilled:

o The eG manager license should allow the detailed diagnosis capability

o Both the normal and abnormal frequencies configured for the detailed diagnosis

measures should not be 0.


5

8. Now, when you click on the Update button in Figure 1.6 and signout of the eG administrative interface,

you will once again be prompted to configure the Global Catalog Search test.

Figure 1.7: Configuring the Global Catalog Search test

9. Specify the following in Figure 1.7 to configure the Global Catalog Search test.




number is 389.

USERNAME - Specify the name of the user who has to be searched in the global catalog.

USERDNSDOMAIN - Specify the name of the DNS to which the specified user who has to be

searched in the global catalog belongs.

10. Click on the Update button in Figure 1.7 and signout of the eG administrative interface.

1.2 Monitoring the Active Directory Server 1. Login as a monitor / supermonitor user

2. Click on the Components option in the menu bar, and select the Servers option from the Components

menu to view the layer model, tests and measurements of the Active Directory Server.

Conf igu r ing and Mon ito r ing Exte rna l Act ive D irectory (AD) Servers

6

Configuring and Monitoring External Active Directory (AD) Servers The Active Directory server model, discussed previously, performs in-depth internal monitoring of the

health of an Active Directory server. However, sometimes, administrators might just want to receive an

"external" perspective to the health of an Active Directory server - i.e., he/she might simply want to know

whether an Active Directory server is available over the network, and if so, how quickly it responds to user

requests. Such administrators can use the External AD model instead. This section explains how to

configure and monitor the External AD server.

2.1 Administering the eG Manager to Work with an External AD Server

To administer eG so that it monitors the External AD server, do the following:

1. Login as an administrator to the eG administrative interface

2. Next, add the external AD server manually using the ADD/MODIFY COMPONENTS page (Infrastructure ->

Components -> Add/Modify) (see Figure 2.1). Components manually added will be automatically

managed by the eG Enterprise system (see Figure 2.1).

Figure 2.1: Adding an External AD server

3. Next, try to sign out of the administrative interface.

4. Upon doing so, you will be prompted to configure the Active Directory Server test for the External

Conf igu r ing and Mon ito r ing Exte rna l Act ive D irectory (AD) Servers

7

AD server (see Figure 2.2).

Figure 2.2: The list of unconfigured tests for an External AD server

5. Click on the Active Directory Server test in Figure 2.1 and proceed to configure it using the

same procedure discussed in Section 1.1 above.

6. Finally, sign out of the eG administrative interface.

2.2 Monitoring the External AD Server 1. Login as a monitor / supermonitor to the eG monitor user interface.


menu.

3. Click on the External AD server to view its measurements, tests and layer model.

Conf igu r ing and Mon ito r ing the Act ive D irecto ry (AD) C luste r Serv ice

8

Configuring and Monitoring the Active Directory (AD) Cluster Service An active directory (AD) Cluster is a collection of physical AD servers that can act as a single logical server.

Requests to a cluster are routed through a virtual cluster server that is assigned a cluster IP address and

TCP port. Requests to this server can be handled by any of the individual nodes in the cluster at any given

point in time, depending on which node is active at that time.

Since clusters are deployed in environments where 24*7 availability and responsiveness are critical, it is

imperative that the performance of the clusters is monitored all the time.

3.1 Administering the eG Manager to Work with an AD Cluster Service

To monitor an Active Directory cluster, an eG external agent is deployed, which emulates a user login to the

cluster to determine the availability of the cluster and the speed with which the cluster responds to the

emulated request. The emulated requests are directed at the virtual cluster server. Therefore, you need to

manage the virtual cluster server as an AD Cluster using the eG administrative interface. To do so, do the

following:

1. Login as an administrator to the eG administrative interface

2. Next, add the virtual cluster server in your environment as the AD cluster service using the

add/modify components page (Infrastructure -> Components -> Add/Modify) (see Figure 3.1).

Components manually added will be automatically managed by the eG Enterprise system (see Figure

3.1).


9

Figure 3.1: Adding an AD Cluster

3. Next, manage/manually add the individual Active Directory servers that form part of the cluster.

Please refer to Configuring and Monitoring Database Servers for a more elaborate discussion

on how to manage an Active Directory server.

4. Then, configure a new segment, where the AD cluster shares a USES relationship with all the

individual AD servers in the cluster (see Figure 3.2). The cluster service is deemed healthy if the user

requests are served by at least one of the servers in the cluster.

Figure 3.2: A segment containing the cluster service and the AD servers

5. Ensure that an external agent monitors the AD Custer, and internal agents are deployed on the

individual AD servers in the cluster to monitor their internal operations.

6. Finally, sign out of the administrative interface.

3.2 Monitoring the AD Cluster Service 1. Login as a monitor / supermonitor to the eG monitor user interface

2. Select the Segments option from the eG monitor menu, and click on the segment representing the

cluster being monitored; then, click on the AD Cluster component in the segment to view its

measurements, layer model and tests of the AD Cluster .


10

For an in-depth discussion on eG Enterprise's Cluster Monitoring capabilities and to

understand the implications of cluster availability on service performance, refer to the

Monitoring Clusters Using eG Enterprise chapter (Chapter 7) in the eG User Manual.

Conf igu r ing and Mon ito r ing Windows Domain Cont ro l lers

11

Configuring and Monitoring Windows Domain Controllers In this chapter, we will discuss the procedures involved in configuring and monitoring a Windows Domain

Controller.

4.1 Administering the eG Manager to work with a Windows Domain Controller

To do the above, do the following:

1. Log into the eG administrative interface.

2. If a Windows Domain Controller is already discovered, then directly proceed towards managing it using

the COMPONENTS - MANAGE/UNMANAGE page (Infrastructure-> Components -> Manage/Unmanage).

However, if it is yet to be discovered, then run discovery (Infrastructure -> Components -> Discover)

to get it discovered or add the controller manually using the ADD/MODIFY COMPONENTS page

(Infrastructure -> Components -> Add/Modify). Remember that components manually added are

managed automatically. Discovered components, however, are managed using the COMPONENTS -

MANAGE/UNMANAGE page.Figure 4.1 and Figure 4.2 clearly illustrate the process of managing a

Windows Domain Controller.

For more details on managing components, refer to Configuring and Managing Web Servers

document.


12

Figure 4.1: Selecting the Windows Domain Controller to manage

Figure 4.2: Managing the Windows Domain Controller

5. Try to signout of the eG administrative interface. Figure 4.3 then appears prompting you to configure

the Window Authentication test.


13

Figure 4.3: List of unconfigured tests for an Domain Controller server

6. To configure this test, click on the test name in Figure 4.3. then appears.

Figure 4.4: Configuring the Window Authentication test





number is 389.

DOMAIN - The default value of the DOMAIN parameter will be none. In Windows 2003

environments however, the WindowAuthenticationTest will function effectively only if a "fully

qualified domain name" is provided in the DOMAIN text box.

USER - Provide the name of a domain user in the USER text box. This can be none for Windows

2000 environments.

PASSWORD - Provide the password for the domain user specified above, in the

PASSWORD text box. This can be none for Windows 2000 environments.

CONFIRM PASSWORD – Confirm the PASSWORD by retyping it here.

8. Click the Update button in Figure 4.4, and finally, exit the administrative interface.

4.2 Monitoring the Windows Domain Controller To monitor the Windows Domain Controller, do the following:

1. Login as a monitor / supermonitor user.


menu.

3. From the Components page, click on the Windows Domain Controller for which you wish to view


14

measurements.

Conf igu r ing and Mon ito r ing the Windows In ternet Name Serv ice (WINS)

15

Configuring and Monitoring the Windows Internet Name Service (WINS) This chapter illustrates the process of configuring and monitoring the Windows Internet Name Service or

WINS.

5.1 Administering the eG Manager to work with a WINS Server



2. If a WINS server is already discovered, then directly proceed towards managing it using the

COMPONENTS - MANAGE/UNMANAGE page (Infrastructure -> Components -> Manage/Unmanage).

However, if it is yet to be discovered, then run discovery (Infrstructure -> Components -> Discover) to

get it discovered or add the WINS server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 5.1 and Figure 5.2 clearly illustrate the process of managing a WINS

server.

For more details on managing components, refer to Configuring and Managing Web Servers

document.


16

Figure 5.1: Selecting the WINS server to manage

Figure 5.2: Managing the WINS server

3. Next, sign out of the eG administrative interface. Then Figure 5.3 appears prompting you to configure

the Windows Processes test.


17

Figure 5.3: List of unconfigured tests for an WindowsProcesses test

4. To configure this test, click on the test name in Figure 5.3, then Figure 5.4 appears.

Figure 5.4: Configuring the Windows Processes test



HOST - The host for which the test is to be configured

PORT - The port to which the specified HOST listens

PROCESS - In the PROCESS text box, enter a comma separated list of names:pattern pairs

which identify the process(es) associated with the server being considered. processName is a

string that will be used for display purposes only. processPattern is an expression of the form -

*expr* or expr or *expr or expr* or *expr1*expr2*... or expr1*expr2, etc. A leading '*' signifies

any number of leading characters, while a trailing '*' signifies any number of trailing characters.

For example, to monitor the Word and Powerpoint applications on a system, in the PROCESS

text box, enter officeProcess:*winword*,*power*, where * denotes zero or more characters.

WIDE - This parameter is valid on Solaris and Windows systems only.

On Solaris environments, if the value of the WIDE parameter is true, the eG agent will use

usr/ucb/ps instead of /usr/bin/ps to search for processes executing on the host.

/usr/ucb/ps provides a long output (> 80 characters), whereas /usr/bin/ps only outputs

the first 80 characters of the process path and its arguments. However, some Solaris systems

are configured with tightened security, which prevents the usr/ucb/ps command to be

executed by any and every user to the system - in other words, only pre-designated users will

be allowed to execute this command. The sudo (superuser do) utility (see

http://www.gratisoft.us/sudo/) can be used to allow designated users to execute this command.

If your system uses sudo to restrict access to the /usr/ucb/ps command, then specify the

value of the "wide" parameter to be "sudo". This will ensure that not only does the agent use

the /usr/ucb/ps command to monitor processes (like it would do if the "wide" parameter

were set to be true), but it would also use sudo to execute this command.

http://www.gratisoft.us/sudo/


18

On Windows environments, by default, the eG agent uses perfmon to search for the processes

that match the configured patterns. Accordingly, the WIDE parameter is set to false by default.

Typically, a process definition in Windows includes the full path to the process, the process

name, and process arguments (if any). Perfmon however scans the system only for

process names that match the configured patterns – in other words, the process path and

arguments are ignored by perfmon. This implies that if multiple processes on a Windows host

have the same name as specified against PROCESSPATTERN, then perfmon will only be able

to report the overall resource usage across all these processes; it will not provide any pointers to

the exact process that is eroding the host’s resources. To understand this better, consider the

following example. Typically, Windows represents any Java application executing on it as

java.exe. Say, two Java applications are executing on a Windows host, but from different

locations. If java.exe has been configured for monitoring, then by default, perfmon will report

the availability and average resource usage of both the Java applications executing on the host.

If say, one Java application goes down, then perfmon will not be able to indicate accurately

which of the two Java applications is currently inaccessible. Therefore, to enable administrators

to easily differentiate between processes with the same name, and to accurately determine

which process is unavailable or resource-hungry, the eG agent should be configured to perform

its process searches based on the process path and/or process arguments, and not just on the

process name – in other words, the eG agent should be configured not to use perfmon.

To achieve this, first, set the WIDE parameter to true. This will instruct the eG agent to not use

perfmon to search for the configured process patterns. Once this is done, then, you can

proceed to configure a PROCESSPATTERN that includes the process arguments and/or the

process path, in addition to the process name. For instance, if both the Remote Access

Connection Manager service and the Terminal Services service on a Windows host, which

share the same name – svchost - are to be monitored as two different processes, then your

PROCESSPATTERN specification should be as follows:

Terminal:C:\WINDOWS\System32\svchost -k

DcomLaunch,Remote:C:\WINDOWS\system32\svchost.exe -k netsvcs

You can also use wildcard characters, wherever required. For instance, in the above case, your

PROCESSPATTERN can also be:

Terminal:*svchost -k DcomLaunch,Remote:*svchost.exe -k netsvcs

Similarly, to distinctly monitor two processes having the same name, but operating from

different locations, your specification can be:

JavaC:c:\javaapp\java.exe,JavaD:d:\app\java.exe

Before including process paths and/or arguments in your PROCESSPATTERN

configuration, make sure that the WIDE parameter is set to true. If not, the test will

not work.

If your PROCESSPATTERN configuration includes a process path that refers to

the Program Files directory, then make sure that you do not a include a ~ (tilde)

while specifying this directory name. For instance, your PROCESSPATTERN

specification should not be say, Adobe:C:\Progra~1\Adobe\AcroRd32.exe.


19






The option to selectively enabled/disable the detailed diagnosis capability will be available only if





6. Click the Update button in Figure 5.4, and finally, exit the administrative interface.

5.2 Monitoring the WINS Server To monitor the WINS server, do the following:



menu.

3. From the Components page, click on the WINS server for which you wish to view measurements.

Conf igu r ing and Mon ito r ing Termina l Se rver

20

Configuring and Monitoring Terminal Server This chapter explains the process of configuring and monitoring Terminal servers.

6.1 Administering the eG Manager to work with Terminal servers



2. If a Terminal server is already discovered, then directly proceed towards managing it using the



to get it discovered or add the Terminal server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 6.1 and Figure 6.2 clearly illustrate the process of managing a WINS

server.

For more details on managing components, refer to Configuring and Monitoring Web Servers

document.


21

Figure 6.1: Selecting the Terminal server to manage

Figure 6.2: Managing the Terminal server

3. Next, try to sign out of the eG administrative interface. Doing so will result in the LIST OF

UNCONFIGURED TESTS listing the unconfigured tests of the Terminal server (see Figure 6.3).


22

Figure 6.3: Unconfigured tests of the Terminal server

4. Now, click on the TerminalAuthentication test in Figure 6.3 to configure it. From the AGENT – TESTS -

SPECIFIC CONFIGURATION page that follows, configure the test as shown in Figure 6.4.

Figure 6.4: Configuring the TerminalAuthentication test

5. The TerminalAuthentication test emulates a user logging into a Windows domain or local host and

reports whether the login succeeded and how long it took. Now, specify the following in Figure 6.4:

TEST PERIOD – How often should the test be executed

HOST – The host for which the test is to be configured

PORT – Refers to the port used by the Terminal server

USERNAME - This test emulates a user logging into a Microsoft Windows domain or a local host.

Therefore, specify the login name of the user here.

PASSWORD - Enter the password that corresponds to the specified USERNAME.

CONFIRM PASSWORD – Confirm the password by retyping it here.

DOMAIN - Specify the name of the domain to which the test will try to login. If the test is to login

to a local host, specify 'none' here. Multiple user names, passwords, and domains can be

specified, separated by a comma.

REPORT BY DOMAIN - By default, this flag is set to Yes. This implies that by default, this test

will report metrics for every domainname\username configured for this test. This way,

administrators will be able to quickly determine which user logged in from which domain. If you

want the detailed diagnosis to display the username alone, then set this flag to No.

6. Finally, click the Update button.

7. Now, sign out of the administrative interface.


23

6.2 Monitoring the Terminal Server To monitor the Terminal server, do the following:



menu.

3. From the Components page that appears next, click on the MicrosoftTerminal server for which you

wish to view measurements.

Conf igu r ing and Mon ito r ing B izTa lk Server 2000

24

Configuring and Monitoring BizTalk Server 2000 This chapter discusses the procedures involved in configuring and monitoring a BizTalk server.

7.1 Administering the eG Manager to work with a BizTalk Server



2. The BizTalk server cannot be discovered by the eG Enterprise system. Therefore, proceed to add it

using the ADD/MODIFY - COMPONENTS page that appears when the menu sequence, Infrastructure ->

Components -> Add/Modify is followed. Remember that components manually added are managed

automatically. Discovered components, however, are managed using the COMPONENTS -

MANAGE/UNMANAGE page. Figure 7.1 clearly illustrates the process of adding a BizTalk server2000

component.

For more details on managing components, refer to Configuration and Monitoring Web

Servers document.

Conf igu r ing and Mon ito r ing B izTa lk Server 2000

25

Figure 7.1:Adding a new BizTalk component

3. Next, sign out of the eG administrative interface.

7.2 Monitoring the BizTalk Server To monitor the BizTalk server, do the following:



menu.

3. From the Components page, click on the BizTalk server for which you wish to view measurements.

Conf igu r ing and Mon ito r ing B izTa lk server2010

26

Configuring and Monitoring BizTalk server2010 In this chapter, we will discuss the procedures involved in configuring and monitoring a BizTalk server2010.

8.1 Administering the eG Manager to work with a BizTalk server2010



2. The BizTalk server2010 cannot be discovered by the eG Enterprise system. Therefore, proceed to add

it using the ADD/MODIFY - COMPONENTS page that appears when the menu sequence, Infrastructure ->



MANAGE/UNMANAGE page. Figure 8.1 clearly illustrates the process of adding a BizTalk server2010

component.

For more details on managing components, refer to Configuration and Monitoring Web

Servers document.

Conf igu r ing and Mon ito r ing B izTa lk server2010

27

Figure 8.1:Adding a new BizTalk server2010 component


8.2 Monitoring the BizTalk server2010 To monitor the BizTalk server2010, do the following:



menu.

3. From the Components page, click on the BizTalk server2010 for which you wish to view the

measurements.

Conf igu r ing and Mon ito r ing DHCP Servers

28

Configuring and Monitoring DHCP Servers In this chapter, we will discuss the procedures involved in configuring and monitoring a DHCP server.

9.1 Administering the eG Manager to work with a DHCP Server



2. If a DHCP server is already discovered, then directly proceed towards managing it using the



to get it discovered or add the DHCP server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 9.1 and Figure 9.2 clearly illustrate the process of managing a DHCP

server.

To know more about how to configure this component, refer to the eG Installation Guide. For

more details on managing components, refer to Configuration and Monitoring Web Servers

document.


29

Figure 9.1: Viewing the list of unmanaged DHCP servers

Figure 9.2: Managing a DHCP server


9.2 Monitoring the DHCP Server To monitor the DHCP server, do the following:


30



menu.

3. From the Components page, click on the DHCP server for which you wish to view measurements.

Conf igu r ing and Mon ito r ing Microsof t Proxy Serve rs

31

Configuring and Monitoring Microsoft Proxy Servers This chapter delineates the process of configuring and monitoring MS Proxy servers.

10.1 Administering the eG Manager to work with a Microsoft Proxy Server



2. If a MS Proxy server is already discovered, then directly proceed towards managing it using the



to get it discovered or add the MS Proxy server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 10.1 and Figure 10.2 clearly illustrate the process of managing an

Microsoft Proxy server.


document.


32

Figure 10.1: Viewing the list of unmanaged Microsoft Proxy servers

Figure 10.2: Managing an Micosoft Proxy server



33

10.2 Monitoring the Microsoft Proxy Server To monitor the Microsoft Proxy server, do the following:



menu.

3. From the Components page, click on the Microsoft Proxy server for which you wish to view

measurements.

Conf igu r ing and Mon ito r ing MS Pr int Se rvers

34

Configuring and Monitoring MS Print Servers This chapter explains the process of configuring and monitoring MS Print servers.

11.1 Administering the eG Manager to work with an MS Print Server



2. If an MS Print server is already discovered, then directly proceed towards managing it using the



to get it discovered or add the MS Print server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 11.1 and Figure 11.2 clearly illustrate the process of managing an MS

Print server.


document.


35

Figure 11.1: Viewing the list of unmanaged MS Print servers

Figure 11.2: Managing an MS Print server


11.2 Monitoring the MS Print Server To monitor the Microsoft Print server, do the following:



36


menu.

3. From the Components page, click on the Microsoft Print server for which you wish to view

measurements.

Conf igu r ing and Mon ito r ing MS F i le Se rvers

37

Configuring and Monitoring MS File Servers This chapter explains the procedures involved in configuring and monitoring an MS File server.

12.1 Administering the eG Manager to Monitor an MS File Server



2. If an MS File server is already discovered, then directly proceed towards managing it using the



to get it discovered or add the MS File server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 12.1 and Figure 12.2 clearly illustrate the process of managing an MS

File server.


document.


38

Figure 12.1: Viewing the list of unmanaged MS File servers

Figure 12.2: Managing an MS File server


12.2 Monitoring the MS File Server To monitor the Microsoft File server, do the following:



menu.

3. From the Components page, click on the Microsoft File server for which you wish to view


39

measurements.

Conf igu r ing and Mon ito r ing ISA Proxy Serve rs

40

Configuring and Monitoring ISA Proxy Servers This chapter discusses the procedures involved in configuring and monitoring ISA Proxy servers.

13.1 Administering the eG Manager to Work with the ISA Proxy Server



2. If an ISA Proxy server is already discovered, then directly proceed towards managing it using the


However, if it is yet to be discovered, then run discovery (Infrastructure-> Components -> Discover)

to get it discovered or add the ISA Proxy server manually using the ADD/MODIFY COMPONENTS page



MANAGE/UNMANAGE page. Figure 13.1 and Figure 13.2 clearly illustrate the process of managing an

ISA Proxy server.


document.


41

Figure 13.1: Viewing the list of unmanaged ISA Proxy servers

Figure 13.2: Managing an ISA Proxy serverList of unconfigured test for the ISA Proxy server

3. Next, sign out of the eG administrative interface. then Figure 13.3 appears prompting you to configure

the ISA Proxy server test.

Figure 13.3:List of unconfigured test for the ISA Proxy server

4. To configure this test, click on the test name in Figure 13.3, then Figure 13.4 appears .


42

Figure 13.4: Configuring of the Windows Processes test

5. Specify the following in Figure 13.4 .



PORT - The port to which the specified HOST listens

PROCESS - In the PROCESS text box, enter a comma separated list of names:pattern pairs

which identify the process(es) associated with the server being considered. processName is a

string that will be used for display purposes only. processPattern is an expression of the form -

*expr* or expr or *expr or expr* or *expr1*expr2*... or expr1*expr2, etc. A leading '*' signifies

any number of leading characters, while a trailing '*' signifies any number of trailing characters.

For example, to monitor the Word and Powerpoint applications on a system, in the PROCESS

text box, enter officeProcess:*winword*,*power*, where * denotes zero or more characters.

WIDE - This parameter is valid on Solaris and Windows systems only.

On Solaris environments, if the value of the WIDE parameter is true, the eG agent will use

usr/ucb/ps instead of /usr/bin/ps to search for processes executing on the host.

/usr/ucb/ps provides a long output (> 80 characters), whereas /usr/bin/ps only outputs

the first 80 characters of the process path and its arguments. However, some Solaris systems

are configured with tightened security, which prevents the usr/ucb/ps command to be

executed by any and every user to the system - in other words, only pre-designated users will

be allowed to execute this command. The sudo (superuser do) utility (see

http://www.gratisoft.us/sudo/) can be used to allow designated users to execute this command.

If your system uses sudo to restrict access to the /usr/ucb/ps command, then specify the

value of the "wide" parameter to be "sudo". This will ensure that not only does the agent use

the /usr/ucb/ps command to monitor processes (like it would do if the "wide" parameter

were set to be true), but it would also use sudo to execute this command.

On Windows environments, by default, the eG agent uses perfmon to search for the processes

that match the configured patterns. Accordingly, the WIDE parameter is set to false by default.

Typically, a process definition in Windows includes the full path to the process, the process

name, and process arguments (if any). Perfmon however scans the system only for

process names that match the configured patterns – in other words, the process path and

arguments are ignored by perfmon. This implies that if multiple processes on a Windows host

have the same name as specified against PROCESSPATTERN, then perfmon will only be able

to report the overall resource usage across all these processes; it will not provide any pointers to

the exact process that is eroding the host’s resources. To understand this better, consider the

following example. Typically, Windows represents any Java application executing on it as

http://www.gratisoft.us/sudo/


43

java.exe. Say, two Java applications are executing on a Windows host, but from different

locations. If java.exe has been configured for monitoring, then by default, perfmon will report

the availability and average resource usage of both the Java applications executing on the host.

If say, one Java application goes down, then perfmon will not be able to indicate accurately

which of the two Java applications is currently inaccessible. Therefore, to enable administrators

to easily differentiate between processes with the same name, and to accurately determine

which process is unavailable or resource-hungry, the eG agent should be configured to perform

its process searches based on the process path and/or process arguments, and not just on the

process name – in other words, the eG agent should be configured not to use perfmon.

To achieve this, first, set the WIDE parameter to true. This will instruct the eG agent to not use

perfmon to search for the configured process patterns. Once this is done, then, you can

proceed to configure a PROCESSPATTERN that includes the process arguments and/or the

process path, in addition to the process name. For instance, if both the Remote Access

Connection Manager service and the Terminal Services service on a Windows host, which

share the same name – svchost - are to be monitored as two different processes, then your

PROCESSPATTERN specification should be as follows:

Terminal:C:\WINDOWS\System32\svchost -k

DcomLaunch,Remote:C:\WINDOWS\system32\svchost.exe -k netsvcs

You can also use wildcard characters, wherever required. For instance, in the above case, your

PROCESSPATTERN can also be:

Terminal:*svchost -k DcomLaunch,Remote:*svchost.exe -k netsvcs

Similarly, to distinctly monitor two processes having the same name, but operating from

different locations, your specification can be:

JavaC:c:\javaapp\java.exe,JavaD:d:\app\java.exe

Before including process paths and/or arguments in your PROCESSPATTERN

configuration, make sure that the WIDE parameter is set to true. If not, the test will

not work.

If your PROCESSPATTERN configuration includes a process path that refers to the

Program Files directory, then make sure that you do not a include a ~ (tilde) while

specifying this directory name. For instance, your PROCESSPATTERN specification

should not be say, Adobe:C:\Progra~1\Adobe\AcroRd32.exe.






The option to selectively enabled/disable the detailed diagnosis capability will be available only if





44


6. Click on the Update button and signout of the eG administrative interface.

13.2 Monitoring the ISA Proxy Server To monitor the ISA Proxy server, do the following:



menu.

3. From the Components page, click on the ISA Proxy server for which you wish to view measurements.

Conf igu r ing and Mon ito r ing Microsof t Radius Servers

45

Configuring and Monitoring Microsoft Radius Servers Internet Authentication Service (IAS) in Microsoft® Windows Server™ is the Microsoft implementation of a

Remote Authentication Dial-In User Service (RADIUS) server and proxy. As a RADIUS server, IAS performs

centralized connection authentication, authorization, and accounting for many types of network access,

including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and

router-to-router connections. As a RADIUS proxy, IAS forwards authentication and accounting messages to

other RADIUS servers.

This chapter deals with the procedure for configuring and monitoring the IAS server.

14.1 Administering the eG Manager to Work with the Microsoft Radius Server



2. The IAS server cannot be discovered by the eG Enterprise system. Therefore, proceed to add it using

the ADD/MODIFY COMPONENTS page that appears when the menu sequence, Infratructure ->



MANAGE/UNMANAGE page. Figure 14.1 clearly illustrates the process of adding an Microsoft Radius

server.


document.

Conf igu r ing and Mon ito r ing Microsof t Radius Servers

46

Figure 14.1: Adding a Microsoft Radius server


14.2 Monitoring the Microsoft Radius Server To monitor the Microsoft Radius server, do the following:



menu.

3. From the Components page, click on the Micosoft Radius server for which you wish to view

measurements.

Conf igu r ing and Mon ito r ing the M icrosof t Remote Authent ica t ion Service (RAS)

47

Configuring and Monitoring the Microsoft Remote Authentication Service (RAS) Microsoft Remote Access Service (RAS) is a feature in the Windows Server family, including Windows Server

2003, Windows 2000 Server, and , NT4 Server. A Limited version of RAS is also included in Windows XP

Professional. RAS allows remote dial-up clients to connect to a Local Area Network using analog phone lines

or ISDN lines. A typical use would be by an ISP (Internet Service Provider) to allow users to dial in to their

LAN, or by a corporate network administrator to allow their users to connect to the corporate LAN from

remote sites. The remote clients connect to RAS using the TCP/IP protocol encapsulated in the Point-to-

Point (PPP) protocol, which allows the remote client to access the LAN as if they were plugged directly into

it.

This chapter deals with the procedure for configuring and monitoring the RAS server.

15.1 Administering the eG Manager to Work with the MS RAS Server



2. The RAS server cannot be discovered by the eG Enterprise system. Therefore, proceed to add it using

the ADD/MODIFY - COMPONENTS page that appears when the menu sequence, Infrastructure ->



MANAGE/UNMANAGE page. Figure 15.1 clearly illustrates the process of adding an RAS server.


document.

Conf igu r ing and Mon ito r ing the M icrosof t Remote Authent ica t ion Service (RAS)

48

Figure 15.1: Adding a Microsoft RAS server


15.2 Monitoring the Microsoft RAS Server To monitor the Microsoft RAS server, do the following:



menu.

3. From the Components page, click on the Microsoft RAS server for which you wish to view

measurements.

Conf igu r ing and Mon ito r ing Windows C luster

49

Configuring and Monitoring Windows Cluster This chapter deals with the steps involved in configuring and monitoring Windows clusters.

Unlike other component-types, eG Enterprise does not offer a specialized monitoring model for monitoring

Windows clusters. If a Windows-based application (eg., IIS Web, MS SQL database, Citrix Presentation

server, etc.) that is being monitored functions within a Windows cluster, then eG Enterprise provides

administrators the option to monitor the health of the cluster service as well by including an additonal

Windows Cluster layer to the layer model of the Windows-based application. For instance, if you are

monitoring an IIS web server that is operating on a Windows host that is part of a cluster, and you wish to

know how well the cluster service is performing, then you can proceed to associate the Windows Cluster

layer to the layer model of the IIS web server. The steps for achieving this are detailed below.

1. Follow the menu sequence, IntegrationConsole -> Components to open the INTEGRATIONCONSOLE-

COMPONENT page . Now choose the Config Layer button corresponding to IIS Web server from the PRE-

DEFINED SERVERS (see Figure 16.1 ).

Figure 16.1: Selecting the config layer of the IIS Web server

2. Now select the Windows Cluster from the DISASSOCIATED LAYERS as depicted in the Figure 16.2 .


50

Figure 16.2: Selecting the Windows Cluster from the Disassociated Layers

3. Next, click on Associate to associate the Windows Cluster to as the top layer of IIS web server’s

monitoring model. Now, click on Update to register the changes. (see Figure 16.3).

Figure 16.3: Associating the Windows Cluster to the top layer of the IIS Webserver

4. If you now navigate to the AGENTS-TESTS SPECIFIC CONFIGURATION page (using the menu sequence

Agents -> Tests -> Configure -> Specific), and view the tests available for an IIS web server, you will

find that as a result of associating the Windows Cluster layer to the IIS Web server, a few cluster-

related tests are visible along with the web server-specific tests. (see Figure 16.4).


51

Figure 16.4: Viewing the Cluster related tests in the Agents-Tests Configuration page

5. Since the cluster tests are configured by default, just sign out of the eG administrative interface by

clicking on the Signout button at the right, top corner of the interface.

16.1 Monitoring the Windows Cluster Server To monitor the Windows Cluster server, do the following:



menu.

3. Yow will see the Windows Cluster as the first layer of the IIS Web server in the Components page.

From the Components page, click on the Windows Cluster server for which you wish to view tests and

measurements.

Conf igu r ing and Mon ito r ing Microsof t Fast Search Server

52

Configuring and Monitoring Microsoft Fast Search Server This chapter deals with the steps involved in the configuring and monitoring the Microsoft Fast Search

Server.

17.1 Administering the eG Manager to monitor a Microsoft Fast Search Server

To administer the eG Manager to monitor the Microsoft Fast Search Server, do the following:


2. eG Enterprise cannot automatically discover the Microsoft Fast Search Server. You need to manually

add the server using the ADD/MODIFY COMPONENTS page (see Figure 17.1) that appears when the

Infrastructure -> Components -> Add/Modify menu sequence is followed. Remember that components

manually added are managed automatically.

Figure 17.1: Adding the Microsoft Fast Search Server

3. When you attempt to sign out, a list of unconfigured tests appears as shown in Figure 17.2.


53

Figure 17.2: List of unconfigured tests to be configured for the Microsoft Fast Search Server

4. Click on the Log Monitor test in Figure 17.2 to configure it.

Figure 17.3: Configuring the Log Monitor test

5. To configure the test, specify the following in Figure 17.3.



PORT– The port at which the server listens

LINES– Specify two numbers in the format x:y. This means that when a line in the log file

matches a particular pattern, then x lines before the matched line and y lines after the matched

line will be reported in the detail diagnosis output (in addition to the matched line). The default

value here is 0:0. Multiple entries can be provided as a comma-separated list.

If you give 1:1 as the value for LINES, then this value will be applied to all the patterns specified

in the SEARCHPATTERN field. If you give 0:0,1:1,2:1 as the value for LINES and if the

corresponding value in the SEARCHPATTERN field is like ORA:ORA-

*,offline:*offline*,online:*online then:

0:0 will be applied to ORA:ORA-* pattern


54

1:1 will be applied to offline:*offline* pattern

2:1 will be applied to online:*online pattern

ROTATINGFILE– This flag governs the display of descriptors for this test in the eG monitoring

console.

If this flag is set to true and the ALERTFILE text box contains the full path to a specific

(log/text) file, then, the descriptors of this test will be displayed in the following format:

Directory_containing_monitored_file:<SearchPattern>. For instance, if the ALERTFILE

parameter is set to c:\eGurkha\logs\syslog.txt, and ROTATINGFILE is set to true, then, your

descriptor will be of the following format: c:\eGurkha\logs:<SearchPattern>. On the other

hand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of the

following format: <FileName>:<SearchPattern> - i.e., syslog.txt:<SearchPattern> in

the case of the example above

If this flag is set to true and the ALERTFILE parameter is set to the directory containing log files,

then, the descriptors of this test will be displayed in the format:

Configured_directory_path:<SearchPattern>. For instance, if the ALERTFILE parameter is

set to c:\eGurkha\logs, and ROTATINGFILE is set to true, then, your descriptor will be:

c:\eGurkha\logs:<SearchPattern>. On the other hand, if the ROTATINGFILE parameter had

been set to false, then the descriptors will be of the following format:

Configured_directory:<SearchPattern> - i.e., logs:<SearchPattern> in the case of the

example above.

If this flag is set to true and the ALERTFILE parameter is set to a specific file pattern, then, the

descriptors of this test will be of the following format: <FilePattern>:<SearchPattern>. For

instance, if the ALERTFILE parameter is set to c:\eGurkha\logs\*sys*, and ROTATINGFILE is

set to true, then, your descriptor will be: *sys*:<SearchPattern>. In this case, the descriptor

format will not change even if the ROTATINGFILE flag status is changed.

ALERTFILE –Specify the path to the log file to be monitored. For eg., /user/john/new_john.log.

Multiple log file paths can be provided as a comma-separated list - eg.,

/user/john/critical_egurkha.log,/tmp/log/major.log.

Also, instead of a specific log file path, the path to the directory containing log files can be

provided - eg., /user/logs. This ensures that eG Enterprise monitors the most recent log files in

the specified directory. Specific log file name patterns can also be specified. For example, to

monitor the latest log files with names containing the strings 'dblogs' and 'applogs', the

parameter specification can be, /tmp/db/*dblogs*,/tmp/app/*applogs*. Here, '*' indicates

leading/trailing characters (as the case may be). In this case, the eG agent first enumerates all

the log files in the specified path that match the given pattern, and then picks only the latest log

file from the result set for monitoring.

Your ALERTFILE specification can also be of the following format:

Name@logfilepath_or_pattern. Here, Name represents the display name of the path being

configured. Accordingly, the parameter specification for the 'dblogs' and 'applogs' example

discussed above can be: dblogs@/tmp/db/*dblogs*,applogs@/tmp/app/*applogs*. In this case,

the display names 'dblogs' and 'applogs' will alone be displayed as descriptors of this test.

Every time this test is executed, the eG agent verifies the following:

o Whether any changes have occurred in the size and/or timestamp of the log files that

were monitoring during the last measurement period;

o Whether any new log files (that match the ALERTFILE specification) have been newly

added since the last measurement period;

If a few lines have been added to a log file that was monitored previously, then the eG agent


55

monitors the additions to that log file, and then proceeds to monitor newer log files (if any). If

an older log file has been overwritten, then, the eG agent monitors this log file completely, and

then proceeds to monitor the newer log files (if any).

OVERWRITTENFILE – By default, this flag is set to false. Set this flag to true if you want the test

to support the 'roll over' capability of the specified ALERTFILE. A roll over typically occurs when

the timestamp of a file changes or when the log file size crosses a pre-determined threshold.

When a log file rolls over, the errors/warnings that pre-exist in that file will be automatically

copied to a new file, and all errors/warnings that are captured subsequently will be logged in the

original/old file. For instance, say, errors and warnings were originally logged to a file named

messages. When a roll over occurs, the content of the file messages will be copied to a file

named messages.1, and all new errors/warnings will be logged in messages. In such a

scenario, since the OVERWRITTENFILE flag is set to false by default, the test by default scans

only messages.1 for new log entries and ignores messages. On the other hand, if the flag is

set to true, then the test will scan both messages and messages.1 for new entries.

If you want this test to support the 'roll over' capability described above, the following conditions

need to be fulfilled:

The ALERTFILE parameter has to be configured only with the name and/or path of

one/more alert files. File patterns or directory specifications should not be specified in

the ALERTFILE text box.

The roll over file name should be of the format: “<ALERTFILE>.1”, and this file must

be in the same directory as the ALERTFILE.

SEARCHPATTERN – Enter the specific patterns of messages to be monitored. The pattern

should be in the following format: <PatternName>:<Pattern>, where <PatternName> is the

pattern name that will be displayed in the monitor interface and <Pattern> is an expression of

the form - *expr* or expr or *expr or expr*, etc. A leading '*' signifies any number of leading

characters, while a trailing '*' signifies any number of trailing characters.

For example, say you specify ORA:ORA-* in the SEARCHPATTERN text box. This indicates that

"ORA" is the pattern name to be displayed in the monitor interface. "ORA-*" indicates that the

test will monitor only those lines in the log file which start with the term "ORA-". Similarly, if your

pattern specification reads: offline:*offline, then it means that the pattern name is offline and

that the test will monitor those lines in the log file which end with the term offline.

A single pattern may also be of the form e1+e2, where + signifies an OR condition. That is, the

<PatternName> is matched if either e1 is true or e2 is true.

Multiple search patterns can be specified as a comma-separated list. For example: ORA:ORA-

*,offline:*offline*,online:*online

If the ALERTFILE specification is of the format Name@logfilepath, then the descriptor for this

test in the eG monitor interface will be of the format: Name:PatternName. On the other hand,

if the ALERTFILE specification consists only of a comma-separated list of log file paths, then the

descriptors will be of the format: LogFilePath:PatternName.

Also, if a comma-separated list of alert files is provided in the ALERTFILE text box in the format

Name@logfilepath, and you want to monitor one/more specific patterns of logs in each alert

file, then your specification would be of the format:

Name@<PatternName>:<Pattern>

For instance, say, your ALERTFILE specification is as follows:

dblogs@/tmp/db/*dblogs*,applogs@/tmp/app/*applogs*. Now, assume that you want

to monitor the following entries in the specified alert files:


56

Alert file Pattern

dblogs *error*

dblogs Ora*

applogs *warning

applogs *ora-info*

The SEARCHPATTERN specification in this case will hence be as follows:

dblogs@error:*error*,dblogs@ora:ora*,applogs@warning:*warning,

applogs@info:*ora-info*

If you want all the messages in a log file to be monitored, then your specification would be:

<PatternName>:*.

USEUTF8 – If UTF-8 encoding is to be used for reading the specified log file, then, set the

USEUTF8 flag to true. By default, this flag is set to false. If multiple log files are being

monitored, then, for each file, you will have to indicate whether UTF-8 encoding is to be used for

reading that file or not. For instance, assume that the ALERTFILE parameter is set to

dblogs@/tmp/db/*dblogs*,applogs@/tmp/app/*applogs*. Now, to instruct the test to use UTF-8

encoding for reading the 'dblogs' log file and not to use the UTF-8 encoding while reading the

'applogs' log file, your USEUTF8 setting should be as follows: true,false. Note that the number

of values provided against the USEUTF8 parameter should be equal to the number of log files

being monitored. Also, note that if the ALERTFILE being monitored has BOM, then the test will

automatically use UTF-8 encoding to read that file, even if the USEUTF8 flag is set to false.

EXCLUDEPATTERN – Provide a comma-separated list of patterns to be excluded from

monitoring in the EXCLUDEPATTERN text box. For example *critical*,*exception*. By default,

this parameter is set to 'none'.

UNIQUEMATCH – By default, the UNIQUEMATCH parameter is set to false, indicating that, by

default, the test checks every line in the log file for the existence of each of the configured

SEARCHPATTERNS. By setting this parameter to true, you can instruct the test to ignore a line

and move to the next as soon as a match for one of the configured patterns is found in that line.

For example, assume that Pattern1:*fatal*,Pattern2:*error* is the SEARCHPATTERN that has

been configured. If UNIQUEMATCH is set to false, then the test will read every line in the log file

completely to check for the existence of messages embedding the strings 'fatal' and 'error'. If

both the patterns are detected in the same line, then the number of matches will be incremented

by 2. On the other hand, if UNIQUEMATCH is set to true, then the test will read a line only until a

match for one of the configured patterns is found and not both. This means that even if the

strings 'fatal' and 'error' follow one another in the same line, the test will consider only the first

match and not the next. The match count in this case will therefore be incremented by only 1.

CASESENSITIVE – This flag is set to No by default. This indicates that the test functions in a

'case-insensitive' manner by default. This implies that, by default, the test ignores the case of

your ALERTFILE and SEARCHPATTERN specifications. If this flag is set to Yes on the other

hand, then the test will function in a 'case-sensitive' manner. In this case therefore, for the test

to work, even the case of your ALERTFILE and SEARCHPATTERN specifications should match

with the actuals.

DD FREQUENCY – Refers to the frequency with which detailed diagnosis measures are to be

generated for this test. The default is 1:1. This indicates that, by default, detailed measures will

be generated every time this test runs, and also every time the test detects a problem. You can

modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis

capability for this test, you can do so by specifying none against DD FREQUENCY.


57

ENCODEFORMAT – By default, this is set to none, indicating that no encoding format applies by

default. However, if the test has to use a specific encoding format for reading from the specified

ALERTFILE , then you will have to provide a valid encoding format here - eg., UTF-8, UTF-16,

etc. Where multiple log files are being monitored, you will have to provide a comma-separated

list of encoding formats – one each for every log file monitored. Make sure that your encoding

format specification follows the same sequence as your ALERTFILE specification. In other words,

the first encoding format should apply to the first alert file, and so on. For instance, say that your

alertfile specification is as follows: D:\logs\report.log,E:\logs\error.log, C:\logs\warn_log. Assume

that while UTF-8 needs to be used for reading from report.log , UTF-16 is to be used for reading

from warn_log . No encoding format need be applied to error.log. In this case, your

ENCODEFORMAT specification will be: UTF-8,none,UTF-16.

DETAILED DIAGNOSIS – To make diagnosis more efficient and accurate, the eG Enterprise suite





The option to selectively enable/disable the DETAILED DIAGNOSIS capability will be available

only if the following conditions are fulfilled:




6. Then, click the Update button in Figure 17.3 , to save the changes.

7. Next, when you signout of the administrative interface, the list of unconfigured tests page will appear

requiring you to configure the Windows Services test.

8. Click on the Windows Services test to configure it.

Figure 17.4: Configuring the Windows services test

9. To configure the test, specify the following in Figure 17.4:



PORT– The port at which the server listens


58

SERVICENAME – Name of the service that is to be checked. More than one service name can

also be provided with comma as the separator.

Note:

When monitoring an MS SQL server, the SERVICE parameter will be set to MSSQLServer by

default. However, if the MS SQL server being monitored was installed using a named instance,

the SQL service name will change. In such a case therefore, ensure that the SERVICE parameter

is reconfigured to reflect the correct service name.

To save the time and effort involved in manual service specification, eG Enterprise offers an

easy-to-use auto-configure option in the form of a View/Configure button that is available next to

the SERVICENAME text box.

CORRECT– Increased uptime and lower mean time to repair are critical to ensuring that IT

infrastructures deliver a high quality of service to users. Towards this end, the eG Enterprise

suite embeds an optional auto-correction capability that enables eG agents to automatically

correct problems in the environment, as soon as they occur. With this capability, as and when an

abnormal situation is detected, an eG agent can initiate corrective actions automatically to

resolve the problem. Automatic correction without the need for manual intervention by IT

operations staff reduces service downtime and improves operational efficiency. By default, the

auto-correction capability is available in the eG Enterprise suite for the Num_procs_running

measure of ProcessTest, and the Availability measure of WinServiceTest. The eG Enterprise suite

includes a default auto-correction script for WinServiceTest, which executes when the service

that the eG agent has been configured to monitor, stops. To enable the auto-correction

capability of the WinServiceTest, first, select the true option against the CORRECT parameter in

this page (by default, false will be selected here).

Note:

When monitoring an MS SQL server, the SERVICE parameter will be set to MSSQLServer by

default. However, if the MS SQL server being monitored was installed using a named instance,

the SQL service name will change. In such a case therefore, ensure that the SERVICE

parameter is reconfigured to reflect the correct service name.

To save the time and effort involved in manual service specification, eG Enterprise offers an

easy-to-use auto-configure option in the form of a View/Configure button that is available next to

the SERVICENAME text box.

ALARMTYPE– Upon selecting the TRUE option, two new parameters, namely, ALARMTYPE,

USERPARAMS, and CORRECTIVESCRIPT will appear. The ALARMTYPE parameter indicates

when the auto-corrective script should execute. You can set the corrective script to execute

when a specific type of alarm is generated, by selecting an option from the ALARMTYPE list box.

For example, if the Critical option is chosen from the ALARMTYPE list box, then the corrective

script will run only when a critical alarm for the WinServiceTest is generated. Similarly, if the

Critical/Major option is chosen, then the corrective script will execute only when the eG

Enterprise system generates critical or major alarms for the WinServiceTest. In order to ensure

that the corrective script executes regardless of the alarm type, select the Critical/Major/Minor

option.

USERPARAMS– The default script for WinServiceTest takes no parameters. Therefore, specify

none against USERPARAMS.

CORRECTIVESCRIPT– The CORRECTIVESCRIPT text box can also contain none, so that the

default script is automatically associated with the test. Administrators can build new auto-

correction capabilities to address probable issues with other tests, by writing their own corrective

scripts. To know how to create custom auto-correction scripts, refer to the eG User Manual.

10. Then, click the Update button in Figure 17.4, to save the changes.


59

11. Finally, signout of the eG administrative interface.

17.2 Monitoring the Microsoft Fast Search Server To monitor the Microsoft Fast Search Server, do the following:


2. Click on the Components option in the menu bar, and select the Servers option from the components

menu.

3. From the COMPONENTS list page, click on the Microsoft Fast Search for which you wish to view

measurements.

Conc lus ion

60

Conclusion This document has described in detail the steps for configuring and monitoring the Microsoft Applications.

For details of how to administer and use the eG Enterprise suite of products, refer to the user manuals.

We will be adding new measurement capabilities into the future versions of the eG Enterprise suite. If you

can identify new capabilities that you would like us to incorporate in the eG Enterprise suite of products,

please contact [email protected]. We look forward to your support and cooperation. Any

feedback regarding this manual or any other aspects of the eG Enterprise suite can be forwarded to

[email protected].

mailto:[email protected]

configuring and monitoring microsoft applications implementer's guides...configuring and...

Documents