Component Administration
 

Windows Services Configuration - Windows Services

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 () icon that is available next to the SERVICENAME text box.

The procedure for auto-configuring the services are as follows:

  1. When the View/Configure() icon is clicked, a Windows Services Configuration page will appear.

    2. Note:

    The View/Configure () icon will appear only if the following conditions are fulfilled:

    • The test must be agent based

    • The eG agent executing the test is of version 5.2 or above.

    • In case the eG manager in question is part of a redundant manager setup, then the agent executing the test must be reporting metrics to the primary manager only.

  2. Upon clicking the Get Services button in the Windows Services Configuration page, a pop up window with a list of services that are running on the host will be displayed.

    3. Note:

    The services that are configured already will not be listed in the list of unconfigured services.

  3. Select the service or list of services that require monitoring and click the SUBMIT button.

  4. The selected service/services will be populated in the Windows service name text box available in the Windows Services Configuration page.

  5. You can add more services in the Windows Services configuration page by clicking on the encircled '+' button present at the end of the first Windows service name specification. To remove a specification that pre-exists, just click on the encircled '-' button that corresponds to it.

  6. The Windows service name text box can also be edited manually.

  7. Clicking the Update button in the Windows Services Configuration page will make sure that the SERVICENAME text box is populated with the list of services that you selected for monitoring in a comma separated list.

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.

In case of components where service names vary with the operating system on which the component is deployed (eg., Terminal server, Domain controller, DHCP server etc.), the SERVICENAME parameter is set to {EG_RUNTIME} by default. This implies that WinServiceTest automatically determines the service to be monitored at run-time, depending upon the operating system on which the test executes. To view the OS-specific service names associated with a component-type by default, and to make changes to them if required, click on the Configure button next to {EG_RUNTIME}. An OS SPECIFIC CONFIGURATION window then pops out, which lists the Operating systems on which the component executes, and the default SERVICE name configurations that correspond to every operating system. If need be, additional services can be configured for monitoring per operating system. Make sure that every additional specification is separated by a comma (,). The default configurations too can be modified or removed, as required. However, if you want to add a new operating system and/or a new component type and set its default service configurations, follow the steps detailed in the Configuring Tests section of the eG User Manual.

  • 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 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 suite for the Num_procs_running measure of ProcessTest, and the Availability measure of WinServiceTest. The eG 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 Yes option against the CORRECT flag in this page (by default, No will be selected here).

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

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

    The CORRECTIVESCRIPT text box can also contain none, so that the default script is automatically associated with the test.

    Note:

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

    • The ‘Auto Correction’ capability is not available for tests run by a remote agent.

  • If the value chosen against ISPASSIVE is YES, then the server under consideration is a passive server in a cluster. No alerts will be generated if the server is not running. Measures will be reported as ‘Not applicable&rsqauo; by the agent if the server is not up.

    		•