HP Operations Manager Software for Windows Integration Guide

HP Operations Manager Software for Windows Integration Guide This guide documents the facilities to integrate EnterpriseSCHEDULE into HP Operations Manager Software for Windows (formerly known as HP OpenView Operations). Revision: Version 1.0 Release Date: September 17, 2007 ISE, Inc P.O. Box 836 Hawthorne, CA 90251 September 17, 2007 1

September 17, 2007 Copyright 2007 All Rights Reserved The information in this document is subject to change without notice and should not be construed as a commitment by International Structural Engineers, Incorporated (ISE). ISE assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No part of this publication may be reproduced, stored in retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise - without the permission of ISE. 2

Contents A. INTRODUCTION... 4 B. SYSTEM REQUIREMENTS... 4 C. INSTALLATION... 5 D. CONFIGURATION... 6 1. EnterpriseSCHEDULE Job Notifications... 6 2. EnterpriseSCHEDULE Event File Messages... 18 3. Windows Event Log Messages from EnterpriseSCHEDULE... 23 4. Deployment of EnterpriseSCHEDULE Policies... 26 5. Use of EnterpriseSCHEDULE Tools... 33 E. UPGRADING... 39 F. REMOVAL... 40 G. TROUBLE-SHOOTING... 41 3

A. INTRODUCTION This guide documents the facilities to integrate EnterpriseSCHEDULE into HP Operations Manager Software for Windows (formerly known as HP OpenView Operations for Windows). Job and server messages can optionally be sent to HP Operations Manager to be processed and displayed in accordance with policies provided. The following message transport mechanisms are available: 1. Send job event messages via the OPCMSG utility only available for managed nodes running the Operations Manager Agent. 2. Send job event messages via SNMP send traps available for any node with an appropriate SNMP trap send program, whether the node is running the Operations Manager Agent or not. 3. Pick up job and server messages from the EnterpriseSCHEDULE events file only available for managed nodes running the Operations Manager Agent. 4. Pick up job and server messages from the Windows system and application event logs (applies to Windows schedule servers only) only available for managed nodes running the Operations Manager Agent. 5. Tools are also provided to execute useful server and job queue commands from the Operations Manager console only available for managed nodes running the Operations Manager Agent. Implementation of the above integration functions are optional. Any combination may be used on any of the schedule server platforms. E.g. on an HP Operations managed node running the Operations Manager Agent, the OPCMSG utility may be the tool chosen for sending job events, such as delays and failures. On a node that is not managed by HP Operations Manager, SNMP traps could be used instead. All of the functions above are provided and can be deployed on the scheduling nodes as required for activation. B. SYSTEM REQUIREMENTS The following are requirements for implementation of the integration: 1. The installation of one or more EnterpriseSCHEDULE servers, version 7.1.26 or above. The hardware, software and system resource requirements are summarized for each platform in the relevant EnterpriseSCHEDULE Quick Start Guide and fully documented in the Release Notes, available on the EnterpriseSCHEDULE release CD or the ISE download site http://support.i-s-e.com 4

. 2. EnterpriseSCHEDULE platforms which currently support the integration are: Windows 2000/2003/XP HP-UX OpenVMS Solaris Review the EnterpriseSCHEDULE Release Notes for version/architecture information. 3. HP Operations Manager Software for Windows version 7.50 or above must be installed and running (formerly known as HP OpenView Operations for Windows v7.50). There are no special additional resources required on the HP Operations Manager Software for Windows console server. The policies created during installation of this integration optionally include the enabling of SNMP traps to be processed (a standard feature within HP Operations Manager Software for Windows), event file monitoring policies and policies to process incoming job and server messages. The number of messages to be processed will depend on the number of jobs that run within the integrated scheduling environment. In a typical environment messages sent to HP Operations Manager will be limited to job delays and failures for important jobs only. At most, if all job events are sent, the number of messages would be around 2 for every job that runs. C. INSTALLATION 1. Install or upgrade EnterpriseSCHEDULE to version 7.1.26 or above. Installation may be made from a release CD or from the ISE download site http://support.i-s-e.com. Check also the patches folders on the CD or download ftp site to pick up the latest release version from there if necessary. Follow the instructions in the relevant EnterpriseSCHEDULE Quick Start Guide or Release Notes. If this includes files within the patches folder structures, be sure to view the readme files for instructions on applying the upgrade. 2. Copy the zip file HPOperationsManagerPolicies.zip to your HP Operations Manager server. Create a folder <program files>\ise\enterpriseschedule\esch_enterpriseschedule_config. Unzip the files to this folder, maintaining the directory structure and file names. 3. Upload the EnterpriseSCHEDULE policies and tools by running the following procedure from the Windows command line: 5 <program files>\ise\enterpriseschedule\ ESCH_EnterpriseSCHEDULE_config\ ESCH_EnterpriseSCHEDULE_policies_upload.bat

This will create the EnterpriseSCHEDULE job and server message policies in HP Operations Manager under a policy group called ESCH_EnterpriseSCHEDULE_policies and tools under a group called ESCH_EnterpriseSCHEDULE_tools. D. CONFIGURATION Configuration is performed on the individual scheduling servers and the HP Operations Manager console server. 1. EnterpriseSCHEDULE Job Notifications The job notification procedure provided with EnterpriseSCHEDULE version 7.1.26 and above includes support for the HP Operations Manager messages. This file will be in the schedule library installation area and called: schedule_notify.vbs schedule_notify.ksh schedule_notify.com - on Windows installations - on HP-UX and Solaris - on OpenVMS These procedures document the facilities for sending the messages. NOTE: if you are using your own customized notification procedure you will need to merge in these changes. Job notifications can be customized to send messages on a per job basis to HP Operations Manager as follows: 1. OPCMSG This feature is only available for managed nodes running the Operations Manager Agent. A node managed by HP Operations Manager will have the OPCMSG command line utility available for sending messages to the Operations Manager Console. To configure messages to be sent via OPCMSG, configure the notices section of jobs as follows: From the command line interface (i.e. called from within the EnterpriseSCHEDULE Windows client or from the operating system native command line) edit the notices of the job: edit -notices \job_folder\job_name or 6

edit/notices \job_folder\job_name See the EnterpriseSCHEDULE reference manual schedule_reference.pdf for your required platforms(s) or schcommands.pdf for Windows for details of this command and syntax. For example, to edit the notices for job Test_job_opcsmg in EnterpriseSCHEDULE folder Hpov, as shown below in the windows client program explorer view, click on the New Commands icon from the windows client program and enter: edit/notices \hpov\test_job_opcmsg Optionally the notices and/or [] folder specification style may be used. E.g. edit -notices [hpov]test_job_opcmsg Create or modify one or more notices sections for the required job s events i.e. job submitted, started, delayed, completed and failed. Refer to the reference manual for notices sections and syntax. E.g. to send a message when the job fails: BEGIN_FAILED SEND_HPOV= - Refer to the procedures handbook DO_NOT_SEND_MAIL END_FAILED In this example a job with this notices section will send a message to the Operations Manager Console via the OPCMSG utility. The message will include the optional message that follows the =. In this example an email will not be sent (which would otherwise be a standard notices option). The resulting message in Operations Manager will look like this: and the message detail: 7

The following example includes an optional severity, explicitly overriding the default: BEGIN_FAILED SEND_HPOV=** Please contact Tech Support! **~critical END_FAILED The resulting message is displayed as follows: 8 and the message detail:

The syntax of the SEND_HPOV call is as follows: SEND_HPOV (= additional text~severity) Examples: SEND_HPOV sends the job event message without any additional text and with default severity. SEND_HPOV = additional text also includes the specified text in the message object field, with the event description. SEND_HPOV = ~severity 9

sets the severity explicitly and does not include additional text. By default the Operations Manager message severity is set as follows: Job submitted, started, completed events NORMAL Job delayed event WARNING Job failed event MINOR Setting the severity explicitly in the SEND_HPOV call allows critical job failures to be highlighted. If the severity is specified it must match a valid Operations Manager severity i.e. NORMAL, WARNING, MINOR, MAJOR or CRITICAL. The schedule_notify procedure allows you to set certain defaults if you do not wish to specify the values in the notices section. These are: hpov_default_text set this variable in the procedure if you wish to include default additional message text. This will be included in the message but overridden by the message text if specified in the send_hpov notices section. hpov_default_severity set this variable in the procedure if you wish to set a default severity e.g. for job failures. This will be overridden by the severity if specified in the send_hpov notices section. hpov_always_on - turn this variable on to force a message to be sent via OPCMSG whether this has been specified in the notices section or not. Note: if you enable the hpov_always_on feature it will only apply to jobs which have notification turned on for a specific event e.g. if you have configured a notification for a job failure event only, the message will only be unconditionally sent via OPCMSG if the job fails. To turn on the notification for the job the appropriate flags must be set in the usual way in the job properties. E.g. in the following example the notification attributes of the job have been set so that job will send a notification only in the event of a job failure. The notices section of the job will then determine what form(s) this notification will take, as described above (in this case, this is the job which was configured to send a message to Operations manager via OPCMSG and to suppress the email that would usually be sent by default. 10

2. SNMP Traps This feature is available for any node with an appropriate SNMP trap send program, whether the node is running the Operations Manager Agent or not. A node that is not managed by HP Operations Manager will typically not have the OPCMSG command line utility available for sending messages to the Operations Manager Console. In this case, or for any other reason, SNMP traps can be used to send messages. To configure messages to be sent via SNMP, configure the notices section of jobs as follows: From the command line interface (i.e. called from within the EnterpriseSCHEDULE Windows client or from the operating system native command line) edit the notices of the job: edit -notices \job_folder\job_name or 11 edit/notices \job_folder\job_name

See the EnterpriseSCHEDULE reference manual schedule_reference.pdf for your required platforms(s) or schcommands.pdf for Windows for details of this command and syntax. For example, to edit the notices for job Test_job_snmp in EnterpriseSCHEDULE folder Hpov, as shown below in the windows client program explorer view, click on the New Commands icon from the windows client program and enter: edit/notices \hpov\test_job_snmp Optionally the notices and/or [] folder specification style may be used. E.g. edit -notices [hpov]test_job_snmp Create or modify one or more notices sections for the required job s events i.e. job submitted, started, delayed, completed and failed. Refer to the reference manual for notices sections and syntax. E.g. to send a message when the job fails: BEGIN_FAILED SEND_SNMP= - Please contact Oracle Support~avocet~major DO_NOT_SEND_MAIL END_FAILED In this example a job with this notices section will send a message to the Operations Manager Console via SNMP. The message will include the optional message that follows the =. It will also specify that the target node for the SNMP message is avocet (i.e. the HP Operations Management Console server), and the message severity will be set explicitly to major. In this example an email will not be sent (a standard notices option). The resulting message in Operations Manager will look like this: 12

and the message detail: The following example also includes an optional severity, explicitly overriding the default as the previous example, but no target node: BEGIN_FAILED SEND_SNMP= - Restore the database & re-run~~warning END_FAILED The resulting message is displayed as follows: 13

and the message detail: The syntax of the SEND_SNMP call is as follows: SEND_SNMP (= message text~target~severity) Examples: SEND_SNMP 14

sends the job event message without any additional text and with default target node and severity. SEND_SNMP = additional text also includes the specified text in the message object field, with the event description. SEND_SNMP = ~~severity sets the severity explicitly and does not include additional text or the target node. By default the Operations Manager message severity is set as follows: Job submitted, started, completed events NORMAL Job delayed event WARNING Job failed event MINOR Setting the severity explicitly in the SEND_SNMP call allows critical job failures to be highlighted. If the severity is specified it must match a valid Operations Manager severity i.e. NORMAL, WARNING, MINOR, MAJOR or CRITICAL. The schedule_notify procedure allows you to set certain defaults if you do not wish to specify the values in the notices section. These are: snmp_default_target - the target node for directing the SNMP trap must be specified. However, it can be defaulted. In this case it need not be specified in the call. Find the reference in the procedure to snmp_default_target. Set this to the name or IP address of the HP Operations Manager server. snmp_default_text set this variable in the procedure if you wish to include default additional message text. This will be overridden by message text if specified in the send_snmp notices section. snmp_default_severity set this variable in the procedure if you wish to set a default severity e.g. for job failures. This will be overridden by the severity if specified in the send_snmp notices section. snmp_always_on - turn this variable on to force a message to be sent via SNMP whether this has been specified in the notices section or not. Note: if you enable the snmp_always_on feature on it will only apply to jobs which have notification turned on for a specific event e.g. if you have configured a notification for a job failure event only, the message will be unconditionally sent via SNMP if the job fails. 15 To turn on the notification for the job the appropriate flags must be set in the usual way in the job properties. E.g. in the following example the notification attributes of the job have been set so that

job will send a notification only in the event of a job failure. The notices section of the job will then determine what form(s) this notification will take, as described above (in this case, this is the job which was configured to send a message to Operations manager via SNMP and to suppress the email that would usually be sent by default. Important note: The schedule_notify procedure supplied for each platform assumes there are standard SNMP trap send routines available and installed. These are: snmptrap trapgen - program on HP-UX - program on Windows sys$system:tcpip$snmp_trapsnd - program on OpenVMS The trapgen program on Windows is shareware rather than a Windows standard program so it 16

requires manual installation, or install a similar utility and adapt the schedule_notify.vbs procedure to use that instead. 3. EnterpriseSCHEDULE Parameter File Configuration for Notifications The server configuration file, sch0_parameter.dat, also located in the EnterpriseSCHEDULE installation folder, contains parameters which determine how notifications are processed. Modify this file as required to enable the above job notifications via OPCMSG or SNMP. If changes are made, the EnterpriseSCHEDULE server will need to be restarted for these to take effect. The file contains comments which document the settings. In particular, set the following parameters: NOTIFY_ENABLED = 1 set this parameter to turn on notifications globally. The settings of the individual jobs as described above will determine which jobs send notifications. NOTIFY_USER = <user> the notification procedure is run as a separate job process by the EnterpriseSCHEDULE server. The <user> specified must be a valid username on the scheduling server which has sufficient rights to execute the notifications. Examples: NOTIFY_USER = adminuser - the notification procedure process is run under valid username adminuser applies to all platforms. For Windows only, use this format if email notifications are not required for any jobs. NOTIFY_USER = adminuser@domain.com - the notification procedure process is run under valid username adminuser, email notifications are sent from that email address. Only applies to Windows platforms. NOTIFY_USER = adminuser@,esch@domain.com - the notification procedure process is run under valid username adminuser, email notifications are sent from valid email address esch@domain.com use this format if the username and first part of the email address are not the same. Only applies to Windows platforms. NOTIFY_SMTP_SERVER = <node> - specify the name of the mail server for the smtp mail client. Applies to Windows and Unix platforms. Notes: 1. If you wish to send notifications, such as messages to HP Operations Manager, but do not ever wish to send emails, you can omit the email configurations in the above parameters. However, you must specify a valid username for NOTIFY_USER (or allow a default to apply) and specify DO_NOT_SEND_MAIL in the job notices to prevent an attempt to send an email. 17 2. The NOTIFY_USER username must be known to EnterpriseSCHEDULE in order for the notification process to be created and run. A user record must exist for this user in the schedule database. Create this record manually or a simpler way is to log interactively on to

the server under that user and enter a schedule command via the command line client. When prompted enter the password, which will be encrypted and stored in the schedule database. 2. EnterpriseSCHEDULE Event File Messages EnterpriseSCHEDULE job and server messages may also be written to an event file that resides on each scheduling server environment. This file may optionally be polled by HP Operations Manager for Windows for messages to be processed and displayed. This feature is only available for managed nodes running the Operations Manager Agent. The user may choose this option for several different reasons: - as an alternative to the job notification methods that use OPCMSG or SNMP - in addition to job notifications. E.g. the events file can be monitored to display just EnterpriseSCHEDULE server messages. 1. The EnterpriseSCHEDULE events & parameter files The events file is located in the EnterpriseSCHEDULE installation folder and is named sch<grp>_events_<node>.log where <grp> is the scheduling group number and <node> is the node name. E.g. for group 0 on node CONDOR the file is called sch0_events_condor.log. The server configuration file, sch0_parameter.dat, also located in the EnterpriseSCHEDULE installation folder, contains parameters which determine which events are written. Modify this file as required to record the events. If changes are made, the EnterpriseSCHEDULE server will need to be restarted for these to take effect. The file contains comments which document the settings. 18 a. Configuring server events to be written Configurable parameters in the parameter file for server events are: server_eventfile_flags this parameter specifies which categories of EnterpriseSCHEDULE server messages are written to the events file as follows: bit 1 sets logging of SUCCESS messages bit 2 sets logging of ERROR messages bit 3 sets logging of WARNING messages bit 4 sets logging of INFORMATIONAL messages. This results in the required decimal values for sever_eventfile_flags: ERROR 2 ERROR WARNING 6

ERROR WARNING INFORMATIONAL 14 SUCCESS ERROR WARNING INFORMATIONAL 15 E.g. to record just error and warning server messages in the events file: server_eventfile_flags = 6 server_eventfile_enabled this parameter globally enables or disables the writing of server events to the events file. If set (enabled), events are written as described above, according to the server_eventfile_flags parameter. If not set (disabled), no server events are written, irrespective of the settings. An example of a server message polled from the events file: with the following detail: 19

b. Configuring job events to be written Configurable parameters in the parameter file for job events are: job_eventfile_flags this parameter specifies which categories of EnterpriseSCHEDULE job notification messages are written to the events file as follows: bit 1 sets logging of JOB SUBMIT events = decimal 1 bit 2 sets logging of JOB STARTED events = decimal 2 (only used on OpenVMS) bit 3 sets logging of JOB COMPLETED events = decimal 4 bit 4 sets logging of JOB DELAYED events = decimal 8 bit 5 sets logging of JOB FAILED events = decimal 16 This results in these examples of decimal values for job_eventfile_flags. 20

To record just job delayed and failure messages in the events file: job_eventfile_flags = 24 To record all job events messages in the events file: job_eventfile_flags = 31 Note: the job started flag is only implemented for OpenVMS. The parameter file also contains a global parameter job_eventfile_enabled this parameter globally enables or disables the writing of server events to the events file. Possible values are: 0 no job events are written to the events file. 1 job events are written in accordance with individual job notification flags. 2 job events are written in accordance with the above job_eventfile_flags parameter or if the individual job notification flags are set i.e. for certain jobs it is then possible to record additional events in the file. c. Setting for individual job events to be written to the event file The above parameters define global settings for writing messages into the EnterpriseSCHEDULE events file. To set the flags so individual job notification messages are written to the events file, check the notifications flags as follows, from the job properties notify window: 21

In this example, only job submission and job failure messages will be written to the EnterpriseSCHEDULE events file, so long as the job_eventfile_enabled parameter is set to 1 or 2. An example of a job failure message polled from the events file: with the following detail: 22

3. Windows Event Log Messages from EnterpriseSCHEDULE On Windows servers only, EnterpriseSCHEDULE job and server messages may also be written to the Windows Application log file. This file may optionally be polled by HP Operations Manager for Windows for messages to be processed and displayed. This feature is only available for managed nodes running the Operations Manager Agent. The user may choose this option for several different reasons: - as an alternative to the job notification methods that use OPCMSG or SNMP or the EnterpriseSCHEDULE events file. - in addition to job notifications. E.g. the event log can be monitored to display just EnterpriseSCHEDULE server messages. 23

1. Configuring Windows event log entries for server messages Configurable parameters in the parameter file for Windows application event log events for server messages are: nteventlog this parameter specifies which categories of EnterpriseSCHEDULE messages are written to the application events log as follows: bit 1 sets logging of SUCCESS messages bit 2 sets logging of ERROR messages bit 3 sets logging of WARNING messages bit 4 sets logging of INFORMATIONAL messages. This results in the required decimal values for sever_eventfile_flags: ERROR 2 ERROR WARNING 6 ERROR WARNING INFORMATIONAL 14 SUCCESS ERROR WARNING INFORMATIONAL 15 E.g. to record just error and warning server messages in the events file: nteventlog = 6 server_eventlog_enabled this parameter globally enables or disables the writing of server events to the Windows Application event log. If set (enabled), events are written as described above, according to the nteventlog parameter. If not set (disabled), no server events are written, irrespective of the settings. 2. Configuring Windows event log entries for job messages Configurable parameter in the parameter file for Windows application event log events for job messages: job_eventlog_enabled this parameter globally enables or disables the writing of job events to the Windows Application event log. If set (enabled), events are written according to the individual job notification flags. If not set (disabled), no job events are written, irrespective of the settings. 3. Settings for individual job events to be written to the Windows event log The above parameter enables the writing of job messages into the Windows event log. To set the flags so individual job notification messages are written to the event log, check the notifications flags as follows, from the job properties window: 24

Note: the middle column is used to define which events are written to both the EnterpriseSCHEDULE events file and Windows Application Event Log, in accordance with the server parameters described above. An example of a Windows event log entry: with the following detail: 25

4. Deployment of EnterpriseSCHEDULE Policies After the configuration has been completed on the EnterpriseSCHEDULE nodes, the policies can be deployed from the HP Operations Manager windows console. If the policies have been uploaded by running the BAT file provided, as documented in step C, you will have a Policy Group called ESCH_EnterpriseSCHEDULE_policies 1. Policy Definitions The policies provided are as follows 26

a. ESCH-AppEventLog-Windows-group0 description: EnterpriseSCHEDULE group 0 job & server messages that have been written to the Windows application event log. deploy: on any Windows servers where EnterpriseSCHEDULE is configured to write to the application event log and you wish to display these messages. b. ESCH-EventsFile-OpenVMS-group0 description: EnterpriseSCHEDULE group 0 job & server messages written to the EnterpriseSCHEDULE events file on OpenVMS servers. deploy: on any OpenVMS servers where EnterpriseSCHEDULE is configured to write to its event file and you wish to display these messages. c. ESCH-EventsFile-UNIX-group0 description: EnterpriseSCHEDULE group 0 job & server messages written to the EnterpriseSCHEDULE events file on HP-UX and Solaris servers. deploy: on any HP-UX and Solaris servers where EnterpriseSCHEDULE is configured to write to its event file and you wish to display these messages. d. ESCH-EventsFile-Windows-group0 description: EnterpriseSCHEDULE group 0 job & server messages written to the EnterpriseSCHEDULE events file on Windows servers. deploy: on any Windows servers where EnterpriseSCHEDULE is configured to write to its event file and you wish to display these messages. e. ESCH-JobEvents-OPCMSG description: EnterpriseSCHEDULE job event notification sent via OPCMSG. deploy: on any Windows, HP-UX, OpenVMS & Solaris servers where EnterpriseSCHEDULE is configured to send notifications via OPCMSG. f. ESCH-JobEvents-SNMP description: EnterpriseSCHEDULE job event notification sent via SNMP. deploy: on the HP Operations Manager for Windows server, not the EnterpriseSCHEDULE 27

remote nodes. g. ESCH-Service-Windows-group0 description: Monitor the EnterpriseSCHEDULE service. deploy: on any Windows servers which run the EnterpriseSCHEDULE server software to send an alert if the service is not started. h. ESCH-SysEventLog-Windows-group0 description: EnterpriseSCHEDULE group 0 server messages that have been written to the Windows system event log. deploy: on any Windows servers where you wish to pick up system event log messages relating to EnterpriseSCHEDULE. These are events such as those from the Windows Service Control Manager. These messages do not require any configuring with EnterpriseSCHEDULE. 2. Policy Customizations The above policies include rules for matching all EnterpriseSCHEDULE messages received from any of the optional sources. By default information messages are disabled. If you wish to turn these on, edit the following rules as shown below: To activate these for policy ESCH-AppEventLog-Windows-group0, remove the! character in rule 1 (Job Submitted) and rule 3 (Job Completed). 28

29 E.g. for rule 1, click on the condition link to display & remove the highlighted!

For the ESCH-EventsFile-UNIX-group0, ESCH-EventsFile-OpenVMS-group0 and ESCH- EventsFile-Windows-group0 policies, change rules 1, 2 and 3. E.g. for rule 3, Job completed, remove the highlighted! character and save in order to activate the message displays for completed jobs written to the EnterpriseSCHEDULE Events File: 30

31 The ESCH-JobEvents-OPCMSG, ESCH-JobEvents-SNMP and ESCH-SysEventLog-Windowsgroup0 policies do not have any rules disabled by default in this way, as this is not generally necessary. For example, if you wish to prevent job completion success messages from being displayed via the OPCMSG or SNMP policies, the standard method is simply to remove the calls from the job specific notice sections on the EnterpriseSCHEDULE remote node, or to untick the send email box from the job s notify options. However, if you wish to disable these from the policies, edit the policy rules and add a! character in front of each message text match string, as in the example below:

3. Additional Notes for Policies a. EnterpriseSCHEDULE Events File specification The 3 policies defined to monitor the EnterpriseSCHEDULE events file on the various platforms - 4.1.b, c, d do so by using various symbolic names to specify the location and name of the event file being monitored. This is done because the event files contain the name of the node on which they reside as part of the file name. The policies are designed to be node independent. This is achieved as follows: Windows the events file specification is defined in the policy ESCH-EventsFile-Windowsgroup0 as <$sch0_events_log>. A system environment variable sch0_events_log must be defined on each EnterpriseSCHEDULE Windows node which has this policy deployed. In future releases of EnterpriseSCHEDULE this will be done automatically during installation. If you are running a version which does not do this, define the following system environment variable as in this example: sch0_events_log= "C:\PROGRA~1\ise\EnterpriseSCHEDULE\sch0_events_grant.log" 32

This example shows the definition for node grant, with the software installed in the standard place under c:\program files adapt as required. HP-UX and Solaris the events file specification is defined in the policy ESCH-EventsFile- UNIX-group0 as /schedule_library/sch0_events_log. A link must be created to point to the actual file. In future releases of EnterpriseSCHEDULE this will be done automatically during installation. If you are running a version which does not do this, create the following link on each UNIX EnterpriseSCHEDULE node which has this policy deployed. E.g. (for HP-UX): ln /schedule_library/sch0_events_hawk.log /schedule_library/sch0_events_log In this example the node name is hawk adapt as required.. OpenVMS the events file specification is defined in the policy ESCH-EventsFile-OpenVMSgroup0 as SCH0_EVENTS_LOG:. This is a logical name which points to the required file and is automatically created during the EnterpriseSCHEDULE installation from v7.1.26 onwards so no action is required. E.g. on a node called CONDOR the logical name will translate to: "SCH0_EVENTS_LOG" = "SCHEDULE_LIBRARY:SCH0_EVENTS_CONDOR.LOG" (LNM$SYSTEM_TABLE) b. Setting up Multiple Job Notifications If you wish to set up identical notices to send messages to HP Operations Manager for Windows from many jobs, consider configuring the DEFAULT job notifications. Any jobs created that use this job as a template will inherit the notifications. For existing jobs, consider extracting the notices from a job and then inserting them into multiple jobs, using wildcards. This could be much quicker to configure and ensures consistency. See the reference manual for more details. 5. Use of EnterpriseSCHEDULE Tools After the configuration has been completed on the EnterpriseSCHEDULE nodes, the tools can be associated with nodes from the HP Operations Manager for Windows console. If the tools have been uploaded by running the BAT file provided, as documented in step C, you will have a Tools folder called ESCH_EnterpriseSCHEDULE_Tools. These tools can only be triggered to run on managed nodes running the Operations Manager Agent. 1. Tools Provided 33

The tools provided are as follows: a. ESCH-Display EnterpriseSCHEDULE Queue(s) all platforms description: Displays 1 or more EnterpriseSCHEDULE Job Queues. Specify queues as comma separated letters. Defaults to * for all queues. Include /full qualifier for additional information. Use: this tool can be specified for use by any managed node which is running EnterpriseSCHEDULE. Example displaying the timed (B) and completed (P) queue entries: b. ESCH-Display failed jobs by set id all platforms 34 description: Display all recently failed jobs with the specified set id. Find the required set id from the job failure message & enter this set id after the "set_id=" parameter when you run the tool.

Use: this tool can be specified for use by any managed node which is running EnterpriseSCHEDULE Example of an entry for a failed job with set id 670: c. ESCH-EnterpriseSCHEDULE Client Interface description: this tool starts the EnterpriseSCHEDULE client program on the local console server, to connect to any specified schedule server. Use: enter the node name or IP address of the remote schedule server when prompted. This will only be possible if you have installed the EnterpriseSCHEDULE client on the console node. It is not necessary to install the scheduling server, only the client is required. d. ESCH-EnterpriseSCHEDULE Server Info all platforms description: display EnterpriseSCHEDULE Server process statistics for the remote node. Use: displays comprehensive information which confirms that the remote EnterpriseSCHEDULE is running, its configuration and health indicators. Example display see product documentation for full explanations. 35

36

e. ESCH-EnterpriseSCHEDULE Server Restart for OpenVMS & UNIX description: Restart the EnterpriseSCHEDULE Server. Use: this tool applies to HP-UX, OpenVMS and Solaris nodes. It requires that the server process is currently running and defaults to group 0. f. ESCH-EnterpriseSCHEDULE Server Start for OpenVMS description: starts the EnterpriseSCHEDULE Server on OpenVMS. Use: the default is group 0. Change the group number in the tool parameter if required. This tool uses a procedure to start the server and is used when the server is not currently running. g. ESCH-EnterpriseSCHEDULE Server Start for UNIX description: starts the EnterpriseSCHEDULE Server on HP-UX and Solaris. Use: the default is group 0. Change the group number in the tool parameter if required. This tool uses a procedure to start the server and is used when the server is not currently running. h. ESCH-EnterpriseSCHEDULE Server Start for Windows description: starts the EnterpriseSCHEDULE Server on Windows. Use: the default is group 0. Change the group number in the tool parameter if required. This tool is used to start the server when it is not currently running. i. ESCH-EnterpriseSCHEDULE Server Stop for OpenVMS description: stops the EnterpriseSCHEDULE Server on OpenVMS. Use: the default is group 0. Change the group number in the tool parameter field if required. This tool uses a procedure to stop the server and is used when the server is currently running j. ESCH-EnterpriseSCHEDULE Server Stop for UNIX description: stops the EnterpriseSCHEDULE Server on HP-UX and Solaris. Use: the default is group 0. Change the group number in the tool parameter if required. This tool uses a procedure to stop the server and is used when the server is currently running. 37

Applies also to Solaris nodes. k. ESCH-EnterpriseSCHEDULE Server Stop for Windows description: stops the EnterpriseSCHEDULE Server on Windows. Use: the default is group 0. Change the group number in the tool parameter field if required. This tool is used to stop the server when it is currently running. l. ESCH-EnterpriseSCHEDULE status all platforms description: display EnterpriseSCHEDULE Server & Client version & connection details. Use: run on any platform to confirm the client and server users and rights. Example: 38

2. Additional Notes for Tools All of these tools run on the remote node, except for the Client Interface tool (which runs on the local console and connects to a remote EnterpriseSCHEDULE server as specified by the user). In order for most of the provided tools to work it is necessary to ensure that the schedule command is recognized by the remote scheduling node on which the tool command runs. In particular: Windows ensure that the program schedule.exe is present in a folder that the system PATH environment variable points to. By default the program is installed in the main windows folder (as specified by %windir%). Ensure that any upgrade to this program is also replaced there. HP-UX, Solaris the schedule command should resolve to the schedule command line client. This is done by default during product installation. OpenVMS the schedule symbol which points to the command line client program is defined via the procedure schedule_library:schedule_login.com. This procedure is usually called from the system SYLOGIN.COM. Ensure that the call is made for all types of process logins the tool will cause a network process to be created to execute the required command. E. UPGRADING An upgrade to the integration may consist of either or both of the following: 1. Upgrading the EnterpriseSCHEDULE software follow the instructions in the relevant EnterpriseSCHEDULE release notes and, if you are downloading patches from the web site, the instructions in the readme text file. The installation on any supported platform will detect the presence of the software and upgrade it accordingly. Note: the upgrade may introduce changes to the schedule server parameter file sch0_parameter.dat and/or to the schedule notification script, schedule_notify.vbs (Windows) schedule_notify.com (OpenVMS) or schedule_notify.ksh (Unix). If you have customized the previous versions of these files, be sure to save your changes before you start the upgrade and merge them into the new upgraded files as appropriate. 2. Upgrading the HP Operations Manager for Windows policies and tools follow the same procedure to upload these to the Operations Manager server as for the original installation: 39 - the new uploaded policies and tools will automatically replace those that exist in the policy group ESCH_EnterpriseSCHEDULE_policies and tools folder ESCH_EnterpriseSCHEDULE_Tools as documented above. They will require redeployment to the appropriate nodes. - if you make changes to the policies and tools that are provided in any release, it is recommended that you save your changed policies and tools under a different name in the same policy group or tool

folder. E.g. add a standard prefix or suffix to the name to indicate a customization. If you then run the procedure provided to upgrade the EnterpriseSCHEDULE policies and tools your modified versions will not be replaced. You can then merge in the changes as appropriate. F. REMOVAL The removal of the integration may consist of either or both of the following: 1. Removing the EnterpriseSCHEDULE software from one or more servers or client PCs. Please refer to the EnterpriseSCHEDULE release note for details. If you wish to remove the integration but keep the EnterpriseSCHEDULE installation, modify the server parameter flags and job notifications to prevent messages from being sent to HP Operations Manager for Windows. You may wish to keep the settings for events to be written to the EnterpriseSCHEDULE events file or Windows event log and may choose to remove just the explicit OPCMSG and SNMP calls from the job notices. Then optionally follow step 2 below. 2. Removing the HP Operations Manager for Windows integration policies and tools. This is done as follows: - using the Operations Manager windows console, uninstall each policy from the servers on which it is deployed; specify all versions if required. - delete each policy from the ESCH_EnterpriseSCHEDULE_policies group. Be sure to delete all versions. - check also for the presence of any policy with the ESCH prefix displayed within Policies grouped by type; permanently delete all versions of these also if required. - from the configure managed nodes option, remove the EnterpriseSCHEDULE tools from each node as required, then configure tools and permanently delete the tools from the folder ESCH_EnterpriseSCHEDULE_Tools. 40

G. TROUBLE-SHOOTING This section gives you hints and tips for resolving problems in the integration configuration. 1. I do not see job notifications via OPCMSG on my Operations Manager console 41 a. Check that the HP Operations Manager Agent is installed and running on the EnterpriseSCHEDULE node where you have configured jobs. b. Check that the policy ESCH-JobEvents-OPCMSG has been deployed on the EnterpriseSCHEDULE node. c. Check the EnterpriseSCHEDULE Server parameters in the configuration file SCHn_PARAMETER.DAT (where n is the group number e.g. 0). In particular, check that the notifications are turned on globally - NOTIFY_ENABLED = 1. Also check the configuration of the other NOTIFY_* parameters. Ensure that you have set the parameters correctly for your requirements and platform as documented in section D.1.3. d. If you have changed the above parameter file, the EnterpriseSCHEDULE Server process must be restarted for changes to take effect. e. Check the individual job flags. From the Windows Client program go to the properties of the job, notify tab and review the Send Email flags. Ensure all events for which you require notification are ticked. Note: for messages to be sent you must set the Send Email flags, even if you don t actually require an email notification (in which case include the line DO_NOT_SEND_MAIL in the notices). f. Check the job notices from the command line (available on each platform and from the New Commands menu item on the Windows Client). Make sure that you have correctly formatted the notices section(s) and SEND_HPOV call. See section D.1.1 for details and the reference manual. g. Check that the notification jobs are actually running. Look in the server log file In the installation folder, which is named sch<n>_server_<node>.log, where <n> is the scheduling group number (default=0) and <node> is the scheduling node name. If the notification job is unable to run under the specified username you should find an explanatory message. A common problem is that EnterpriseSCHEDULE does not have a valid username record with the encrypted password for the specified user. The easiest way to create this record is to log into the server interactively as the NOTIFY_USER which is set to run the notification job. Then enter a schedule command e.g. schedule dir Enter the password when prompted. The user record will be created and the notification job should then run.

h. Check for the presence in the EnterpriseSCHEDULE installation folder of a file named sch<n>_server_<node>.log_notify If it exists, review it for indications of problems in the execution of the notification procedure. i. Make sure any files that you have downloaded and copied have been copied under the correct mode if you use an FTP tool. In general most files are copied in binary mode but.dat,.com,.ksh,.vbs files are copied in asci mode (documented in the relevant readme file). 2. I do not see job notifications via SNMP on my Operations Manager console a. Follow all the above checks, apart from 1.a. b & f b. Check that the policy ESCH-JobEvents-SNMP has been deployed on the HP Operations Manager node (note: not the EnterpriseSCHEDULE node). c. Check the job notices from the command line (available on each platform and from the New Commands menu item on the Windows Client. Make sure that you have correctly formatted the notices section(s) and SEND_SNMP call. See section D.1.2 for details and the reference manual. d. Check that you have the required SNMP trap send tool. By default these are expected to be: $SYS$SYSTEM:TCPIP$SNMP_TRAPSND OpenVMS trapgen Windows (not a standard part of Windows) snmptrap HP-UX If you have a different SNMP trap program, you will need to adapt the schedule_notify procedure accordingly. Note that a different utility may have different arguments. 3. I do not see job notifications from the EnterpriseSCHEDULE events file on my Operations Manager console 42 a. Check that the HP Operations Manager Agent is installed and running on the EnterpriseSCHEDULE node where you have configured jobs. b. Check that the policy ESCH-EventsFile-<platform>-group0 has been deployed on the EnterpriseSCHEDULE node, where <platform> is OpenVMS, UNIX or Windows as appropriate. c. Check the EnterpriseSCHEDULE Server parameters in the configuration file SCHn_PARAMETER.DAT (where n is the group number e.g. 0). In particular, check that the job and server event file flags are set SERVER_EVENTFILE_ENABLED and JOB_EVENTILFE_ENABLED must be set to 1 if required, and the equivalent flags set to enable the required messages to be generated. See section D.2 for details.

d. If you have changed the above parameter file, the EnterpriseSCHEDULE Server process must be restarted for changes to take effect. e. Check the individual job flags. From the Windows Client program go to the properties of the job, notify tab and review the Event log flags. Ensure all events for which you require event file entries are ticked (note: On Windows this is also used to specify events to be written to the Windows Application Event Log). f. Check the contents of the event file, in the EnterpriseSCHEDULE installation folder sch<n>_events_<node>.log. This will confirm whether there is a problem writing the records or with the policy detecting them. Check for the presence of the string(s) that the policy is configured to match. g. Make sure you have the pointers to the events file correctly set up, as specified in the relevant event file policies. These should be: SCH0_EVENTS_LOG: sch0_events_log - logical name on OpenVMS - system environment variable on Windows /schedule_library/sch0_events_log - a link to the actual path on UNIX, set via ln command e.g. ln /schedule_library/sch0_events_hawk.log /schedule_library/sch0_events_log 4. I do not see job notifications from the Windows Event Log on my Operations Manager console a. Check that the HP Operations Manager Agent is installed and running on the EnterpriseSCHEDULE node where you have configured jobs. b. Check that the policies ESCH-AppEventLog-Windows-group0 and ESCH-SysEventLog- Windows-group0 have been deployed on the EnterpriseSCHEDULE node. c. Check the EnterpriseSCHEDULE Server parameters in the configuration file SCHn_PARAMETER.DAT (where n is the group number e.g. 0). In particular, check that the JOB_EVENTLOG_ENABLED & SERVER_EVENTLOG_ENABLED flags are set to 1, with the NTEVENTLOG flags set to enable the required messages to be generated. See section D.3 for details. d. If you have changed the above parameter file, the EnterpriseSCHEDULE Server process must be restarted for changes to take effect. e. Check the individual job flags. From the Windows Client program go to the properties of the job, notify tab and review the Event log flags. Ensure all events for which you require event file entries are ticked (note: On all platform this is also used to specify events written to the EnterpriseSCHEDULE Event file). f. Check the Windows Application and System Logs,. This confirms whether there is a problem writing the records or with the policy detecting them. Check for the presence of the string(s) 43

that the policy is configured to match. 5. My HP-UX messages from EnterpriseSCHEDULE are not being interpreted a. Check if this is preventing messages from being picked up by the Operations Manager policies. b. The EnterpriseSCHEDULE message catalog files are a series of.cat files, installed by default in the directory /schedule_library/msg/c. The "C" on the end of the path may be the name of the default "locale LC_MESSAGE" returned by the system. If the system returns a different value, the catalog directory must be linked to the default library. E.g. if the value the system returns is POSIX, the command to link the schedule catalog is: ln -s /schedule_library/msg/c /schedule_library/msg/posix This should enable the message text to be picked up and displayed, resulting in the policy search string matches. 44