Operations Orchestration (OO) provides a simple way for customers to run scripts for automated actions. The integration with OMi uses the OO capabilities for building investigation tools or service remediation scripts, providing the operations with a simple way to validate a problem, investigate it, or automatically correct it. A run book can be executed manually.

OO run books can be launched from the Service Health and Event Browser OMi components.

The integration of OMi and OO provides the capability of mapping CI types to OO run books.

After you create such mappings, you can run the mapped OO run books:

• On CIs, by using the Invoke Run Books context menu option. The OO run book parameters are populated by using the map to the CI attributes defined in the Run Book Mapping Configuration wizard. For detailed information about the wizard, see the OMi Administration Guide.

• At the event level. OMi receives an event. The event must match the specified event filter and the event's related CI's CI type must be mapped to the run book.The OO run book parameters are populated by using the map to the CI or event attributes defined in the Run Book Mapping Configuration wizard. For detailed information about the wizard, see the OMi Administration Guide.

  You can also manually execute a run book by selecting the option for a selected event in the Event Browser's event context panel.

Use Case Scenario in Service Health

In OO, the Restart a Node run book is associated with a Node CI Type. The parameters of the run book are mapped to the relevant CI attributes of the Node CI.

In Service Health, the operator detects that a host has a system problem. The operator right-clicks the CI to get a list of the run books relevant to the CI. One of the run books is Restart a Node. The run book can execute automatically because the values of the parameters such as the host name or the IP address are automatically populated by data taken from the CI context.

Use Case Scenario in the Event Browser

In the OMi Event Browser, the operator is going through the assigned events. The operator detects an event related to a lack of disk space that causes a database performance issue. From the event context, the operator can get a list of relevant run books. The operator can launch the appropriate run book manually. The run book continues running without further input from the operator as all run book parameters are extracted from the event or related CI.

Complete the following workflow to integrate OMi and OO.

1. Prerequisites

   Before you configure the integration, the OO administrator needs to perform the following:

   1. Enable user authentication and create an integration user with the Administrator role. The user must be internalexternal.

      Users must have the following capabilities in OO: AUTHOR, SCHEDULE, MANAGE_RUNS, RUN_REPORTS, and HEADLESS_FLOWS. You can either add users to groups with these capabilities (for example, the administrator group has these capabilities) or you can create such a group.

   2. Deploy the following OO Content Packs (CPs) on the OO server: Base, Middleware, and Operating Systems. For OO version 10.50 and higher, also deploy the Third-party content pack.

      First deploy the Base CP, and then the other CPs.

      For details on how to deploy CPs in OO, see the OO documentation.

      Note If you have upgraded to a newer OO version, check if new OO content packs are available on ITOM Marketplace. If new content packs are available, download and deploy them.

   3. If you want to configure run book automation in an OO setup up with a load balancer and a firewall, ensure that port 8443 is open. If port 8443 is not open, the automatic run book execution will fail. The Automatic Run Book execution is triggered from the data processing server.

2. Configure the link between OO and OMi

   To configure the integration between OMi and OO, do the following:

   1. In OMi, open the infrastructure settings:

      Administration > Setup > Infrastructure Settings.

   2. Select Foundations.

   3. Select Integrations with other applications.

   4. In the HPE Operations Orchestration table, locate Operations Orchestration application server version. Select OO 9OO 10.

   5. Locate Operations Orchestration application URL, and modify the setting to the URL used to access the OO application.

      When connecting an OMi instance that employs Lightweight Single Sign-On (LW-SSO) to OO version 10.02 or higher, you must specify the connection URL of OO using the following format: <protocol>://<FQDN>:<portNumber> (for example, http://lab.lab:8080). The port can be 8080 for HTTP or 8443 for HTTPS, according to your needs. For OO 9.xx, use: https://<fully qualified server name>:8443.

   6. If you want to enable run books to be invoked automatically, you must enter a User Name and Password in the same table. In this case, the user should be defined as internal in OO. Specify the integration user you created as part of the prerequisites.

   7. To be able to invoke run books automatically, the user must be internal.
3. Configure LW-SSO authentication

   You must configure LW-SSO in both OMi and OO. Do the following:

   1. Make sure Single Sign-On for OMi is enabled (it is disabled by default). In OMi, open Authentication Management:

      Administration > Users > Authentication Management

      In the Single Sign-On Configuration section, click Edit to open the Single Sign on Editor panel. Select LightweightHPEIdentityManagement.

      Copy the Token Creation Key (initString) to OO, and replace, in OO, all the initStrings in the lwssofmconf.xml file located in the <OO installation directory>\Program Files\Hewlett-Packard\Operations Orchestration\Central\conf\ directory.

   2. In OO, in the web.xml and applicationContext.xml files located in the
      <OO installation directory>\Program Files\Hewlett-Packard\
      Operations Orchestration\Central\WEB-INF\ directory, enable all filters and mappings between LWSSO_SECTION_BEGIN and LWSSO_SECTION_END.

   3. If OO and OMi are in different domains in the Windows operating system, you must make sure that the Trusted Hosts/Domains parameter is the same in OO and OMi. To set the parameter in OMi, open Authentication Management:

      Administration > Users > Authentication Management

      In the Single Sign-On Configuration section, click Edit to open the Single Sign On Editor panel. Select Lightweight.

      Configure the Trusted Hosts/Domains parameter in the field available when you select Domain

   4. Restart the following OO services:

      • RSCentral

      • RSJRAS

      • RSScheduler

   Note If you need to enable logging for debugging LW-SSO: In OO, in the <OO installation directory>\jetty\resources\log4j.properties file, uncomment the line that appears under the LW-SSO comment.

   1. Make sure Single Sign-On for OMi is enabled (it is disabled by default). In OMi, open Authentication Management:

      Administration > Users > Authentication Management

      In the Single Sign-On Configuration section, click Edit to open the Single Sign on Editor panel. Select LightweightHPEIdentityManagement.

      Copy the Token Creation Key (initString). Add the domain where your OMi and OO systems are located to the Trusted Hosts/Domains section. Click Save.

   2. In OMi, open Authentication Management:

      Administration > Users > Authentication Management

      In the Single Sign-On Configuration section, copy the Token Creation Key (initString).

   3. In OO, go to:

      System Configuration > Security > SSO

      System Workspace > Security > SSO

      Administration > System Configuration > Authentication

   4. Replace the value of the LW SSO passphrase or the InitString parameter with the Token Creation Key you copied from OMi. (This must have the same value on all OMi instances that are integrated by using LW-SSO.)

   5. Define domain-related parameters in the LW SSO Settings area:

      • Domain. The domain of the OO server.

      • Protected Domains. List of comma-separated domains used by the OMi instances that employ LW-SSO.

        Note If OO and OMi are in different domains in the Windows operating system, make sure that the Trusted Hosts/Domains (Protected Domains in OO) parameter is the same in OO and OMi.

        In OMi, open Authentication Management:

        Administration > Users > Authentication Management

        In the Single Sign-On Configuration section, click Edit to open Single Sign On Editor panel. In the Single Sign On Editor panel, select Lightweight.

        If OO and OMi are in the same DNS domain, no extra step is required. If OO and OMi are in different domains, add OO's DNS domain to OMi's Trusted Hosts/Domains, and add OMi's DNS domain to OO's Protected Domains.

   Note Limitation with OO versions 10.02 to 10.22 and OMi

   The OMi integration with the OO versions 10.02 to 10.22 (inclusive) is only supported if OO and OMi are in the same domain. If they are in different domains, the integration fails.

   For more details on configuring LW-SSO in OO, see the OO documentation.

4. Export server certificates from OO

   To export server certificates from OO and import them into OMi, use the keytool utility, which is included in JRaim.out-68

   1. On the OO server, enter:

      • Windows:

        [OO install folder]\jre1.6\bin\keytool -keystore "[OO install folder]\Central\conf\rc_keystore" -export -alias pas -file "<path>\<Operations Orchestration fully qualified host name>.cer"

      • Linux:

        keytool -keystore "$ICONCLUDE_HOME/Central/conf/rc_keystore" -export -alias pas -file "<path>/<Operations Orchestration fully qualified host name>.cer"
        

   2. When prompted for a password, enter bran507025.

   1. On the OO server, enter:

      • Windows:

        <OO install folder>\java\bin\keytool.exe -keystore "<OO install folder>\central\var\security\key.store" -export -alias tomcat -file "<path>\<Operations Orchestration fully qualified host name>.cer"

      • Linux:

        keytool -keystore "$ICONCLUDE_HOME/central/var/security/key.store" -export -alias tomcat -file "<path>/<Operations Orchestration fully qualified host name>.cer"

   2. When prompted for a password, enter changeit.

5. Import OO server certificates to OMi

   Import the server certificate from the OO server to the OMi servers so that the two systems can communicate with each other securely.

   You have to execute the following steps on all of your gateway servers, then on all of your data processing servers.

   1. Import the Server Certificate to OMi. To import the server certificate you exported from OO to the OMi cacerts keystores, on the OMi server:

      Enter the following commands:

      <OMi_HOME>\bin\opr-cert-mgmt.[bat|sh] -import <alias> <path>

      Note For more information on the opr-cert-mgmt tool, see the OMi Developer Guide.

   2. Restart all OMi servers so that the trust is loaded in the truststore.

   3. To prevent a certificate error, make sure that this certificate is imported as a trusted root certification authority on any browser that will be accessing OMi.

      The procedure for importing the certificate may vary slightly depending on the type of browser that you are using. For example, if you are using Internet Explorer, follow these steps:

      1. Click Tools > Internet Options > Content > Certificates.

      2. In the Trusted Root Certification Authorities tab, click the Import... button.

      3. Click Next to start the Certificate Import Wizard.
      4. Specify the file you want to import, and then click Next.

      5. Select the Place all certificates in the following store radio button, and then click Browse.

      6. Select Trusted Root Certification Authorities, and then click Next.

      7. Click Finish.

6. Import OO server certificates to OMi container

   Import the server certificate from the OO server to the OMi container so that the two systems can communicate with each other securely.

   1. Find the name of the OMi container by running the following command:

      kubectl get pods --all-namespaces

   2. Go into the OMi container, switch to the OMi directory, and create a certificate directory in the OMi container if you haven't already:

      kubectl exec <OMi container name> -ti bash -c omi -n opsbridge1

      mkdir /var/certs

   3. Copy the OO server certificate to the Docker host using a file transfer tool.

   4. On the Docker host, get the OMi container ID:

      docker ps | grep omi

      Then, copy the OO server certificate from the Docker host to the OMi container by using the ID:

      docker cp <path to certificate>/<OO fully qualified domain name.cer> <OMi Container ID>:/var/certs/<OO fully qualified domain name.cer>

   5. Import the OO server certificate to the OMi container keystore:

      kubectl exec <OMi container name> -ti bash -c omi -n opsbridge1

      cd /var/certs

      /opt/HP/BSM/bin/opr-cert-mgmt.sh -import tomcat /var/certs/<OO fully qualified domain name>.cer

   6. Restart OMi after the import of the certificate:

      /opt/HP/BSM/scripts/run_hpbsm stop
/opt/HP/BSM/scripts/run_hpbsm start

7. Grant permissions

   Grant permissions so that users can create, view, and modify the mapping between OMi CI types and OO run books, and invoke OO run books from OMi.

   To integrate with OO, you must set up users in OMi with specific permissions. Navigate to:

   Administration > Users > Users, Groups, and Roles

   Select the user or create a new user and grant them a role with Operations Orchestration Integration permissions.

   When setting up the users, keep in mind the following:

   • Set up an integration user with the same name in OMi and OO (for example, OMiOO_integr_user).

     Note The username in OO should have all lowercase letters. If users with the same username but different case sensitivity exist in OO, the lowercase username is used.

   • In OMi, the user must have the following permissions to execute Run Books:

     • The Operations Console > Run Book Execution permission.
     • The Advanced RTSM Permissions > Resources (tab) > Resource Type > Queries permission.
     • The Advanced RTSM Permissions > Resources (tab) > Resource Type > Views permission.
     • The Advanced RTSM Permissions > General Actions (tab) > CI Related Actions permission.
     • The Advanced RTSM Permissions > General Actions (tab) > Data Retrieval Actions permission.

   • To enable an OMi user to map a run book to the selected CI type, in OMi, the user must have the Operations Console > Run Book Mappings permission to administer Run Books.

   • To enable an OMi user to administer Run Book Mappings and Automatic Run Book Execution pages in OMi, the user must be created on both OMi and OO, as described above. The same configuration and required permissions apply as for the integration user.

8. Map run books to CI Types

   You can map OO run book parameters to:

   • CI type attributes. For details on the user interface, see the OMi Administration Guide.

     The child CIs of a CI, for which you configure a run book, are also assigned to that run book.

     Note To be able to map run books to CI types, either create a run book flow in OO, or import a content pack in OO with the Content Workspace.

   • The event attributes are predefined in OMi.

   For details, see the OMi Administration Guide.

9. Use OO  functionality from OMi

   You can trigger a run book:

   • From Service Health by using the Invoke Run Books context menu option.

   • From the Event Browser by using the context menu or from the Action Panel.

Use the following information to troubleshoot problems with your OMi-OO integration.

Log Files

The oo_integration.log file enables you to perform basic troubleshooting of problems with OO integration and run book execution.

For automatic run book execution, the oo_integration.log file is available on the data processing server:

<OMi_HOME>/log/opr-backend/oo_integration.log

Log configuration can be performed in:

<OMi_HOME>/conf/core/Tools/log4j/opr-backend/OOIntegration.properties

For setting up and configuring the OO integration, as well as manual run book execution, the log file is available on the gateway server:

<OMi_HOME>/log/jboss/oo_integration.log

Log configuration can be performed here:

<OMi_HOME>/conf/core/Tools/log4j/jboss/OOIntegration.properties

Connection Errors

Connection errors when accessing Run Book Mappings page in OMi

If you receive a remote connection error in the Run Book Mappings page, and no actions are available for new or existing run books, check the oo_integration.log file on your gateway system. Look for the following text:

Failure: User was not authenticated.

If you find this text, do the following:

1. Check that the LWSSO integration is correctly configured between OMi and OO.
2. Make sure that the logged in user exists in OO and has the correct permissions.
3. Check that the configured integration user can authenticate against the OO system and has the correct permissions.

Connection errors when selecting run books in Available Run Books

If you receive a connection error when you select run books in the Available Run Books pane (Library > Operations), change the run.book.timeout and service.center.ws.timeout settings from 10000 to 60000 (1 minute):

1. Open a JMX console on the OMi server:

   https://localhost:29000

2. Select Foundations > service=Infrastructure Settings Manager.

3. To set the values, use setSettingValuePerCustomerId() with contextName: integrations and settingName: settings.pm.settings.run.book.timeout or settings.pm.settings.service.center.ws.timeout. Change to newValue: 60000.

Note Restarting OMi is not required.

Different Domains

If OMi and OO are in different domains, and you are using Internet Explorer as your browser, you may need to add the domains to the list of allowed domains in the Privacy tab (Internet Options > Privacy > Sites).

Web service API error

Problem: When logging into OMi with the integration user account, you receive the error "Web service API returned HTTP status 403: Forbidden".

Solution: This is a known issue with OO 10.20. To resolve the problem, log into OMi as the administrator and access Administration > Setup and Maintenance > Infrastructure Settings. In the Foundations context, select Single Sign-On. Set Add user roles information to LW-SSO token to false.

The Application Performance Management (APM) integration of BSM with OMi enables you to:

• Integrate user interface components from separately deployed APM systems directly into the OMi's MyWorkspace pages. In this way, relevant information is shown directly within the OMi user interface, although this data comes from the BSM system.

• Use the OMi embedded graphing component to show performance data stored within the Profile database of the BSM system.

• Create a MyWorkspace page in OMi to drill down to detailed information about business transactions, business transaction flows, or location-based monitoring within BSM. For this purpose, OMi provides drill-down operations that allow to launch the BSM user interface in the context of a specific CI or event.

For information on supported versions, see the Integrations Catalog.

Understanding the Integration Process

Each instance of the APM Integration is represented in OMi as a connected server. If you are integrating multiple BSMs, each one will be a separate connected server.

When you integrate BSM with OMi, there are a number of steps that occur behind the scenes:

1. Topology Synchronization. The first step of the integration involves pulling the topology of CIs from BSM into OMi. This can take some time, and in very large environments can take several hours.

   The topology of domain-specific CIs such as Business Transactions (BTs) and Business Transaction Flows (BTFs) are not synchronized by default. Instead, we synchronize the Business Application CI which reflects any status changes to these CIs and any BT/BTF CIs that are related to it in BSM.

   Note that the following procedure describes how to integrate BSM into OMi by using the default integration TQLs. If you have any topologies not covered by the out-of-the-box TQLs, create a custom integration TQL. The TQL needs to be defined on the BSM side. For information on how to create an integration TQL, see the Modeling Guide.

2. BSM Status Change Alert Creation. After the BSM topology is integrated into OMi, BSM status change alerts are created within BSM to generate events upon HI or KPI status change. Forwarding rules then define that these alerts will be sent to OMi. As a result, when a CI's status changes in BSM, an event is sent to OMi to update the CI's status.

3. Initial Status Synchronization. When setting up the APM-OMi integration, there is an initial status synchronization so that each CI in OMi receives the status it has in BSM. After the initial synchronization, whenever a CI's status changes in BSM, OMi receives a status change event. This event changes the CI's status in OMi, but the event is not displayed in the Event Console.

   In general, when a KPI's status changes in BSM, the KPI changes status in OMi. In addition, if an HI's status changes on one of the CIs that we synchronized from BSM into OMi, this status change is reflected directly in OMi.

4. Downtime Synchronization. After the above steps are complete, you can synchronize downtimes, so that any downtimes defined in OMi will also apply to BSM. This includes the downtime CI, the CIs connected to the downtime, and the scheduling and action configurations (such as stopping monitoring, sending alerts and emails, and so on). In addition, OMi serves as the central downtime management location, so you can enable one time initial synchronization of BSM downtime to OMi, in order to help start managing all downtimes on the OMi side.

Prerequisites

To integrate a BSM 9.25 (or later) deployment that has been upgraded from a running BSM 9.24 (or earlier), you must complete the following steps first.

If you integrate remotely, copy all the content packs to your computer and then point to the local location to deploy the package.

1. On your BSM server, check if uCMDB content pack 11.13.859 is installed. Access the JMX console on your primary DPS at the following location:

   http://<DPS_FQDN>:21212/jmx-console/HtmlAdaptor?action=inspectMBean&name=UCMDB:service=Content Pack Services#displayCurrentContentPackVersion

   If the console displays the current version of the installed content pack, continue with the next step. Otherwise, install the content pack by using the Package Manager as follows:

   1. Navigate to Admin > RTSM Administration > Administration > Package Manager to open the RTSM Package Manager.

   2. Click Install Content Pack to open the Install Content Pack window.
   3. Select 11* from Version and click Install to install the content pack version 11. Note that you will only see content packs that are available but not yet installed. Those that are installed, you will not see here.

2. On the BSM data processing server, import all the packages listed below. Note that you must import these .zip files, even if these files are already present on the BSM server:

   BLE.zip
Business.zip
Diagnostics_New.zip
OMi_Integration.zip
Sitescope.zip

   To get the TQLs from each zip file:

   1. Navigate to Admin > RTSM Administration > Administration > Package Manager to open the RTSM Package Manager.

   2. Click to open the Deploy Packages to Server window and click .

   3. Navigate to <BSM_HOME>/odb/conf/factory_packages.

   4. Open the zip file, then click <zip_name>.zip to see the list of resources.

   5. Click Deploy to deploy your resource and click OK in the box Resources have been deployed successfully.

   To validate that these packages containing individual TQLs have been loaded correctly, you can look them up in the Modeling Studio. Navigate to:

   1. Admin > RTSM Administration > Modeling > Modeling Studio

   2. Select Resource Type: Queries. In the list, expand Root and scroll down to verify that CIs_For_CIStatusChange_in_OMi is present. Next, expand Root > Integration > OMi_Integration to verify that the following packages are present:

      OMi_Sync_Biz
OMi_Sync_BPI
OMi_Sync_Diag_TV
OMi_Sync_SiS
OMi_Sync_SiS_EMS

3. On your BSM or APM deployment, proceed as follows to check whether OMi is configured for single sign-on configuration. First, read out the values from the JMX console to determine whether further steps are required:

   1. For BSM version 9.25, open the JMX console on your BSM gateway server by typing in a web browser:

      http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=Foundations%3Aservice%3DInfrastructure+Settings+Manager

   2. For BSM 9.26APM 9.30APM 9.40, open the JMX console on your BSM gateway server by typing in a web browser:

      http://localhost:29000

      Navigate to Foundations > Foundations: service=Infrastructure Settings Manager

   3. Find the method java.lang.String getGlobalSettingValue().

   4. Change contextName to SingleSignOn.

   5. Change settingName to lw.sso.configuration.xml.

   6. Click Invoke.

   In the resulting output, search for the string omi. If the string omi is present twice, your deployment is configured correctly and no further steps are required.

4. If the resulting output does not contain the string omi, BSM is not yet correctly configured for integrating with OMi. In this case, you must append the necessary data:

   1. On your BSM Gateway Server, copy and paste the entire result output in a text editor and append the following URLs between the <restURLs> and the </restURLs> tags:

      <url>.*/topaz.*/omi.*/integration.*</url>
<url>.*/topaz.*/acweb.*</url>
<url>.*/topaz.*/personalization.*</url>
<url>.*/topaz.*/bsmLight.*</url>
<url>.*/topaz.*/ldapContext.*</url>
<url>.*/topaz.*/bsmLight.*/BPM.*</url>

   2. Also append the following between the <inbound> and </inbound> tag:

      <service service-pattern=
".*/topaz.*/omi.*/integration.*" service-type="rest">
<in-lwsso refid="ID000001"/>
<in-custom classname="com.mercury.topaz.reportsExt.login.BsmLwSsoBasicAuthHandler"/>
<in-lwssoAutoCreate refid="ID000002"/>
</service>

   3. Copy the entire content from the two steps above.

   4. Open the JMX console on your BSM gateway server by typing in a web browser, preferably Firefox:

      http://localhost:290008080/jmx-console/HtmlAdaptor?action=inspectMBean&name=Foundations%3Aservice%3DInfrastructure+Settings+Manager

   5. Find the method void setGlobalSettingValue().

   6. Change the contextName to SingleSignOn.

   7. Change the settingName to lw.sso.configuration.xml.

   8. Paste the new content into the Value field.

   9. Click Invoke.

   10. Restart the Mercury AS process.

   Note In a distributed environment, you must manually establish a trust relationship between your BSM and OMi systems. Run the following command on the BSM data processing server:

   <OMi_HOME>/opr/bin/BBCTrustServer.[bat|sh] <FQDN of OMi data processing server>

1. Install the UCMDB Data Flow Probe

   The UCMDB Data Flow Probe pulls data from BSM to OMi. To install the UCMDB Data Flow Probe for OMi:

   1. Get the UCMDB Data Flow Probe installation bits from the OMi media kit. The UCMDB Data Flow Probe must be of the same version as the RTSM that OMi uses. The UCMDB Data Flow Probe can be installed on either the OMi gateway server or data processing server. For more details on the installation of the Data Flow Probe, see the Data Flow Probe ReadMe on the media kit.

   2. Install the UCMDB Data Flow Probe according to the instructions in the UCMDB Data Flow Probe Installation Guide. Make sure:

      • HP BSM is selected as the application server.

      • The OMi gateway server or virtual server name is specified.

   3. Set credentials so that the domain name appears in a drop-down list during configuration of the connected server:

      1. Navigate to:

         Administration > RTSM Administration > Data Flow Management > Data Flow Probe Setup

      2. Select DefaultDomain(Default) and expand Credentials to go to Generic Protocol.

      3. Click New in the Generic Protocol pane to open the Generic Protocol Parameters wizard.

      4. Leave the default values in the General section.

      5. Enter the user name and password of one of the following in the Generic section:

         • BSM user who has SDK permission and is allowed to perform synchronizations
         • BSM administrator
         • Integration user
   4. Set up TLS and root certificates

      If you have hardened your OMi server, you must configure TLS in the Data Flow Probe and establish trust between the Data Flow Probe server and the OMi server.

      1. Enable TLS in the DFP to connect to OMi:

         1. Open <DFP_HOME>/conf/DataFlowProbe.properties.

         2. Change the property appilog.agent.probe.protocol from HTTP to HTTPS.

         3. Change the property serverPortHttps from 8443 to 443.

      2. Establish trust between the DFP server and the OMi server:

         1. Import the OMi server certificate into JRE’s trust store:

            <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/bin/keytool -import -trustcacerts -file <CA cert>.pem -alias <ca cert alias> -keystore

            <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/lib/security/cacerts

         2. Import the BSM server certificate into JRE’s trust store:

            <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/bin/keytool -import -trustcacerts -file <CA cert>.pem -alias <ca cert alias> -keystore

            <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/lib/security/cacerts

      You must import the root certificate from your certification authority to the OMi and the BSM data processing servers and gateway servers.

      1. On the OMi gateway and data processing servers, run the following command:

         <OMi_HOME>/bin/opr-cert-mgmt.[bat|sh] -import <alias> <path>

      2. On the BSM gateway and data processing servers, run the following command:

         <BSM_HOME>/JRE/bin/keytool -import -trustcacerts -file <Root Certificate of your Certificate Authority> -alias <any name> -keystore <BSM_HOME>/JRE/lib/security/cacerts

      3. Restart the OMi and BSM gateway and data processing servers.

   5. Start the Data Flow Probe before integrating BSM, by using

      <INSTALL_DIR>/UCMDB/DataFlowProbe/bin/gateway.bat|sh start.

      To see whether the UCMDB Data Flow Probe started successfully, check the following log file :

      <INSTALL_DIR>/UCMDB/DataFlowProbe/runtime/log/WrapperProbeGw.log

      Allow approximately 10 minutes for this process to finish as the Data Flow Probe is uploading a large number of files from the RTSM.

   6. Increase the RTSM timeout in these two places if network latency is likely:

      Note The JMX Console can only be used remotely when its use is configured in BSM or OMi respectively. For information on how to configure your JMX Console remotely, see the OMi Administration Guide.

      To log in the JMX Console, use the user name sysadmin and the password admin.

      1. On your OMi deployment, open the RTSM JMX console in a web browser:

         http://localhost:21212/jmx-console/.

         Click UCMDB:service=Settings Services.

         Click setSettingValue.

         For customerID, enter value 1.

         For name, enter task.DataAccess.Manager.getAdapterClassesConfig.timeOut.

         For value, enter the increased RTSM timeout in milliseconds (default is 20000).

      2. Also, in the RTSM JMX console http://localhost:21212/jmx-console/HtmlAdaptor,

         Click UCMDB:service=Settings Services.

         Click setSettingValue.

         For customerID, enter value 1.

         For name, enter configuration.remote.action.timeout.

         For value, enter the increased RTSM timeout in milliseconds (default is 35000).

2. Prepare the topology synchronization

   Task 1: Create Integration Point in UCMDB for BSM

   Create an integration point in the UCMDB for BSM:

   1. In the UCMDB, go to:

      Managers > Data Flow Management > Integration Studio

   2. Click New Integration Point or Edit, enter a name and description of your choice, and select the adapter: UCMDB 10.x

   3. Enter the following information for the adapter: 

      • Hostname/IP: <gateway server hostname>
      • Port: < 80 or 443 depending on your protocol>
      • Protocol: <communication protocol>
      • Remote Machine State: Actual
      • Push Back Ids For Population: Enabled
      • CMDB State (Data Push): Actual
      • Data Flow Probe: <DFP name>
   4. Specify the credentials for the user accessing the BSM system, and click Test Connection to see if you entered the correct information.

   5. Click OK, then click the Save button above the list of the integration points.

   Task 2: Create Integration Job to pull CIs from BSM

   Next, create an integration job that will pull the CIs from BSM based on the TQLs specified:

   1. Select the Integration Point you created in Step 1. Click the Population tab on the right pane, and click Create New.

   2. Click Add and go to Root > Integration > OMi_integration.

   3. Choose the following five TQLs (running order does not matter for this integration):

      • OMi_Sync_Biz

      • OMi_Sync_BPI

      • OMi_Sync_Diag_TV

      • OMi_Sync_SiS

      • OMi_Sync_SiS_EMS

   4. Select the check box Allow Integration Job to delete removed data.
   5. In the Scheduler Definition section, define the job schedule.

   Task 3: Create Integration Point in UCMDB for OMi

   Create an integration point in the UCMDB for OMi:

   1. In the UCMDB, go to:

      Managers > Data Flow Management > Integration Studio

   2. Click New Integration Point or Edit, enter a name and description of your choice, and select the adapter: UCMDB 10.x

   3. Enter the following information for the adapter: 

      • Hostname/IP: <gateway/LB server hostname>
      • Port: < 80 or 443 depending on your protocol>
      • Protocol: <communication protocol>
      • Remote Machine State: Actual
      • Push Back Ids for Population: Enabled
      • Push Back Ids for Push: Disabled
      • CMDB State (Data Push): Actual
      • Data Flow Probe: CMDB
   4. Specify the credentials for the user accessing the OMi system.

   5. Click OK, then click the Save button above the list of the integration points.

   Task 4: Create Integration Job to Push CIs to OMi

   Next, create an integration job that will push the CIs from the UCMDB to OMi based on the TQLs specified:

   1. Select the Integration Point you created in Step 3. Click the Data Push tab on the right pane, and click Create New.

   2. Based on the CIs you would like to push from the UCMDB to OMi, use an appropriate TQL. As a starting point, you can use RTSMtoCMSSync.

      If you use the RTSMtoCMSSync TQL as a starting point, you must make sure that the correct attributes for your integration are synchronized. Right click any node and select Properties to bring up the Query Node Properties window. On the Element Layout tab, select Select attributes for layout. In the Conditions section, adjust the conditions in order to include the attributes you need. If you would like to include all attributes, set Attributes condition to All.

   Task 5: Verify the Topology Synchronization

   Run the integration jobs and verify the integration results in the UCMDB Manager.

3. Set up TLS and root certificates

   If you have hardened your OMi server, you must configure TLS in the Data Flow Probe and establish trust between the Data Flow Probe server and the OMi server.

   1. Enable TLS in the DFP to connect to OMi:

      1. Open <DFP_HOME>/conf/DataFlowProbe.properties.

      2. Change the property appilog.agent.probe.protocol from HTTP to HTTPS.

      3. Change the property serverPortHttps from 8443 to 443.

   2. Establish trust between the DFP server and the OMi server:

      1. Import the OMi server certificate into JRE’s trust store:

         <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/bin/keytool -import -trustcacerts -file <CA cert>.pem -alias <ca cert alias> -keystore

         <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/lib/security/cacerts

      2. Import the BSM server certificate into JRE’s trust store:

         <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/bin/keytool -import -trustcacerts -file <CA cert>.pem -alias <ca cert alias> -keystore

         <UCMDB_HOME>/UCMDB/DataFlowProbe/bin/jre/lib/security/cacerts

   3. Restart the DFP.

   You must import the root certificate from your certification authority to the OMi and the BSM data processing servers and gateway servers.

   1. On the OMi gateway and data processing servers, run the following command:

      <OMi_HOME>/bin/opr-cert-mgmt.[bat|sh] -import <alias> <path>

   2. On the BSM gateway and data processing servers, run the following command:

      <BSM_HOME>/JRE/bin/keytool -import -trustcacerts -file <Root Certificate of your Certificate Authority> -alias <any name> -keystore <BSM_HOME>/JRE/lib/security/cacerts

   3. Restart the OMi and BSM gateway and data processing servers.

4. Configure Lightweight Single Sign-On

   Note If you use IDM SSO, you must temporarily switch to Lightweight Single Sign-On and restart OMi for the change to take effect, before proceeding with the integration. Once the integration is up and running, you can switch back to IDM SSO.

   A limitation after switching back to IDM SSO:

   • Once established, the data flow probe will store credentials in its cache and does not need LW SSO. However, if you want to change the credentials used by the data flow probe to connect to APM, or if the data flow probe cache is cleared, you must temporarily switch back to LW SSO and configure the data flow probe.

   Aligning Lightweight Single Sign-On on both deployments enables you to view BSM components in the OMi user interface.

   Set up Lightweight Single Sign-On (LW-SSO) and align initString on both systems. It is good practice that the product added to the existing environment gets the same key as the already existing deployments. For example, if OMi is added last, the key needs to be changed in OMi. If more than one BSM server is connected to the same OMi server, change the initString parameter on the BSM side.

   Note: LW-SSO will not work if TLS is enabled for one product but not the other. Make sure that the TLS setup is consistent between products before trying to configure LW-SSO.

   • In OMi:

     1. Navigate to Authentication Management:

        Administration > Users > Authentication Management

     2. In the Single Sign-On Configuration section, click Edit to open Single Sign On Editor panel.

     3. In the Single Sign On Editor panel, select Lightweight.

     4. Copy the Token Creation Key (initString) value.

     5. Click Save to save your configuration.

        For details on configuring LW-SSO, see the OMi Administration Guide.

        Note If you are using OMi 10.63 and this is the first time you integrate the system with APM, you must disable useHTTPonly for the LWSSO cookie by running the following command on the gateway server:

        Windows: <OMi_Home>\opr\support>opr-jmxClient.bat -r -s localhost:4447 -b "Topaz:service=LW-SSO Configuration" -m setUseHTTPOnly -a false

        Linux: <OMi_Home>/opr/support>opr-jmxClient.sh -r -s localhost:4447 -b "Topaz:service=LW-SSO Configuration" -m setUseHTTPOnly -a false

        This is not required if you upgraded to OMi 10.63 from a previous version and already had set up an integration with APM.

   • Perform the following in your BSMAPM deployment:

     1. Navigate to the gateway server and open via browser http://localhost:29000/

     2. Insert your credentials which you configured in the Configuration Server Wizard.

     3. Search for Topaz:service=LW-SSO Configuration.

     4. Paste the Token Creation Key (initString) value that you copied from OMi in the previous instructions.

     5. Click Set to save your changes.

5. Optional.Create the integration user

   In this step you will begin by creating your integration user in the BSM JMX console, and then configure the user by using the BSM user interface.

   Note that an LDAP user must be used unless mixed mode is enabled. If mixed mode is enabled, local accounts can be used.

   1. In your BSM deployment (DPS), go to the jmx console: http://localhost:21212/jmx-console

   2. Select UCMDB:service=Security Services.

   3. Go to createIntegrationUser() and create your integration user using the following values:

      customerID: 1
userName: <integration user name>
password: <pwd>
dataStoreOrigin: <any value>

   4. Click Invoke.

   5. Invoke the getUsersList MBean with customerID=1 to check if the user is shown in the list of integration users.

   6. In your BSM deployment go to Admin > Platform > User and Permissions > User Management.

   7. Select Create New Users with the same user name and password as the integration user created previously.

   8. Click the icon of the user you have just created.

   9. Go to the tab Permissions tab.

   10. Grant the Administrator role to your integration user.

   11. Click Apply Permissions to finish.

   Note You must wait at least ten minutes for the changes to take effect. You can define this in the following setting:

   Navigate to: Admin > Platform > Setup and Maintenance > Infrastructure Settings

   Select the context: Applications - Operations Management

   Scroll to Operations Management - Topaz Authorization Service Settings

   Click the edit button in the line Refresh Interval and enter 10 in the field Value in the Edit Setting dialog box.

   Note Do not perform this step if you upgraded from BSM 9.2x and already created an integration user. It will be created automatically as part of the upgrade.

   You can, optionally, create a dedicated user for integrations between other products (including OMi) and APM. This user enables a product that uses the APM client SDK to be authenticated in the server SDK and execute the APIs. Applications written with this API set must log on with integration user credentials.

   1. In your OMi deployment, open the RTSM JMX console in a web browser:

      http://localhost:21212/jmx-console/

   2. Under UCMDB, click service=UCMDB Authorization Services

   3. Locate the createUser operation. This method accepts the following parameters:

      • customerId. The customer ID.
      • username. The integration user's name.
      • userDisplayName. The integration user's display name.
      • userLoginName. The integration user's login name.

      • password. The integration user's password.

        The password policy requires the password to include at least one one upper case, one lower case, one numeric, and one special character (,/\:._?&%=+-[]()|).

      Click Invoke.

   4. In a single-tenant environment, locate the setRolesForUser method and enter the following parameters:

      • userName. The integration user's name.
      • roles. SuperAdmin.

      Click Invoke.

   5. Locate the setUserServerAdministratorValue method and enter the following parameters:

      • customerID. The customer ID.
      • userLoginName. The integration user's login name.
      • serverAdministratorValue. Select True.

      Click Invoke.

   6. In a multi-tenant environment, locate the grantRolesToUserForAllTenants method and enter the following parameters to assign the role in connection with all tenants:

      • userName. The integration user's name.
      • roles. SuperAdmin.

      Click Invoke.

      Alternatively, to assign the role in connection with specific tenants, invoke the grantRolesToUserForTenants method, using the same user name and roles parameter values. For the tenantNames parameter, enter the required tenants.

   7. Either create more users, or close the JMX console.

   8. Log on to APM as an administrator.

   9. Click Admin > RTSM Administration.

   10. From the Administration tab, run Package Manager.

   11. Click New.

   12. Enter a name for the new package, and click Next.

   13. In the Resource Selection tab, under Administration, click Integration Users.

   14. Select a user or users that you created by using the JMX console.

   15. Click Next and then Finish. Your new package appears in the Package Name list in Package Manager.

   The integration user is defined per customer. To create a stronger integration user for cross-customer usage, use a systemUser with the isSuperIntegrationUser flag set to true. Use the systemUser methods (createSystemUser, removeSystemUser, showAllSystemUsers, changeSystemUserPassword, canSuperIntegrationUserAuthenticate, and so on).

   There are two out-of-the-box system users; we recommend to change their passwords after the installation by using the changeSystemUserPassword method.

   • sysadmin/sysadmin
   • UISysadmin/UISysadmin (this user is also the Super Integration User SuperIntegrationUser)

   If you change the UISysadmin password by using changeSystemUserPassword, you must execute the following method: in the JMX console, locate the UCMDB-UI:name=UCMDB Integration service. Run setCMDBSuperIntegrationUser with the user name and new password of the integration user.

6. Set up an APM connected server in OMi and complete the integration

   In the previous steps, you set up your environment to enable the APM Integration. In the following section, you will perform the integration. In this step, you enable the following:

   • Initiate event, status, and UI integration.

   • Initiate status and downtime synchronization.

   To integrate the configuration items (CIs) that exist in BSM to OMi, perform the following steps:

   1. Make sure port 383 is open in BSM.

   2. On your OMi deployment, navigate to:

      Administration > Setup and Maintenance > Connected Servers

   3. In the central Connected Servers pane, click New and select APM. Alternatively, you can click New in the Application Performance Management (APM) area in the right pane.

      The Create APM Server panel opens.

   4. In the General section, enter a display label, an identifier (a unique internal name if you want to replace the automatically generated one), and, optionally, a description of the connection being specified.

   5. In the Server Properties section, complete the following information:

      1. Enter the fully qualified domain name of the Application User URL setting. To find this FQDN, follow these steps:

         1. On your BSM deployment, navigate to Admin > Platform > Setup and Maintenance > Infrastructure Settings.

         2. Select Foundations and use the list to set the administration context to Platform Administration.
         3. Go to the Platform Administration - Host Configuration section.
         4. Copy the FQDN part of the URL in the Value field of the Default Virtual Gateway Server for Application Users URL entry. The FQDN part of the URL is the URL without https:// and <port number>.
         5. Paste this FQDN part into the Fully qualified domain name field.

      2. Enter the user name and password of your integration user.

      3. Optional. If the URL path has changed, you must add the new URL, otherwise leave this field empty.

      4. Enter the port number of the APM server. The default port value is automatically inserted and can be restored by clicking Set default port.

      5. Make sure the Use secure HTTP check box is selected if you are using secure communication (default).

      6. Clear the Enable sending event updates to the APM server check box if you have BSM 9.2x without OMi being enabled, or APM 9.309.40.

   6. In the Synchronization section, complete the following information:

      Click the box on the left of Step 1: Topology:

      1. If the Use OMi as Global ID Generator option is editable, select your desired global ID generator. Do not use OMi as Global ID Generator. If the Use OMi as Global ID Generator option is grayed out, a global ID generator already exists in your environment. In this case, proceed with selecting your Data Flow Probe.

      2. Select the name of your Data Flow Probe from the drop-down list. Then specify the domain name that was used during the Data Flow Probe installation.

      3. In Test Connection, click Run Test to see if the connected server was correctly set up.

      4. Make sure that the Activate after save check box is selected if you want to enable the server connection immediately.

      5. Click Create to start the topology synchronization and to create the APM integration point.

   If you integrate BSM/APM CIs directly into the UCMDB, or integrate OMi with UCMDB, add APM:<name_of_connected_server_in_OMi>:<dns_name_of_APM_server> to the monitored_by attribute of the CIs. This is required for Performance Dashboard to graph EUM data from BSM 9.2x. To modify the monitored_by attribute, integrate topology directly between BSMAPM and OMi.

   Note that Run Test fails because OMi tries to test a connection to port 383, which is not used in APM 9.30 and 9.40 integrations. Ignore this error.

   Verify the Integration

   The previous procedure involves pulling the topology of the CIs from BSM into OMi. This can take some time, and in very large environments can take several hours.

   The following section describes how to verify that the synchronization is complete, in order to continue with the integration setup.

   1. On the OMi server, navigate to:

      Administration > Setup and Maintenance > Connected Servers

   2. Check the status of the last executed job in the pane to the right of your connected server. Wait until one integration job runs successfully before continuing. To update the status, click Refresh.

   3. Additionally, you can check the status of the integration jobs in the RTSM Integration Studio.

      1. Navigate to:

         Administration > RTSM Administration > Data Flow Management > Integration Studio

         On the left-hand side of the Integration Studio, you see a list of all integration points.

      2. Select the APM2OMi integration point. You see two integration jobs:

         sync_continuous
sync_initial

         Wait until at least one of these completes before continuing.

         You can start manually either integration job by clicking the full synchronization icon or the delta synchronization icon.

   Continue the Setup of BSM in OMi and Start the Integration

   In this section, you configure event, status, and UI integration.

   1. On the OMi server, navigate to:

      Administration > Setup and Maintenance > Connected Servers

   2. Double-click your APM connected server to open the Edit APM Server panel. Alternatively, you can select it and click Edit.

   3. Go to the Synchronization section, and perform the following:

      1. Clear the Step 1: Topology check box.
      2. Select the check box next to Step 2: OMi to APM Setup. This step integrates UI mash-up components and communication certificates and configures OMi server settings in APM.

      3. Click Save to complete this step.

   4. Go back to Administration > Setup and Maintenance > Connected Servers.

   5. Refresh to check if the status of the server connection is Running.
   6. Double-click your APM connected server to open the Edit APM Server panel. Alternatively, you can select it and click Edit.

   7. Go to the Synchronization section, and perform the following:

      1. Clear the Step 2: OMi to APM Setup check box.
      2. Select the check box next to Step 3: Synchronization. CIs in OMi are updated with KPI status from the corresponding CIs in APM and downtime definitions are copied from APM to OMi.
      3. Optional. Select the Synchronize downtime check box to allow one time initial synchronization of BSM downtime to OMi, in order to help start managing all downtimes on the OMi side.
      4. Click Save.

   8. In the Test Connection section, click Run Test to check that the specified connection attributes are correct. If an error message is displayed, correct the connection information, and retest the connection.

7. Enable Alert and Status Forwarding

   In order to enable alert and status forwarding, you must manually deploy the OprEvent template on the OMi side.

   1. On your OMi deployment, navigate to:

      Administration > Monitoring > Policy Templates.

   2. Expand the following:

      Templates grouped by type > Events > Event from REST web service

   3. Click OprEvent template.
   4. Click Assign and Deploy Template.
   5. Select all OMi gateway systems.
   6. Click Next.
   7. Click Next.
   8. Click Finish.
8. Create OMi authentication user name and password

   As part of the new integration between APM and OMi, embedded OMi under APM no longer exists, and the integration relies on connecting to OMi via REST.

   APM users need to set an OMi user name and password for sending events from APM to OMi.

   1. Run the following command on the agent to which the policy was deployed in the previous step. This sets the user name/password for the web service that APM is using (you must set the same username and password on APM):

      <OMi_Home>/opr/bin/opr-rest-ws-policy-configuration.[bat|sh] -enable_auth -credentials -username <username> [-password <password>]

   2. Stop and restart the agent in order to save this change:

      ovc -stop
ovc -status


   3. In APM, select Admin > Platform > Setup and Maintenance > Infrastructure Settings.
   4. Select Foundations.
   5. Select OMi Integration.

   6. In the OMi Integration - General Settings table:

      • Locate Login and enter the user name you used in step 1 to create your OMi authorization user name.

      • Locate Password and enter the password you used in step 1 to create your OMi authorization password.

      Use the user name and password that you created above.

   7. Save your changes.
9. Importing Certificates for REST Service

   Note The default communication method is HTTPS. This step is only required if a secured connection is required. If a secure connection is not required, complete the procedure in Using unsecured HTTP REST access.

   To import the certificates:

   1. On one of the OMi gateway servers where the policy was deployed, list the OMi certificates for the REST service, by entering ovcert -list in a command prompt.

   2. Export the certificate by using the following command:

      ovcert -exporttrusted -file <location of file> -alias <trusted certificate name>

      For example:

      ovcert -exporttrusted -file c:\trust.pem -alias CA_c37b8bd5-5b9b-4626-be18-c78ef76040e5_2048

      where

      c:\trust.pem is the location for the file which will be exported

      CA_<UUID>_2048 is the CA certificate of OMi (where <UUID> is the ID retrieved when using the ovcoreid -ovrg server command).

   3. Import the certificate by running the following command from the <APM_Home>/JRE64/bin folder on the APM gateway and data processing servers:

      keytool -import -trustcacerts -keystore ../lib/security/cacerts -storepass changeit -alias ANYCERTID -file <location of file>

   4. Restart the APM server on both the gateway and data processing server.

10. Using unsecured HTTP REST access

    The default communication method is HTTPS. In order to use HTTP instead, perform the steps described in the Troubleshooting and Maintenance section.

11. KPI Assignments in OMi

    BSM sends KPI status information for certain CI types to OMi. Per default, this is done for Business Application CIs, but BSM can also send KPI status changes for other CI Types. Such a KPI status change is sent to OMi in the form of a special event with a Health Indicator (HI) that contains the KPI name and the new status. These KPI change events are processed separately from other events and are not stored in the event database.

    When a KPI change event arrives in OMi, the following is triggered:

    • Assuming an “Application Availability KPI change event” arrives, a corresponding Health Indicator “Application Availability” is created automatically (for the corresponding CI type).

    • If the CI Type does not yet have a KPI assignment for that specific KPI, then a new KPI assignment is created automatically that uses the HI “Application Availability” to set the KPI “Application Availability” and no further steps are necessary. The KPI status of the “Application Availability” KPI will be synchronized automatically.

    • If the CI Type already has a KPI assignment, then the KPI assignment needs to be adjusted manually.

    Because OMi already has an out-of-the-box KPI assignment for Business Application CIs, you must perform the following manual steps.

    1. In OMi, navigate to Administration > Service Health > CI Status Calculation > KPI Assignments.

    2. Select the CI Types ConfigurationItem > BusinessElement > BusinessApplication.
    3. Pause the assignments for BPM and RUM. These are predefined KPI assignments, which are not suitable for an OMi system.
12. Optional. Additional APM-OMi Integration Configurations

    Integrating BSM with a new, second instance of OMi

    To integrate BSM with a new instance of OMi, after disconnecting the original OMi system from BSM, perform the following:

    Note It is not possible to simultaneously connect two OMi systems to one BSM system. The original OMi system must first be disconnected before connecting a new OMi instance to BSM.

    1. Connect BSM to OMi and execute the topology synchronization following the steps in Set up an APM connected server in OMi and complete the integration.
    2. After the topology synchronization, go to the OMi Integration Studio and select the Integration Point with the name "APM2OMi <name of connected server>".
    3. On the right side, select one of the two sync_* jobs.
    4. On the toolbar, click Clear caches.... After completion, click Full synchronization.
    5. The global IDs generated by the new OMi instance are now properly pushed to BSM.

    Display BSM data in OMi

    BSM user interface components can be directly integrated into the OMi Workspaces to view and drill down to detailed BSM information.

    Note All APM systems connected to OMi must be the same version and/or provide the same features.

    1. On the OMi server, navigate to Workspaces > My Workspace

    2. Create a new page:

       1. Click the New Page icon on the toolbar.
       2. Click Add Component to open the Component Gallery.

       3. Select APM from the list on the left of the Component Gallery to display the BSM components.

       4. Double-click the desired BSM.

    It is not possible to apply a filter to the user interface components from the BSMs that are displayed in OMi. The following BSM use cases are supported:

    • Selecting BSM components from the OMi components gallery and opening them in a frame inside the OMi components dashboard.

    • Wiring in case of a CI change. For example, a CI 1 is selected and its associated data is displayed. If now a different CI, CI 2, is selected, the data displayed changes to data associated with CI 2.

    The following components are currently available in OMi:

    • Platform components

      Top View

      Hierarchy

      Application Health

      APM Based Impact

    • BPM components

      Application Summary

      BPM Performance Matrix

      BPM Performance Status

      BPM Error Summary Distribution by Category/Type

      Application Health Business Summary

      BPM Error Summary Distribution by Location/BPM Custom Attributes

      BPM Error Summary Distribution by Transaction

      Metrics Over Time

    • RUM components

      Application Health Performance

      Application Health Availability

      RUM Event Count By classification

    • SiteScope components

      Cross Performance Reports

      SiteScope Multi View

    • Service Level Management components

      SLA Summary

      Current Status Snapshot

      Historic Status Snapshot

    Other configurations

    There are several OMi Integration Infrastructure setting that will enable you to customize your BSM-OMi Integration.

    To customize the BSM-OMi integration:

    1. In the BSM application, select Admin > Platform > Setup and Maintenance > Infrastructure Settings.
    2. Select Foundations > OMi Integration.

    3. Configure the OMi Integration settings as follows:

       • HI Statuses Sync - CITs configuration file. Define which CI types to include in the HI status synchronization. The following CI types are included by default: node, running_software, business_application. You can add additional CI types or remove existing ones. The CI type name is the internal name (not the display name, for example, the display name is business_application, not Business Application). You can view the CI type name under RTSM > CIT manager.
       • KPIs list per CI type (Business Application). Define which KPI to use for synchronizing the KPI status change. The following CI type is included by default: Application Availability and Application Performance for CI type business_application. You can add additional KPIs and CI types or remove existing ones. Keep in mind that the TQL integration for topology synchronization jobs must be modified to cover the same CI type. If the CIs and the GID are missing from OM, no status change will be reflected.
       • Events chunk size. Size of chunk of events sent during initial KPI/HI synchronization. You can enter a number between 1 and 500.
       • Interval between session. Interval between events chunks sending sessions (seconds). You can enter a number between 1 and 10.
       • Event forwarding CI Alert name if status improved. Enter the event description that is generated when status changes and becomes better.
       • Event forwarding CI Alert name if status worsened. Enter the event description that is generated when status changes and becomes worse.

    In addition, you can use the tql - CIs_For_CIStatusChange_in_OMi to define which CIs to use to synchronize KPI status changes.

13. Optional. Create and forward EUM alerts to OMi

    It is best practice to forward End User Management (EUM) related information to OMi. With EUM alerts, you can:

    • Configure conditions and event based triggers or time based triggers. For example, you can send an alert when a transaction fail or exceeds a specified amount of time.
    • Filter the alert by transaction, location, or mobile device
    • Configure the notification frequency

    By creating EUM alerts, you can pass critical events for EUM applications that are not part of the integration to OMi. When you create EUM alerts you should tailor them according to your specific requirements. In the Actions tab, be sure to select Generate Event. Events that are created in this manner are automatically forwarded to OMi.

    For information about creating and managing EUM alerts, see the BSM Application Administration Guide.

The following topics describe how to troubleshoot and maintain your OMi-APM integration.

Adjust KPI assignments

To adjust and troubleshoot KPI assignments in OMi, do the following:

1. In BSM, create a KPI assignment with the Application Availability KPI type, and any of the available HIs.

2. Send an event on OMi by using the sendEvent.bat|sh tool. The event should contain a severity with the new state of the KPI, a category KpiStatusChange, an ETI Hint containing only the name of the affected KPI, and a RelatedCiHint with a valid hint for the CI resolver.

   Example: In this example, Application Performance has been chosen as the assignment in step 1.

   <OMi_HOME>/opr/support/sendEvent.[bat|sh] -t example -c KpiStatusChange -s Normal -rch GUCMDB:<GlobalCi_Of_BusinessApplication_CI> -eh "Application Performance"

3. In OMi, navigate to Administration > Service Health > KPI Assignments.
4. In the left pane, select ConfigurationItem > BusinessElement > BusinessApplication.
5. In the central pane, select the assignment that contains Application Availability, Availability Performance, and click Edit to edit the KPI assignment.
6. In the Edit KPI Assignment panel, navigate to the KPI Configurations section.
7. Select the Application Availability KPI, and click Edit.

8. In the Related HIs field, add the Application Availability HI to the list of selected HIs.

   Note: If you do not see any HIs in the Related HIs drop-down menu, wait until CI status changes are from BSM to OMi. The forwarding of CI status changes is triggered by the first change of a CI status of any CI that is present in BSM and has been synchronized to OMi. These adjustments can only be done when a corresponding CI status event has been received in OMi. Otherwise, you will not see the Application Performance or Application Availability HIs.
9. Click Save.
10. Perform steps 7 to 10 for the Application Performance HI and KPI.
11. Click Apply all rules for the assignment to take effect on existing CIs.

Change the integration user's password

When you change the integration user's password on the BSM system, the password must be updated in BSM User Management and in the OMi connected server. To change the integration user's password, perform the following steps:

1. In your BSM deployment (DPS), go to the jmx console: http://localhost:21212/jmx-console

2. Select UCMDB Service:Security Services.

3. Go to changeIntegrationUserPassword() and use the following values:

   customerID: 1
userName: <integration user name>
password: <new pwd>
   

4. Click Invoke.

5. In your BSM deployment, go to Admin > Platform > User and Permissions > User Management.

6. Select your integration user in the Groups/Users list.

7. On the General tab, enter the new password in the Password and Confirm Password fields. Click Apply.

8. In your OMi deployment, navigate to Administration > Setup and Maintenance > Connected Servers.

9. Edit the APM connected server. In the Server Properties section, enter the new password in the Password and Verify password fields and save.

10. In the Synchronization section, re-trigger steps 1-3 to avoid any inconsistencies after the password change.

Use unsecured HTTP REST access

Note This step is only required if you are using unsecured HTTP access.

The default communication method is HTTPS. In order to use HTTP, perform the following:

1. Access APM JMX, for example:

   http://<localhost>:29000/mbean?objectname=OMi-Integration%3Aservice%3DSettings

2. Enter the URL to connect to OMi by using setOmiUrl method, for example:

   http://<OMi GW>:30005

3. To view the settings, use the method getOmiUrl.

Failed to re-direct topology from BSM 9.2x to OMi 10.11

If you integrate SiteScope with BSM 9.26 for OMi features (topology and events) and upgrade BSM 9.26 to OMi 10.11, the integration between OMi and SiteScope does not behave as it used. You will not see the new topology and events from your existing SiteScope in the new upgraded OMi.

Workaround: Reset the BSM integration in SiteScope and delete the integration in OMi10.11's Connected server and re-integrate SiteScope from OMi 10.11.

To reset the BSM integration in SiteScope:

1. Log in to SiteScope with your user ID and password.

2. Go to Preferences > Integration Preferences.

3. Edit the existing BSM integration.

4. Click the BSM Preferences Available Operations tab and click Reset.

5. Click OK. The BSM integration is deleted.

Topology synchronization fails

If LDAP was configured on the APM system, it's possible that the integration user's password was not correctly saved in the RTSM database, which will cause the topology integration to fail. To manually update the integration user's password in the RTSM, do the following:

1. Log in to APM as an administrative user.
2. In the same browser in a different tab, connect to the RTSM with http://<APM>:21212, and select User Management.
3. Find the integration user and select Change Password.
4. Fill in the new password (you can leave the old password blank).
5. Save the new password and trigger the topology synchronization again.

Integration fails with trust for event synchronization failed error

If you are running the OMi-APM integration and BSM is using IIS and the OMi-APM integration fails with a Trust for event synchronization failed error, perform the following on all BSM gateways running on IIS.

1. From the Start menu, click Administrative Tools > Internet Information Services (IIS) Manager.
2. In the Connections pane, click Default Web Site.
3. In the right pane, double-click Request Filtering.
4. Click the HTTP Verbs tab.
5. In the right pane, right-click and select Allow Verb.
6. In the Allow Verb dialog box, enter PUT and click OK.
7. Click the File Name Extensions tab.
8. In the right pane, right-click and select Allow File Name Extension.
9. In the Allow File Name Extension dialog box, enter group and click OK.
10. Reset IIS.

SiteScope is an agentless monitoring solution that enables you to remotely monitor the availability and performance of your IT infrastructure (for example, servers, operating systems, network devices, network services, applications, and application components). The SiteScope integration with OMi has multiple parts, which can be enabled individually or in combination with one another. The parts of the integration are:

• Event integration: SiteScope can forward events to OMi.
• Topology integration: SiteScope can forward topology information to OMi.
• Drilldown integration: When SiteScope monitors are used to set the status of a configuration item (CI), you can drill down from the CI in OMi to a SiteScope monitor that contributes to the HI's status.
• Configuring and deploying SiteScope monitors from OMi: OMi provides a script that enables you to import templates from a SiteScope server so that you can include them in aspects, thus allowing you to manage the configuration and deployment of SiteScope monitors from within OMi.

Complete the following workflow to configure and use the SiteScope integration:

1. Prerequisites

   • See the Integration Catalog to review the official support matrix for the integration between OMi and SiteScope.

   • The minimum requirements are:

     • Have OMi 10.12 IP5, 10.60, 10.61, 10.62, or 10.63 installed. If you are using OMi 10.60, 10.61, or 10.62, the latest patch must be installed.
     • Have SiteScope 11.33 IP2 installed.
     • Hotfix for sisconfig: used on the SiteScope server to deploy monitors from OMi. The hotfix is already included in SiteScope 11.33 IP5 and 11.40. If you use an earlier SiteScope version, get the hotfix for QCCR8D44840 from Micro Focus support.

     • If you want to integrate OMi 10.63 and SiteScope 11.40, install SiteScope 11.40 IP2 and and apply the hotfix for QCCR1I129992.

   • In SiteScope, go to Preferences > Infrastructure Preferences > Server Settings and set Host name override to the FQDN of the SiteScope server. Alternatively, modify SiteScope/Groups/master.config by setting _sishostnameoverride=<SiS server FQDN>.

     By doing this, you avoid getting duplicate SiteScope node CIs in OMi.

2. Install and configure the operations agent

   1. Install the Operations Agent on the SiteScope system.

      Install Operations Agent from the SiteScope installer package, or download it from the HPE Software Support (in the Search box, type "Operations Agent", select the relevant version, under Document Type, select Patches, and locate the installation file).

      On Windows:

      1. Log in to the node with administrator privileges.
      2. Go to the directory where you extracted the contents of the ISO file.
      3. Run the following command to install the agent:
         cscript oainstall.vbs -i -a

      On Linux:

      1. Log on to the node with root privileges.
      2. Go to the directory where you extracted the contents of the ISO file.
      3. Run the following command to start the installation:
         ./oainstall.sh -i -a

      For more detailed installation instructions, see the Operations Agent Installation Guide, available from the HPE Software Support site.

      Note  

      Use the -includeupdates installation to install Operations Agent with prepackaged hotfixes. For details, see the Operations Agent Installation Guide.

   2. Configure the Operations Agent.

      This task registers the sisconfig subagent process (used for Monitoring Automation to deploy monitoring to SiteScope), and installs the policy signing tool (used by SiteScope to install policies locally).

      1. Run the SiteScope Configuration Tool on the SiteScope server:

         • On Windows: Select Start > All Programs > SiteScope > Configuration Tool.

         • On Linux (graphic mode): Run <SiteScope install Directory>/bin/config_tool.sh

         • On Linux (console mode): Run <SiteScope install Directory>/bin/config_tool.sh -i console.

         For more details on using the SiteScope Configuration Tool, see the SiteScope Help.

      2. In the ConfigureOperations Agent installed separately option (Operations Agent option in console mode), select Configure Operations Agent to complete the installation of the Operations Agent.

      3. Restart SiteScope.

      4. If the agent is installed on a Red Hat ES Linux 6.0 environment, after installing the Operations Agent, check the installation status in the log files.

         1. In the SiteScope log, check if the installation completed successfully by searching for the results of installOATask.

            Log file name: HPSiteScope_config_tool.log

            Log file location on Windows platforms: win- %temp%

            Log file location on UNIX/Linux platforms: /temp or /var/temp

         2. In the Operations Agent log files:

            Log file name: oainstall.log, oapatch.log

            Log file location on Windows platform: %ovdatadir%\log

            Log file location on UNIX/Linux platforms: /var/opt/OV/log

3. Configure and deploy SiteScope monitors from OMi

   To set up the OMi-SiteScope integration so that you can configure and deploy SiteScope monitors from within OMi, follow these steps:

   Note To enable this integration for TLS, perform the steps in Connect to a SiteScope server that requires TLS and Set up TLS between sisconfig and SiteScope runtime.

   Note If you want to graph SiteScope metrics on the Performance Dashboard, do not use the character "/" in the SiteScope monitor names. Performance dashboard does not support this character. Hence classes for the CI on which the monitor is created will not be listed.

   1. Set up the SiteScope system as a connected server on the OMi server. For more information on setting up a SiteScope connected server and on selecting the target SiteScope server for deployment, see the OMi Administration Guide.

      In order to create a connected server, a valid SiteScope admin user with user name and password must be set up. The user credentials are not created by default when you install SiteScope. For details on how to set up a user name and password, see the SiteScope User Help > Preferences > User Management Preferences.

   2. Configure templates in SiteScope and import them. For information on importing templates from a SiteScope server and assigning SiteScope policy templates to remote servers, as well as for troubleshooting information, see the OMi Administration Guide.

   Guidelines for using multiple SiteScope monitors of same monitor type

   When creating a chart in a performance dashboard, you select the SiteScope data source followed by the monitor type (class name), metric name, and instance name. This is the instance name format:

   <SiteScope_ServerName>/<SiteScope_Group_Name>/<Monitor_Name>

   When you want to use the same performance dashboard to display the same metrics for a different monitored CI, Performance Dashboard (PD) uses the <Monitor_Name> to find a matching instance. If the exact name does not exist, which is typically the case, it finds the first available instance. If that CI has just one monitor of that type, then it is selected. However, you may choose to have more than one monitor of the same type for a monitored CI. This can happen if you want to have two or more UNIX Resources monitors per monitored CI. In this case, to ensure PD selects the correct instance for the metrics in your chart, your monitor names must be in this format:

   <Prefix name> on <hostname>

   For a SiteScope template, it would be <Prefix name> on %%host%%

   PD selects the instance with the same <Prefix name>.

   For example, when monitoring a server named sample.domain.com with separate UNIX Resource monitors for file system usage metrics and network usage metrics, name the two monitors as follows:

   File_system_usage on sample.domain.com and Network_usage on sample.domain.com

4. Configure the event integration

   1. Log in to SiteScope, and navigate to Preferences > Integration Preferences.

   2. Click New Integration, and in the resulting window select HPE Operations Manager Integration.

   3. Enter the FQDN of the OMi gateway server or load balancer.

   4. Check the following boxes:

      1. Enable sending events

      2. Connect directly to APM

      3. Prefer events over metric in APM Service Health (global preference)
         

      Note Do not send metrics to the Operations Agent on the SiteScope server. This capability has been deprecated. OMi and other components of Operations Bridge access SiteScope metric data via SiteScope's native logs.

   5. Uncheck the Enable exporting templates to HPE Operations Manager box.

   6. Click Connect to activate the agent.

      Note If you have not configured certificate auto-granting, you must manually grant the certificate request in OMi:

      • Navigate to Administration > Setup and Maintenance > Certificate Requests

      • Select the certificate request.

      • Click the Grant icon.

   7. Click Install Polices, then click Analyze to verify the configuration.
   8. In the Test Integration section, enter a test message, and click Send Test Message. Then click Send Test Event. Click OK to close the window, then click OK in the following Disable Policy Result window. Verify that both events are in the OMi Event Browser.

   9. Configure all pre-existing monitors to set Service Health based on events.

      Now that you have integrated SiteScope with OMi, any pre-existing monitors have been updated with an Integrations Settings section. In this section, the BSM Service Health Preferences show Service Health is affected by Metrics. This setting must be changed to Events, so that events carry indicators to set Service health. To change the BSM Service Health Preferences from Metrics to Events:

      1. In the monitor tree, right-click the SiteScope container and select Global Search and Replace.

      2. In the wizard, select all monitors. In the Choose Changes tab, check the APM Service health affected by box and set the associated drop down list to Events.

5. Connect to a SiteScope server that requires TLS

   To connect to a SiteScope server that requires TLS, OMi must trust the root certificate that was used to sign the SiteScope certificate. This is done by adding the root certificate to the CA keystore of all of the OMi gateway and data processing servers and to the CA keystore of the SiteScope server. It is important to load the certificates into all DPS and GW servers as the servers reach out to the SiteScope server to run REST APIs required to determine licensing and load:

   • Deployment jobs for SiteScope templates based on manual deployments are executed on a GW server.
   • Deployment jobs for SiteScope templates when using automatic assignment rules are executed on the DPS.

   After loading certificates only into the gateway servers, note that the Connected Server user interface will return a false positive when clicking Run Test because the test does not check the DPS certificates.

   Caution Clients can no longer connect to SiteScope 11.33 (and later versions) by using an HTTPS URL starting with https://localhost. Instead, the host name of the SiteScope system must be used. You can set the host name in SiteScope by running the following command:

   $ ovconfchg -ns opr.sisconfig -set sis_host <SiS_hostname>

   Complete one of the following procedures depending on the type of certificate that was used to sign the SiteScope certificate:

   Note If the OMi or SiteScope server runs a Linux operating system, replace the paths in the following procedures with their Linux equivalents.

   • Certificate from a certificate authority. If the SiteScope certificate was signed with a certificate from a certificate authority, import the certificate to the SiteScope CA keystore and to the CA keystore of the OMi server. Alternatively, you can also import OMi certificate into SiteScope.

     To import SiteScope CA certificate into OMi, follow these steps:

     1. Obtain the root certificate (and any other intermediate certificate) from the certificate authority.

     2. On the SiteScope server to which you want to deploy policies, import the root certificate (and any other intermediate certificate) to the SiteScope CA keystore. Type:

        C:\SiteScope\java\bin\keytool -importcert -alias <yourCA> -file <CAcertificateFile> -keystore C:\SiteScope\java\lib\security\cacerts

        When prompted for the password, type the keystore password. (The default password is changeit.)

     3. On the OMi server to which you want to export SiteScope templates, import the root certificate (and any other intermediate certificate) to the OMi CA keystore. Type:

        <OMi_HOME>\bin\opr-cert-mgmt.[bat|sh] -import <alias> <path>

        When prompted for the password, type the keystore password. (The default password is changeit.)

     4. Restart SiteScope, so that the newly imported certificate will be recognized and used by the integration.

     5. Required if both OMi and SiteScope use HTTPS setup. Import the SiteScope server Keystore to the OMi CA keystore:

        1. Copy the SiteScope serverKeystore, located in C:\SiteScope\groups\serverKeystore, to the following location in OMi: <OMi_HOME>\JRE\lib\security

        2. Import the serverKeystore to OMi cacerts:

           <OMi_HOME>\JRE\bin\keytool -importkeystore -destkeystore cacerts -deststorepass <keypass> -srckeystore “<OMi_HOME>\JRE\lib\security\serverKeystore” -srcstorepass <keypass>

           For <keypass>, define the keystore password that you set in SiteScope.

        3. Restart SiteScope and the OMi gateway server.

     To import OMi CA certificate into SiteScope, follow these steps:

     1. On the SiteScope server, go to Preferences > Certificate Management. Click New. The Import Certificates page is displayed.
     2. Enter the IP address of the OMi server and specify the port.
     3. Click Select to browse and upload the certificate.
     4. Click Import to import the OMi CA certificate into SiteScope.

     5. Restart the SiteScope service.

   • SiteScope self-signed certificate. If the SiteScope certificate is a self-signed certificate (for example, a certificate that was created and configured with the SiteScope tool ssl_util), export the self-signed certificate from SiteScope and import it to the CA keystores of the OMi server and SiteScope:

     1. On the SiteScope server, export the self-signed certificate, type:

        C:\SiteScope\java\bin\keytool -exportcert -keystore C:\SiteScope\groups\serverKeystore -alias sitescope -file <certificateFile>

        When prompted for the keystore password, type the password that was specified when using the ssl_util tool.

     2. On the SiteScope server, import the self-signed certificate to the SiteScope CA keystore. Type:

        C:\SiteScope\java\bin\keytool -importcert -file <certificateFile> -keystore C:\SiteScope\java\lib\security\cacerts

        When prompted for the password, type the keystore password. (The default password is changeit.)

     3. Copy the certificate to the OMi server to which you want to export SiteScope templates.

     4. On the OMi server, import the self-signed certificate to the OMi CA keystore. Type:

        <OMi_HOME>\bin\opr-cert-mgmt.[bat|sh] -import <alias> <path>

        Note For more information on the opr-cert-mgmt tool, see OMi Developer Guide.

        When prompted for the password, type the keystore password (the default password is changeit).

     5. Restart SiteScope, so that the newly imported certificate will be recognized and used by the integration.

     6. Required if both OMi and SiteScope use HTTPS setup. Import the SiteScope server Keystore to the OMi CA keystore:

        1. Copy the SiteScope serverKeystore, located in C:\SiteScope\groups\serverKeystore, to the following location in OMi: <OMi_HOME>\JRE\lib\security

        2. Import the serverKeystore to OMi cacerts:

           <OMi_HOME>\JRE\bin\keytool -importkeystore -destkeystore cacerts -deststorepass <keypass> -srckeystore \tmp\serverKeystore -srcstorepass <keypass>

           For <keypass>, define the keystore password that you set in SiteScope.

        3. Restart SiteScope and the OMi gateway server.
6. Configure the topology integration

   Note By default, OMi uses HTTPS for the internal communication with UCMDB 10.30 and later versions. If you want to run OMi in an HTTP-only environment instead, run the following script on all gateway servers:

   <OMi_Home>/opr/support/enableOdbInternalSSL.sh|bat

   Restart OMi after the script execution.

   1. If not already done so in an earlier step, create a connected server in OMi for the SiteScope server. For information on creating a connected server, see OMi Administration Guide.

   2. Applies to SiteScope versions 11.33 (IP1 to IP5)and 11.40. Redeploy the SiteScope packages by doing the following:

      1. Log on to the OMi server.
      2. Copy the sitescope.zip file from the SiteScopePackages folder which is delivered with the SiteScope installation files. Save the copy to a temporary location.
      3. Go to Administration > RTSM Administration > Administration > Package Manager.
      4. Right-click SiteScope and click Undeploy.
      5. Click Deploy packages to server (from local disk).
      6. Click Add and select the new sitescope.zip package.
      7. Click Deploy.
      8. Restart SiteScope to have the new scripts available in SiteScope.

      Alternatively, you can redeploy the packages by using the JMX console. For details, see the ReadMe file that is delivered together with the SiteScope installation files.

   3. Verify that the integration has been configured automatically in SiteScope:

      • In SiteScope, navigate to Preferences > Integration Preferences.

      • You will see a new APM integration configured as a result of creating the connected server in OMi.

   4. Verify that the topology has been created in the RTSM.

      1. In OMi, navigate to Administration > RTSM Administration > Modeling > IT Universe Manager.

      2. Search for all node CIs. You should now see one or more new CIs created by SiteScope.

      3. Troubleshooting: If topology is not appearing in the RTSM, you can check for errors in the SiteScope logs.

         If you see an error in <SiteScope>\logs\bac_integration\discovery.log, clear the topology cache on SiteScope:

         • Stop the SiteScope service.
         • Delete the 4 files in <SiteScope>\discovery\hsqldb directory
         • Start the SiteScope service.
         • Re-synchronize the topology. Log in to SiteScope and navigate to Preferences > Integration Preferences. Edit BSM Integration, and in the resulting window click Re-Synchronize under BSM Preferences Available Operations.
7. Drill Down to SiteScope

   When SiteScope monitors are used to set the status of a configuration item (CI), you can drill down from the CI (or from a health indicator (HI) on the CI) to a SiteScope monitor that contributes to the HI's status.

   1. Prerequisite. Configure LW-SSO between SiteScope and OMi. Otherwise, you must log into SiteScope manually whenever you drill down to SiteScope.

      To configure LW-SSO, do the following:

      1. Log on to OMi and go to Administration > Users > Authentication Management. Click Edit for the Single Sign-On Mode, select Lightweight and copy the Token Creation Key (initString).
      2. Log on to SiteScope and go to Preferences > General Preferences >LW SSO Settings. Enter the initString you copied from OMi and save.
      3. Restart SiteScope.

   2. Access menu commands from a CI or HI in a My Workspace page or component, for example 360° View, Top View, View Explorer, Health Indicator, or the SiteScope Multi-View component. Select Go to >SiteScope. The SiteScope UI opens directly to the parent group of the relevant monitor.

      If monitors from multiple groups contribute to the CI's or HI's status, the Drilldown to SiteScope dialog box opens. Select the monitor to which you want to drill down and open it in SiteScope.

      The Drilldown to SiteScope dialog box displays the following hierarchy:

      • The root level shows health indicators.

        If you open the dialog box for a CI, one or more HIs that contribute to the CIs status are listed. If you open the dialog box for an HI, this HI appears as the root.

      • The level below the root shows the SiteScope systems (connected server name) that have monitors contributing to the HI.

      • The lowest level shows the SiteScope monitors that contribute to the HI.

      Note In the System Monitors view, if you select Go to > SiteScope from a monitored CI, SiteScope opens the monitor's parent group. If you select this from a group CI, SiteScope opens directly to the group.

   3. Select a SiteScope monitor, and click Drilldown.

      For details on working with SiteScope, see the SiteScope Help.

8. Set up TLS between sisconfig and SiteScope runtime

   The sisconfig component is the adapter between the Operations Agent and the SiteScope runtime. If you are performing the integration to enable configuration and deployment of SiS monitors from OMi, and you want TLS to be enabled, follow these steps:

   1. Set up TLS for SiteScope:

      1. If SiteScope was not yet configured to run with HTTPS, set up a self-signed certificate:

         <SiteScopeDir>/java/bin/keytool -genkey -dname "CN=www.example.net, OU=myOffice, O=myCompany, L=myLocation, ST=myState, C=myCountry" -alias myAlias -keypass mykeypass -keystore

         <SiteScopeDir>/groups/serverKeystore -storepass mykeypass -kelalg "RSA" -validity 742

      2. Modify tomcat:

         In <SiteScopeDir>/Tomcat/conf/server.xml comment the port="8080" and add the following:

         <Connector port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" debug="0" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="<SitescopeDir>/groups/serverKeystore" keystorePass="passphrase" />

         Restart tomcat.

   2. Set up TLS for sisconfig:

      1. Import the SiteScope root certificate to the Java keystore so that siconfig can find it:

         <SitescopeDir>\java\bin\keytool -import -keystore SitescopeDir>\java\lib\security\cacerts -storepass mykeypass -trustcacerts -file "<SitescopeDir>\groups\serverKeystore"

      2. Set https_enabled=true and check that the port is 8443:

         <OvBinDir>\ovconfchg –ns opr.sisconfig –set https_enabled true

         <OvBinDir>\ovconfchg –ns opr.sisconfig –set sis_port 8443

      3. Restart sisconfig:

         <OvBinDir>\ovc –restart sisconfig

Follow these best practices when setting up your OMi-SiS integration.

SiteScope monitor settings

These are the best practices for SiteScope monitor settings. You can set these settings in the HPE Integration Settings section which is part of every SiteScope monitor:

1. Do not send metrics data.

   At the top of the HPE Integration Settings section, select Enable reporting monitor status (no metrics).
   Since OMi does not process metrics and will just ignore them, and to avoid unnecessary network traffic, it is better not to send those metrics in the first place.

2. Examine the topology section and set it up properly.

   Topology is required if you want to graph SiteScope metrics in the OMi Performance Dashboard. It also enables additional functionality, for example service health and downtime management. Topology is also important for OBR reports. For more guidance on SiteScope topology, see the blog post Three faces of SiteScope monitors in the Wild West.

   Note If you force monitoring to report at the Node level where the monitor defaults to a Running Software CI type, then the related out-of-the-box TBEC rules will not be used.

3. Send events.

   The best practice approach for sending events to OMi is to click the Send events checkbox in the Integration Settings section.

4. APM Service Health settings.

   Under the APM Service Health Preferences section make sure that the APM Service health affected by setting is set to Events.

Event integration

For the event integration, the best practice is to click the Send events checkbox in the HPE Operations Manager Integration Settings of all monitors. This generates an event in OMi for each metric threshold status change. The event automatically includes the Event Type Indicator (ETI) applicable for that CI type, and the metric / threshold combination based on the Indicator Settings in the HPE Integrations Settings section of the monitor.

Event rules

If you do not want an event to be generated immediately on a status change, configure Event Rule Settings in the monitor. This feature was added in SiteScope 11.32. Events generated by the Send events configuration can be held back based on time and/or the number of monitor executions for which a condition that generated an event is continuously active. For example, send an event only if the monitor fails twice in row.

Using Alert Actions to generate events

If even more flexibility is required for generating events than what you can achieve with Event Rules or by controlling them in OMi, then you could define SiteScope Alert Actions.

Be aware that the ETI is not set automatically if you use the Alert Action method. You need to set the ETI at the alert action level as shown below.

Alert Action Type

When creating an alert to generate an event, you can choose either the Event Console or Trigger Action Type. The Trigger action in SiteScope Alert actions incurs less overhead than Event Console.

The Event Console action keeps a log of actions for SiteScope’s internal event dashboard. When integrating SiteScope with OMi, there is typically no need to use an event console in SiteScope as well. Thus, the best practice is to use a Trigger action instead of Event Console.

Custom Event Mappings (CEMs)

Custom Common Event Mappings (CEMs) are often created for monitors in a SiteScope template in order to customize the event attributes such as the title, description, ETI, and custom attributes for the events they generate.

When using OMi Monitoring Automation with a group of SiteScope servers, these CEMs must exist on the SiteScope server before deploying a policy from OMi to the server that uses the CEM.

There is no “dedicated” export/import capability specifically for CEMs. The procedure outlined here uses the SiteScope Persistency Viewer tool to export a CEM from the SiteScope server where you develop your OMi SiteScope templates.

Updating CEMs

Apply these best practices to update CEMs:

1. Decide on a naming convention for your CEMs. Add a version number and update it every time you change a CEM. This will allow you to apply updated versions by using the Export/Import procedure.

   For example, if you have a CEM for a HeartBeat monitor, you may want to call the first version of the CEM “HeartBeat –V1”. When you change your monitoring template that you wish to use with OMi/MA and it requires a new version, you would use the new name of “HeartBeat–V2”.

2. Before you upload a new SiteScope template to OMi that uses a new CEM version, follow the Export /Import procedure outlined below to first export the CEM to a file and then import it to every SiteScope server that might receive a deployment of this SiteScope template from OMi.

3. Once the CEM has been replicated to all relevant SiteScope servers, you can upload your new or updated SiteScope template to OMi.

4. When you eventually deploy the OMi template or aspect to a SiteScope server, you are now guaranteed that the required CEM is available.

Export/import procedure for CEMs

Use the SiteScope Persistency Viewer tool to export the CEM from the SiteScope server on which you develop your templates.

Caution Improper use of the SiteScope Persistency Viewer tool can cause irreparable damage to your SiteScope server. Do not use any capabilities other than those documented in this procedure.

1. Launch the SiteScope Persistency Viewer on your development SiteScope server. You can do this with your SiteScope server running. The tool is located at:

   Windows: <SiteScope_Home>\bin\PersistencyViewer.bat
   UNIX: /opt/HP/SiteScope/bin/XPersistencyViewer.sh

2. Click Continue to move through the warning message. Then click Select Persistency Path...

3. Select the SiteScope persistency folder and click Open. This folder is located at the top level in your SiteScope installation directory.

4. In the Filter by Type drop-down list, select the entry (near the bottom of the list) with the name

   com.mercury.sitescope.platform.configmanager.preferences.PreferencesConfig

5. Select the new Common Event Mappings that you want to copy to the destination SiteScope server(s) and click Export.

   You cannot import a CEM into a SiteScope system that already has a CEM with the same name. It will simply be skipped/ignored and the original version will remain. That is why you need to have a naming convention that has a version number and only import new items.

6. Provide a file name, for example cem-updates. Then click Open to save the CEMs to a file.

7. Copy the exported file to a destination production SiteScope server.

8. Make a copy of the file and paste it into the <SiteScope_Home>/persistency/import folder. Do not move your only copy of the original file as it will eventually be deleted. Within a couple of minutes, the file will be processed and then deleted.

9. Your new CEMs on the destination SiteScope server should now be available. You can verify this in your SiteScope UI as shown below.

   

10. You are now able to deploy a template (which references these new CEMs) to this production SiteScope server by using OMi.

Note If you have a very large SiteScope deployment, the out-of-the-box persistency viewer Java command line may not be configured with enough memory for the tool to run. It will crash with an Out of Memory error at startup time. In this case, do the following to increase the memory:

• In Windows, edit <SiteScope_Home>/conf/ems/tools/set_env.bat and add more heap memory to the -Xmx command line option.

  For example, change
  set JAVA_EXEC=%SS_HOME%\java\bin\java.exe -Xmx512m
  to
  set JAVA_EXEC=%SS_HOME%\java\bin\java.exe -Xmx2000m

• In Unix, add an -Xmx option to the Java command line in /opt/HP/SiteScope/bin/XPersistencyView.sh.

  For example, change
  java/bin/java -Dtopaz.home=../conf/ems/tools …
  to
  java/bin/java -Xmx2000m -Dtopaz.home=../conf/ems/tools …

Configuring SiteScope templates for OMi Monitoring Automation

These best practices leverage the capabilities of OMi Monitoring Automation in order to:

• Reduce the number of monitoring templates that need to be developed and maintained at the SiteScope level.

• Eliminate the need for manual steps to duplicate credentials across multiple SiteScope servers.
• Keep all credentials in one place (OMi).
• Leverage centralized parameter customization (for example threshold tuning).
• Eliminate “race” conditions where monitors are deployed that depend on each other. For example between Remote Server creation and the Heartbeat monitor, or a Heartbeat monitor and core OS monitors.

Create a single template for core OS monitoring

It is best practice that the remote server creation step as well as any monitors defined as dependencies (for example heartbeat or reachability check monitors) and the core OS monitors be deployed as a single SiteScope template.

There is no problem having the core OS monitors depend on a heartbeat monitor that is defined within the same SiteScope template.
Deploying the core OS monitor as “all in one” also eliminates race conditions. For example, a core OS monitor could be deployed before the remote server is created (causing the core OS monitor to fail).

Manage credentials in OMi

When you use SiteScope Credential Preferences to manage OS credentials inside a SiteScope template, you must create multiple copies of a SiteScope template and synchronize them with OMi. Multiple OMi aspects are then required at the OMi level as well as multiple automatic assignment rules.

You would require additional effort when making simple changes to update a SiteScope template, as those changes must be made in multiple places. These can easily get out of sync due to the manual nature of this task.

As a best practice, parameterize all credentials in SiteScope templates so that a SiteScope template can be reused and customized at the OMi level. Credentials should be set in an OMi aspect or when applying an automatic assignment rule against a view in OMi.

Fully parameterize all SiteScope templates

SiteScope templates should be parameterized as much as possible to allow for maximum reuse. This includes:

• OS and resource/application credentials
• Metric thresholds
• Application name or other monitor specific details (server, port, URL or whatever the monitor requires)

Parameterization reduces the number of required templates. OMi allows the customization of template parameters in the following situations:

• A SiteScope template is included in an aspect.

  There could be, for example, one aspect created with a “Gold” level of thresholds and another with a “Silver” level of thresholds based on a single SiteScope template. If metric thresholds are parameterized, then only one SiteScope template needs to be maintained. Threshold values can be overridden when it is included in an OMi aspect or during an assignment.

• An aspect is deployed against a view (using automatic assignment rules).

  For example, one set of Windows servers (view #1) could need credential set #1 and the same aspect could be used for a different set of Windows servers (view #2) but with credential set #2 applied. If credentials are parameterized, there could be one aspect that has the OS credentials specified differently in two automatic assignment rules when the different views are assigned to the same aspect.

• An aspect is tuned for a specific deployment (settings can be overridden).

  For example, an application team could desire some custom threshold outside of existing packaged aspects or automatic assignment rules offered by the monitoring team. Parameters can be overridden for a single server deployment if required.

Deploying SiteScope monitors to a pool of SiteScope servers

In a large agentless monitoring deployment, usually multiple SiteScope servers are required. One SiteScope server can monitor around 24,000 monitors and most successful deployments run fewer than this.

There might be a requirement whereby a set of nodes must be monitored by a specific SiteScope server. This means that not all SiteScope servers would have access to the complete set of managed nodes. In this case, you must be sure that monitors will be deployed to a SiteScope server that can actually reach the managed nodes in question.

Monitors are typically deployed to a pool of SiteScope servers. OMi supplies a “callout” to a SiteScope selection script that can be configured in Administration > Infrastructure Settings > Monitoring Automation > Proxy Deployment Scripts > HPE SiteScope server selection script.

This script must be customized to take data, sometimes from the RTSM, to make a decision about which SiteScope server is appropriate for a deployment. By default, decisions to deploy monitors to a SiteScope server can be based on the following inputs to the SiteScope selection script:

• Name
• DNSName
• DomainName
• IPAddress

In addition, the decision can be based on these attributes of the SiteScope server:

• Deployed Monitors
• TotalPoints
• UsedPoints
• MonitorsPerMinute
• OsInstanceUsedPoints
• OsInstanceTotalPoints
• URLMonitorUsedPoints
• URLMonitorTotalPoints
• TransactionMonitorUsedPoints
• TransactionMonitorTotalPoints

Note The SiteScope server data does not include any pending deployment jobs in the monitor counts.

Deploying multiple templates can result in additional OSI licenses

When OMi deploys additional templates against the same node, there is no guarantee that the deployment job will be deployed to the SiteScope server that is already consuming an OSI license for that node. This could result in an OSI license to be consumed for the same node on multiple SiteScope servers.

Note Updating an existing SiteScope template that is already deployed for a node will cause the template to be deployed to the same SiteScope server (as of OMi 10.12 IP2). No new license will be consumed.

Downtime management

OMi supports a downtime feature where you can put one or more business applications (and their nodes), CI collections (and their nodes), running software and any individual node(s) that you select into a downtime state. This is useful during periods of maintenance or a planned outage to stop both the monitoring and alerting.

To access this feature in OMi, go to Administration > Service Health > Downtime Management and create your downtime with the wizard or use the opr-downtime CLI or equivalent REST API. To stop monitoring in SiteScope for the affected CIs, use the option BSM/APM integration only. Additionally enforce downtime in BSM/APM reports and stop active BPM & SiteScope monitoring.

Note If you continue monitoring during the downtime and a status changes, the event is still generated in OMi, but it is immediately closed.

How OMi downtime works with SiteScope

The BSMDowntime_topology TQL in OMi controls downtime CIs. The TQL should always be inspected and can be adjusted to match your application modeling style.

To see this TQL, make hidden queries visible in the Modeling Studio: go to Modeling Studio > User Preferences > General Section > Enable Hidden Queries and set it to true.

The out-of-the-box TQL can be too restrictive in some cases. For example, it requires that business services be related to the business applications, but not all organizations follow this practice. Also, in OMi 10.62 and earlier, the TQL is missing a relationship between business application and SiteScope monitor, and between business application and node. The following TQL contains all these changes. When moving to production the existing TQL should be removed from the system and replaced with the TQL embedded below (import it from a file).

BSMDowntime_topology_fixed_.xml

By default, every 15 minutes (and at SiteScope start up), SiteScope runs the query to see if any more downtime periods should be created. Because of this you should avoid creating downtimes very close to the time you expect them to begin.

The interval between SiteScope queries to OMi for downtime requests can be changed in SiteScope in Preferences > Infrastructure Preferences > General Settings > APM downtime retrieval frequency (minutes).

SiteScope logging data during downtime or when monitors are disabled

By default, when a SiteScope monitor is disabled it still writes data to the log files. This causes issues in graphing data in OMi Performance Dashboard where the last known value logged will be erroneously delivered as a sample value.

The best practice is to turn this feature off. In SiteScope, go to Preferences > Infrastructure Preferences > General Settings and select Log enabled monitors only. Click Save.

Performance dashboards

OMi does not include any performance dashboards for SiteScope metrics. However, you can create your own performance dashboards and share them with other users.

Note If you are monitoring a CI with SiteScope and subsequently deploy additional monitors, Performance Dashboard (PD) might not show the new metric names in the UI drop-downs. OMi 10.12 with a hotfix (QCCR8D98471) or OMi 10.63 provide a Reset Data Source option for non-admin users that causes PD to reach out to SiteScope to collect updated metric meta-data to update the UI drop-downs for the selected CI. This is in contrast to the admin user’s Clear Cache option that does this for all CIs.

Multiple monitors of the same type for a monitored CI

When creating a chart in a performance dashboard, you select the SiteScope data source followed by the monitor type (class name), metric name, and instance name. This is the instance name format:

<SiteScope_ServerName>/<SiteScope_Group_Name>/<Monitor_Name>

When you want to use the same performance dashboard to display the same metrics for a different monitored CI, Performance Dashboard (PD) uses the <Monitor_Name> to find a matching instance. If the exact name does not exist, which is typically the case, it finds the first available instance. If that CI has just one monitor of that type, then it is selected. However, you may choose to have more than one monitor of the same type for a monitored CI. This can happen if you want to have two or more UNIX Resources monitors per monitored CI. In this case, to ensure PD selects the correct instance for the metrics in your chart, your monitor names must be in this format:

<Prefix name> on <hostname>

For a SiteScope template, it would be <Prefix name> on %%host%%

PD selects the instance with the same <Prefix name>.

For example, when monitoring a server named sample.domain.com with separate UNIX Resource monitors for file system usage metrics and network usage metrics, name the two monitors as follows:

File_system_usage on sample.domain.com and Network_usage on sample.domain.com

Response times when using Performance Dashboard to graph SiteScope metrics

PD retrieves data from the daily SiteScope metric log files. A busy SiteScope server can take a long time to respond with metric data since it may have to read through gigabytes of daily log files. Generally, asking metrics for a 1 to 4 hour period is very quick even on a loaded system since SiteScope can do a binary search on the log files to find out where it must sequentially read to deliver the results. On the other hand, asking SiteScope for one week of CPU metric data for a specific server will cause SiteScope to read 7 days of log files from beginning to end to extract the required metrics.

The PD response time depends on how many monitors and metrics you are collecting on your SiteScope server. You need to test your system and recommend to your end users the maximum time period that will result in a reasonable performance.

For reporting long term data for SiteScope, we recommend using the OBR Generic SiteScope Content that is available on the ITOM Marketplace.

You can create an OMi MyWorkspace page consisting of a View Explorer and an OBR graph component that will allow your end users to graph metrics over a long period of time (days, weeks, months, years). This mash-up includes the ability to drill down, drill up, and include any of the node or business application related metrics.

Enable different performance dashboards for different UNIX versions

With Operations Agents, most core OS metrics are “normalized” to a standard naming convention. As a result, performance dashboards like “System Overview Stats” can be used across a variety of OS types including Windows, UNIX, and Linux.

With SiteScope monitoring, the Windows and UNIX Resources Monitors are at the mercy of the target OS type and version for the supported metrics and the names of the metrics. Different OS types require different monitoring templates. This extends to the OMi Performance Perspective where different OS types may require different dashboards.

This presents a challenge for graphing metrics for CI instances based on the UNIX CI type. There can be only one default performance dashboard for each CI type. The problem is that it is difficult to know in advance what the proper dashboard should be. Also, the CI class model does not have a unique CI type for each UNIX variant. There are multiple possible solutions:

• You could look at the CI properties to determine the OS type and then select the most appropriate graph, but this is not a tenable solution.
• You could create a different CI subtype for each UNIX OS type (like AIX, Linux, SunOS, HP-UX, and so on). This would solve the problem but it is not a recommended solution as it would be difficult to maintain and would have ripple effects to any UCMDB integration.

The solution to this problem is to use the OMi conditional dashboard feature. A conditional dashboard allows you to specify which dashboard is the default for a given CI based on a CI attribute. Prior to OMi 10.62, only CI properties of the boolean type were supported for creating conditional dashboards. However, with OMi 10.62, you can create a conditional dashboard based on any CI property. For example OSFamily=Solaris.

The configuration steps involved are covered in detail below.

1. Create new CI attributes for the UNIX CI type (OMi 10.61 or earlier).

   Go to Administration > RTSM Administration > Modeling > CI Type Manager. In the CI Type Manager, add as many new boolean attributes as required to create different dashboards. The example below shows what was done for AIX, Linux, and SunOS. Three new boolean attributes were created: isAIX, isLinux, and isSunOS. Set the default to false and make them both visible and editable.

   

2. Create enrichment rules to set values (OMi 10.61 or earlier).

   Create an RTSM enrichment rule to set the value of these new attributes. The enrichment rule conditionally sets an attribute to true based on some other attribute of the CI like OSFamily, OSVersion, or OSDescription.
   For the detailed steps, please consult your local UCMDB/RTSM expert for assistance.

3. Create your required performance dashboards.

   For each of the different UNIX types, create a different performance dashboard with the metrics you require.

4. Configure the recommended and default dashboards.

   Go to Administration > Operations Console > Performance Dashboard Mappings. Select the UNIX CI type on the left panel and click Edit Mappings.

   Select the Recommended Dashboards option and add any dashboards you have created that should be available to the end users. It is recommended to also set a default – which is indicated by the star next to the graph below.

   

5. Configure the conditional dashboard rules.

   Add a conditional dashboard rule for each of the boolean attributes you created for the UNIX CI type (OMi 10.61 or earlier) or for each OS based on an existing CI attribute (OMi 10.62 or higher). For each rule, select a dashboard as a default, even if you have only one dashboard (indicated by the red arrow below). Below are screenshots of the first rule that was created and the final settings for this example.

   

   

6. Demonstrate the results.

   Note The example in this step is based on OMi 10.61 or earlier.

   To show the end results in this example, the new boolean values are set manually for the UNIX instances.

   

   The node "stilton" draws the SunOS-specific dashboard.

   

   The node "gammelost" draws the AIX-specific dashboard.

   

   The node "ricotta" did not match any of the conditional dashboard settings and shows the default configured dashboard.

   

Reporting

There are three ways to visualize the metrics collected by SiteScope monitors:

• OMi Performance Dashboard
• Out-of-the-box SiteScope reports provided by OBR
• Community-supported OBR Generic SiteScope Content, available on the ITOM Marketplace

The following tables compares the three different options:

Category	OMi Performance Dashboard	Out-of-the-box OBR reports	OBR Generic SiteScope content
Support	Micro Focus supported	Micro Focus supported	Community supported
Data retention	< 40 days	Years, depending on space	Years, depending on space
Responsiveness	Responsive for short time ranges (for example a few hours). Data is retrieved from files on the SiteScope servers.	Designed to aggregate and report on large data sets. Data is stored in the OBR Vertica database.	Designed to aggregate and report on large data sets. Data is stored in the OBR Vertica database.
Monitor coverage	Complete OMi 10.62 added support for graphing SiteScope Measurement type with Dynamic Monitors (e.g., Dynamic Disk Monitor, VMware)	Small CPU, Memory, Dynamic Disk Space, Microsoft Windows Resources, Unix Resources, VMware Performance See the OBR Configuration Guide for the list of SiteScope monitors, objects, and counters.	Large To report on URL monitors, they must be configured with a topology set to a Business Application CI. Monitors that have their topology set to a Running Software CI type are not reported on.
Report list	None provided out-of-the-box, but dashboards are easy to create.	Reports in the System Management content pack and VMware virtualization reporting content pack. See the OBR Configuration Guide for the list of reports.	SiteScope Metrics by Application SiteScope Metrics by Business Service SiteScope Metrics by Server SiteScope Metrics by Monitor Instance SiteScope Metrics by Monitor Type SiteScope Metrics by CI Collection SiteScope Metrics by CI

Integrating SiteScope Failover with OMi

In OMi, create a Connected Server for the primary SiteScope server. Do not create a Connected Server for the failover SiteScope server. When a failover occurs, APM integration is automatically created on the failover server, in Preferences > Integration Preferences, with the registration details of the primary. When you switch back to the primary, the APM integration is deleted from the failover.

Note Re-Sync and Hard Re-Sync are not available at any time on the failover sever. If you try them, you get the message "Operation is not supported on Failover".

Topology integration

There is one SiteScope profile and it is known by the name of the primary. If you create monitors on the failover server during a failover, the topology synchronizes to the RTSM. When you switch back to the primary, the new monitors and their data are added as per your failover preferences.

Event integration

Regardless of whether the event comes from the primary or the failover server, the CI resolution result is the same.
If a monitor’s metric status changes when on the primary server and later this status changes again when on the failover server, the event generated on the failover will close the corresponding event that was generated on the primary based on the resolved ETI which is a Health Indicator.

If the event does not resolve to a Health Indicator, it relies on message keys which will fail to correlate by default since the SiteScope FQDN is part of the key (QCCR1I90537). The recommended workaround is to ensure that all SiteScope monitors are configured with a topology and HIs. Another option is to edit the default (or your custom) Common Event Mappings to replace the <<siteScopeHost>> part of the Key and Close Key Pattern fields with a fixed name. For example, change these:

<<siteScopeHost>>:<<monitorUUID>>:<<metric>>:<<etiValue>>:<<severity>>
<<siteScopeHost>>:<<monitorUUID>>:<<metric>>

To these:

SiS_CA:<<monitorUUID>>:<<metric>>:<<etiValue>>:<<severity>>
SiS_CA:<<monitorUUID>>:<<metric>>

SiS_CA is a string to indicate the primary/failover server pair in California.

Changes to the Common Event Mappings are synchronized between the primary and the failover server. The SiteScope Drilldown URL in the event points to the SiteScope server that sent the event.

Context menu integration

Launching the context menu Go To > Go To SiteScope on the monitored CI or the monitor CI’s HI (HI panel) is successful when the primary is active, but fails when the failover is the active SiteScope server.

SiteScope Multi-View

The SiteScope Multi-View component works with the primary SiteScope server only.

Performance dashboards

You cannot graph SiteScope performance data when the primary server is down (meaning that the failover is active). The charts display a “No data found” error.

When the primary is the active SiteScope server, the monitor data logged on the failover is synchronized back to the primary, so the performance dashboards show all the metric data from monitors running on the primary and the failover.

Monitoring Automation

OMi Monitoring Automation always selects the SiteScope server defined as the Connected Server — meaning the primary — as the node on which to deploy SiteScope monitors.

If you switch from the primary to the failover server, MA deployment jobs will fail if the agent is down or unreachable and you get an event in the browser to that effect. When the primary is available again, you can restart the deployment job.

If you switch from the primary to the failover server, MA deployment jobs will appear to be successful in the UI if the agent remains running and reachable on the primary. However, although the policy is installed and enabled on the agent, the sisconfig process on the agent fails to import the template to SiteScope. The %OvDataDir%log\system.0.en_US log file shows an error similar to the following:

Feb 10, 2017 3:37:06 PM;4;11;com.hp.ov.xpl.log.OvLogger;logMessage;com.hp.ov.opr.sisconfig;SEVERE;java.lang.Exception: Failed to import template importTemplateWithOverride(). Path: 'Deployed from HP Monitoring Automation/omi.example.com/MSSQLServer_ResponseTime (:MSSQLServer_ResponseTime)'., java.net.ConnectException: Connection refused: connect
Feb 10, 2017 3:37:06 PM;5;11;com.hp.opr.sis.config.connector.PolicyWorker;run;com.hp.ov.opr.sisconfig;SEVERE;Error during policy operation. , java.lang.Exception: Failed to import template importTemplateWithOverride(). Path: Deployed from HP Monitoring Automation/omi.example.com/MSSQLServer_ResponseTime (:MSSQLServer_ResponseTime).

This message shows that the failure occurs when importing the template which is the precursor to deploying the template to the monitored CI(s); so it does not actually show which monitored CIs are impacted. This makes it more challenging to determine what to redeploy.

Due to this, we recommend to do the following:

• Avoid deploying monitoring to SiteScope when the primary server is not running.
• Create a policy to monitor %OvDataDir%log\system.0.en_US and generate an event for import failures.

SiteScope logging

By default, two types of daily log files are generated: v1 (legacy) and v2. If you are not using the SiteScope baselining feature, we recommend to disable the legacy daily log (v1) by setting the property _shouldLogToLegacyDailyLog=false in the <SiteScope root>\groups\master.config file.

By default, SiteScope retains daily logs for 40 days. Unless you need this for SiteScope’s own reports or to use OMi Performance Dashboard to graph a short time frame up to 40 days ago, you can reduce this to save disk space, and rely on OBR for longer term reporting.

For example, to keep 15 days of data, update the line property _dailyLogKeepDays=15 in the <SiteScope root>\groups\master.config file.

Use the following information to troubleshoot problems with your OMi-SiS integration.

SiteScope (non-TLS) - OMi (TLS) integration fails when configuring the connected server

The non-HTTPS SiteScope tries to communicate with HTTPS OMi via SSLv3, which is not allowed due to OMi's TLS configuration. Due to this, Apache aborts the connection attempts. If possible, switch SiteScope to HTTPS and retry the integration. If this is not possible, make sure that SiteScope and OMi exclude the same protocols and cyphers.

Duplicate SiteScope node CIs in the OMi RTSM

If you have duplicate SiteScope node CIs in the RTSM, you have to merge the CIs as follows:

1. Go to Administration > RTSM Administration > Modeling > IT Universe Manager.

2. Search for the SiteScope node CIs.

3. Select the duplicate CIs, right-click and select Merge CIs from the context menu. As the merge target, select the CI that has the FQDN as primary domain name.

You can integrate NNMi with OMi to provide the following capabilities:

• NNMi topology > OMi RTSM topology. The topology integration populates the OMi RTSM with the NNMi network topology. OMi stores each device, interface, IP address, and a few other artifacts in the NNMi network topology as a CI and includes it in the relevant views.

• NNMi events > OMi events. NNMi events are displayed in the Event Browser in OMi. You can also access the NNMi console from the OMi Event Browser. The NNMi events are sent to OMi by using the Operations Connector. NNMi events are automatically closed when OMi events are closed.

  This integration has item ID 344 in the Integrations Catalog at the following location:

  https://softwaresupport.hpe.com/km/KM01694988

• NNMi events > OMi health indicators. After you have set up the integration, if the NNMi events have corresponding health indicators defined, these health indicators affect the status of relevant CIs in OMi applications, such as Service Health.

• OMi > NNMi drill down. In OMi, you can configure a link to the NNMi management server that enables you to drill down from My Workspace and other locations to NNMi, to view trace route information between the client and the destination machine. You can also use URL tools to launch a browser that enables you to connect to the NNMi management server and further analyze incoming events in NNMi.

  In addition, certain NNMi user interface components (network maps, items, detailed information dialogs, and so on) can be displayed directly in Workspaces > My Workspace.

Complete the following workflow to configure and use the NNMi integration:

1. Perform the integration in NNMi

   Perform the steps needed to integrate NNMi with OMi in the NNMi application.

   For details, see the Network Node Manager i Software—Business Service Management/Universal CMDB Topology Integration Guide.

2. Configure LW-SSO in both OMi and NNMi

   To be able to seamlessly switch between NNMi and OMi, it is recommended to use LW-SSO. Make sure that LW-SSO is configured in both OMi and NNMi with the same initString. For details on how to configure the initString in OMi, see the OMi Administration Guide. For details on how to configure the initString in NNMi, see the NNMi Deployment Reference.

   It is also possible to integrate NNMi with OMi without using LW-SSO. In this case, you are prompted for a password every time you switch to an NNMi component.

3. Connect NNMi to more than one OMi instance

   After connecting the first OMi instance to NNMi, NNMi stores in its own database the CI IDs gained from the topology synchronization of the OMi's RTSM. When another OMi instance is connected, another topology synchronization is carried out. As the OMi instances might contain some of the same CI IDs, the IDs need to be reconciled in the NNMi database. This reconciliation works only partially and the NNMi log files still include several reconciliation errors that are caused by the non-existing RTSM IDs. To fix the problem, perform the following steps:

   1. Change the integration to the new OMi system.

   2. Log on to the NNMi JMX console http://<NNMi_fqdn_and_port>/jmx-console using the system account and password.

   3. Go to mbean NnmBsmModule.

   4. Run java.lang.String resetNnmBsmIds().

   You should see a list of devices from which the RTSM ID was removed.

   5. Disable and enable the topology integration to get the CIs into RTSM.

4. Configure OMi to display NNMi data

   To display NNMi data in OMi and to access the NNMi components in Workspaces > My Workspace:

   1. Open Infrastructure Settings:

      Administration > Setup and Maintenance > Infrastructure Settings

   2. Select Foundations.

   3. Select Integrations with other applications.

   4. In the Integrations with other applications - HPENNM table, locate and modify the following parameters:

   • HPENNM Integration URL. The NNMi host and port number (protocol://host:port/nnm).

   • HPENNM UI drilldown use global CI ID. Set to true if the NNMi topology integration is synchronized to a different RTSM or UCMDB.

   Users are authenticated by LW-SSO, but an internal user is required.

5. Results

   You can view NNMi data in Workspaces > My Workspace, as follows:

   Note Make sure you have a View Explorer component configured in addition to the new NNMi component. The View Explorer component pulls the node information needed by the NNMi component. For more information on the View Explorer component, see the OMi User Guide.

   1. Click the New Page icon.
   2. Click Add Component. The Component Gallery window opens.
   3. In All Categories, select the NNMi check box.

   To access the NNMi components, you must have the appropriate licenses installed. NNMi components are only displayed if you configured a connection to an NNMi server in Infrastructure Settings:

   Administration > Setup and Maintenance > Infrastructure Settings

   Select Foundations > Integrations with other applications > HPENNM

   Component Name	Description
   Layer 2 Neighbor View	Shows a map view of a selected device and its connector devices within a specified number of hops from the selected device. This view is useful for understanding the switch connectivity between devices.
   Layer 3 Neighbor View	Shows a map view of a selected device and its connector devices within a specified number of hops from the selected device. This view is useful for understanding the router connectivity between devices.
   MPLS VPN Inventory	This is an enterprise customer view of how their sites are connected via service provided MPLS networks.
   Open Key Incidents	Shows the incidents that are most important to network operators and that often require more immediate action.
   Overall Network Health (Node Group Overview)	Displays a map containing all (top-level) Node Groups that do not have parent Node Groups.
   Overall Network Health - Routers	Displays a Node Group Map of the Router connectivity in your network.
   Overall Network Health - Switches	Displays a Node Group map of the Switches connectivity in your network.
   Router Redundancy Groups Inventory	Shows the available Router Redundancy Groups created by the NNMi administrator. Each Router Redundancy Group is a set of two or more routers that use one or more virtual IP addresses to help ensure that information packets reach their intended destination.

Operations Manager (OM) can be integrated into your OMi environment to become a data source for OMi. OM for Windows, OM for UNIX (HP-UX and Solaris), and OM for Linux are supported.

After you install both OMi and OM, follow the described procedures to connect OMi and OM. This connection enables bidirectional synchronization of events between the two systems, tool execution, and instruction text retrieval. The connection configuration requires you to establish a trust relationship between the OMi and OM systems, as well as to configure a message forwarding policy.

The integration between OMi and OM provides you with the following capabilities:

• OM events > OMi. Events from OM are displayed in the OMi Event Browser.

• OM events > OMi health indicators. After you set up the integration, if the OM events have corresponding health indicators defined, these health indicators automatically affect the status of the relevant Configuration Items (CIs) in OMi applications such as Service Health. For an introduction to health indicators, see the OMi User Guide.

• OMi Actions, Tools, and Instructions. You can specify tools, for example, to ping a system. These tools are launched from events or the Actions panel and run on the associated CI. The tools are designed to help users solve common problems quickly and efficiently. All available tools are launched in the context of a CI. The selection of tools a particular user sees in context menus depends on the tools that are available for the CI affected by a particular event.

  Events received in the OMi Event Browser may contain event-related actions configured in OM. If event-related actions exist, you can run these actions from the OMi console. OM actions can be either operator-initiated, or can run automatically when an event occurs. For a complete overview of available actions and how to run them, see OMi Help.

  Operators working with the OM message browser can see additional instructions for the selected message. It is equally helpful for OMi operators to be able to access this information when using OM servers to forward events to OMi. This information is displayed in the Instructions tab of the Event Browser. For details, see the OMi User Guide.

• OM topology > RTSM topology. The OM topology can synchronize with the OMiRTSM topology. Using topology synchronization, the OM services are synchronized with OMi, and by using corresponding mapping rules, they are transformed into CIs stored in the RTSM. For details, see the OMi Administration Guide.

  Note If the OM topology is not synchronized with the RTSM topology by using the OMi topology synchronization mechanism, the Monitored by property of the OMi CIs corresponding to the OM services may be empty. As a consequence, these CIs are not displayed in the System Monitors only Perspective, System Hardware Monitoring, and System Software Monitoring views.

Complete the following workflow to configure and use the OM integration:

1. Set up OMi in an environment managed by OM

   To set up OMi in an environment managed by OM, follow these steps:

   1. Before installing OMi, run the following command on all data processing servers and gateway servers:

      ovconfchg -ns sec.cm.client -set CERTIFICATE_SERVER <FQDN of primary DPS>

   2. Install and configure OMi according to the OMi Installation and Upgrade Guide.

   3. Integrate OM as described in the following steps.

   Optional. Set up forwarding targets for OM agent node creation

   To ensure that events are assigned to the correct CIs, the nodes in the OMi RTSM or UCMDB need to be synchronized with the OM node bank(s). You can use the OM Agent Node Creation Forwarding Targets infrastructure setting to forward topology data from operations agents monitored by OMi to a specified OM for LinuxWindows server(s). After the topology information is forwarded from OMi, a node is created in the OM for LinuxWindows server. The platform of the synchronized node is displayed as other in OM for Linuxn/a in OM for Windows.

   To set up a forwarding target for the creation of an agent node, edit the OM Agent Node Creation Forwarding Targets infrastructure setting:

   1. In OMi, navigate to

      Administration > Setup and Maintenance > Infrastructure Settings

   2. Select Applications and use the list to select the Operations Management context. Scroll down to Operations Management - HPEOM Topology Synchronization Settings.

   3. Next to the OM Agent Node Creation Forwarding Targets setting, click Edit.

   4. Enter your target server in the Value field.

      If you want to enter more than one target server, separate them with a semi-colon.

   5. Click OK to save.

2. Establish a trust relationship for a server connection

   For connection and communication between OMi and OM hosts, you must establish a trust relationship between the systems.

   In OM server pooling, the virtual server must have a certificate that is trusted by all OM hosts in the server pool and by all OM hosts.

   Note The trust relationship must be set up on all nodes (data processing servers, gateway servers, manager-of-manager configurations, load balancers, and reverse proxies). However, some load balancer technologies include a by-pass or pass-through functionality for incoming encrypted messages to its pool members. When using such technologies, the trust relationship on the load balancer node is not required if you are load balancing on the recommended OSI layer 2 or 4.

   To establish a trust relationship between the data processing servers and external server systems, do the following:

   1. On the OMi data processing server, execute the following command:

      <OMi_HOME>/opr/bin/BBCTrustServer[.bat|sh] <external_server>

      Replace <external_server> with the FQDN of the external system (for example, ommgmtsv).

      Note The value of <external_server> should be the virtual name if the OM server is part of a server pool or runs in a high-availability (HA) cluster.

      When asked to add a certificate to the trust store, enter y.

      If the trusted certificate already exists, the tool asks you if you want to overwrite the existing certificate. To replace the existing certificate with a new one, enter y.

   2. OM servers only:

      Note If you have the appropriate OM patch or version, you can skip this step.

      • OM for Windows: Starting with patches OMW_00121 (32-bit) and OMW_00122 (64-bit), the BBCTrustServer tool is already installed in the %OvInstallDir%\contrib\OVOW folder.
      • OM for UNIX or Linux: Starting with OM server version 9.10.220, the BBCTrustServer tool is already installed in the /opt/OV/bin directory.

      1. Locate the following files on the OMi data processing server:

         <OMi_HOME>/opr/lib/cli/opr-cli.jar  

         <OMi_HOME>/opr/bin/BBCTrustServer.bat  

         <OMi_HOME>/opr/bin/BBCTrustServer.sh  

      2. Copy the files to the machine that is running the OM for Windows management server.

         Copy opr-cli.jar to %OvInstallDir%\java\opr-cli.jar.

         Copy BBCTrustServer.bat to %OvBinDir%\BBCTrustServer.bat.

      3. OM for UNIX and Linux only: Copy the files to the machine that is running the OM for UNIX or Linux management server.

         Copy opr-cli.jar to /opt/OV/java/opr-cli.jar.

         Copy BBCTrustServer.sh to /opt/OV/bin/BBCTrustServer.sh.

         Change the permissions of the BBCTrustServer tool by entering the following command:

         chmod 555 /opt/OV/bin/BBCTrustServer.sh

   3. If you do not have a load balancer or a reverse proxy, or your load balancer is configured to work on OSI layers 2 or 4 (recommended), execute the following command on the external system:

      BBCTrustServer.[bat|sh] <load_balancer_or_single_gateway_server_or_RP_or_Server_Pool_Virtual_Interface>

      When asked to add a certificate to the trust store, enter y.

      If the trusted certificate already exists, the tool asks you if you want to overwrite the existing certificate. To replace the existing certificate with a new one, enter y.

   4. If you are using a reverse proxy or your load balancer is configured to work on OSI layer 7, you must exchange the certificates manually:

      1. On the OMi data processing server, execute the following command:

         ovcert -exporttrusted -file <omi.cer>

      2. On the external system, execute the following command:

         ovcert -exporttrusted -file <other.cer>

      3. Copy <other.cer> from the external system to the OMi data processing server.

      4. Copy <omi.cer> from the OMi data processing server to the external system.

      5. On the OMi data processing server, execute the following commands:

         ovcert -importtrusted -file <other.cer>  

         ovcert -importtrusted -file <other.cer> -ovrg server

      6. On the external system, execute the following commands:

         ovcert -importtrusted -file <omi.cer>  

         ovcert -importtrusted -file <omi.cer> -ovrg server

   5. If you are using a load balancer or a reverse proxy, where your data sources are not communicating directly with the OMi gateway servers, make sure that port 383 is routed through the load balancer to the OMi gateway servers.

      If the load balancer or the reverse proxy is configured to pass through traffic directly (OSI layers 2 or 4), skip to the next step. If configured to work on OSI layer 7, perform as follows:

      • The certificate on the load balancer must be installed for port 383 (or the port that you configured for secure communication).

      • Communication between the load balancer and the gateway server systems must be secured.

      • The load balancer must possess a server certificate for authentication so that the external systems can connect successfully. The load balancer must also validate client certificates presented by external clients (for example, OM servers).

      • The load balancer must possess a client certificate for authentication with OMi.

      1. Issue a certificate for the load balancer from the OMi data processing server:

         ovcm -issue -file <certificate file> -name <Fully Qualified Domain Name of Virtual Interface or Reverse Proxy> [ -pass <passphrase>]

      2. Import this certificate as a server and client certificate into your load balancer.

         For details on the required format, see your load balancer documentation. You can use openssl to convert the certificates into the required format.

3. Verify the trusted relationship

   After establishing a trust relationship between the OMi data processing server and external systems, check the connection between the two systems. You can do this wile setting up your connected server by clicking Run Test or by using the command line interface.

   To check the connection between the OMi server environment and an external system by using the command line interface, do the following:

   1. From the external host, verify that communication to the OMi installation is possible (the return value should be eServiceOk) by executing the following command on the external server system:

      bbcutil -ping https://<load_balancer_or_single_gateway_server_or_RP_or_Server_Pool_Virtual_Interface>  

      When done between management servers, add the -ovrg server option to esure the server certificate is used instead of the node certificate, as follows:

      bbcutil -ovrg server -ping https://<load_balancer_or_single_gateway_server_or_RP_or_Server_Pool_Virtual_Interface>  

      Example of the command result:

      https://<OMi servername>: status=eServiceOK
coreID=7c66bf42-d06b-752e-0e93-e82d1644cef8 bbcV=06.10.105
appN=ovbbccb appV=11.03.031 conn=1 time=1094 ms

   2. From all OMi gateway server hosts, verify that communication with the external server host is possible (the return value should be eServiceOk) by executing the following command:

      bbcutil -ping https://<external server hostname>  

      When done between management servers, add the -ovrg server option to esure the server certificate is used instead of the node certificate, as follows:

      bbcutil -ovrg server -ping https://<external server hostname>

      Example of the command result:

      https://<external_host_server_name>: status=eServiceOK
coreID=0c43c032-5c94-7535-064a-f7654a86f2d3 bbcV=06.10.070
appN=ovbbccb appV=11.03.031 conn=7 time=140 ms

      Note

      If the bbcutil –ping command executes but does not return eServiceOk, you may need to restart the ovc processes on the system that is not responding by running the following command on the OM side:

      • /opt/OV/bin/ovc –kill and /opt/OV/bin/ovc –start
      •  ovc –kill and ovc –start
4. Create a connection to an OM server

   OMi can run actions and tools on the OM server, and retrieve instructions from the OM server. Credentials for the OM web service are required for this processing.

   1. In OMi, navigate to Administration > Setup and Maintenance > Connected Servers, click New and select Operations Manager for UNIXOperations Manager for Windows. Alternatively, you can click New in the Operations Manager for UNIXOperations Manager for Windows area in the right pane.

      The Create Operations Manager for UNIX ServerCreate Operations Manager for Windows Server panel opens.

   2. In the General section, enter a display label, an identifier (a unique internal name if you want to replace the automatically generated one), and, optionally, a description of the connection being specified.

   3. In the Server Properties section, complete the following information:

      1. Enter the fully qualified domain name of the host system of the OM server.

         Note If the host system is a high-availability cluster, enter the fully qualified domain name of the cluster package where the OM server is installed. If OM is installed in a server pooling environment, add the virtual interface as the first OM server. Add all physical pool servers separately as connected servers.

      2. Enter the name of the integration user that is used to log in to the OM server.

         For OM for Windows servers, specify both the domain to which the host system belongs and the user name: <DOMAIN>\<user name>. If the host system is not part of a domain, replace <DOMAIN> with the host name of the system.

         HPE recommends to use a dedicated user so that it is clear which events are owned by and being worked on in OMi.

         Note All messages forwarded from OM systems are treated as allowing read and write. Any changes made to these events result in back synchronization to the originating OM server.

         • For OM for Windows, the selected user must have at least PowerUser rights and must be a member of the HP-OVE-Admins group and the local administrators group (for example, HP-OVE-User).
         • For OM for UNIX or Linux, only the Integration User (opc_adm) has the necessary OM administrator rights to be able to synchronize topology and execute tools.
         • If you want to specify a user name that is different from opc_admin for synchronizing events, you can create two connected servers, one for the web services that handle actions, tools and instructions as the opc_adm user, and another that references the connected server with another user name.

      3. Select the Enable sending event updates to the Operations Manager for UNIX serverEnable sending event updates to the Operations Manager for Windows server check box if you want to forward enable synchronization of event changes from OMi to OM. For example, if OM forwards a message to OMi and OMi changes it, then the changes are synchronized back to OM.

      4. Optional. Customize the way events and change notifications are delivered to this server by using Advanced Delivery Options:

         (missing or bad snippet)

      5. Select the Forward dynamic topology check box if you want to forward dynamic topology information from the OMi instance to which you are logged in, to the OM instance that you are currently configuring.

         Important In most cases, you should leave the Forward dynamic topology check box clear. Otherwise, OMi will resend the topology data received from one OM server to the rest of the OM servers. This may lead to unexpected consequences on OM servers (for example, a deleted node on an OM server may reappear after some time, or new nodes may appear on an OM server after you add a node by using a data collector, such as SiteScope).

         (missing or bad snippet)

   4. In the Outgoing Connection section, complete the following information:

      Note If you are editing outgoing connection properties, you must restart the MercuryAS process for the changes to take effect.

      • Select Use this server if you are using this server for receiving instructions, and executing tools and actions on external nodes, and then follow these steps:

        1. Enter the password for the integration user.

        2. Enter the port required to access the server for receiving instructions, and executing tools and actions. The default port value is automatically inserted and can be restored by clicking Set default port.

        3. Optional. If you are using secure communication (default), make sure that the Use secure HTTP check box is selected, and then apply a certificate by clicking import the certificate and using one of the following methods:

           • Connect and Import from Server: Retrieves a certificate from the host system specified in this server connection.

           • Import from File: Opens the file browser and enables you to navigate to and specify a Base64 Encoded X.509 certificate file for the server connection.

           Note In a clustered OM for Windows environment, the IIS web server on all cluster nodes must have the same certificate. If different, valid certificates are used, problems such as tools execution may be experienced after switching to a node with a different certificate. For more details, see the article available at https://softwaresupport.hpe.com/km/KM01211399.

      • Select Use other server if you are using an alternative server for providing instructions, and executing actions and tools, and then select a server from the list. For the physical servers in a server pooling environment, select the virtual interface connected server.

        Note Avoid selecting an alternative action execution server that creates a loop and results in specifying the connected server as the action execution server.

   5. In the Test Connections section, click Run Tests to check that the specified connection attributes are correct. If an error message is displayed, correct the connection information, and retest the connection. Check <OMi_HOME>/log/jboss/opr-webapp.log on the gateway server for more information if the test fails.

   6. Make sure that the Activate after save check box is selected if you want to enable the server connection immediately.

   7. Click Create.

5. Configure topology synchronization

   After ensuring that the OM server is added to OMi as a connected server, configure the forwarding of topology (node and service) data on the OM server.

   Configure topology synchronization on OM for Windows systems

   This section describes how to configure topology synchronization on OM for Windows management servers. For further details, see the OM for Windows documentation.

   To forward topology data to OMi, complete the following steps on the OM for Windows management server from which you want to receive topology information:

   1. Prerequisite. Make sure that the minimum patch level for the OM for Windows management server is installed:

      • Version 8.16: Patch OMW_00121 or superseding patch

      • Version 9.00: Patch OMW_00122 or superseding patch

   2. Prerequisite. Configure trusted certificates for multiple servers.

      If you plan to forward topology to multiple destinations, each target (or destination) server must have trust configured with the OM server.

   3. In the console tree, right-click Operations Manager, and then click Configure > Server.... The Server Configuration dialog box opens.

   4. Click Namespaces, and then click Discovery Server. A list of values appears.

   5. Add the hostname of the gateway server or load balancer to List of target servers to forward discovery data. If there is more than one target server, separate the hostnames with semicolons, for example:

      server1.example.com;server2.example.com

      If the target server uses a port other than port 383, append the port number to the hostname, for example:

      server1.example.com:65530;server2.example.com:65531

   6. Make sure that the value of Enable discovery WMI listener is true. This is the default value.

   7. Click OK to save your changes and close the Server Configuration dialog box.

   8. Restart the OvAutoDiscovery Server service for your changes to take effect:

      net stop "OvAutoDiscovery Server"

      net start "OvAutoDiscovery Server"

   9. Start the initial synchronization of topology data:

      1. In the console tree, select Tools > HP Operations Manager Tools.

      2. Right-click Synchronize Topology and select All Tasks > Launch Tool....

         The startInitialSync.bat tool is started and begins to send all the topology data to the configured target management servers.

   Migrate from scheduled synchronization on OM for Windows systems

   This section describes how to migrate from scheduled synchronization on OM for Windows management servers. For further details, see the OM for Windows documentation.

   To migrate from scheduled synchronization, complete the following steps on the OM for Windows management server from which you want to receive topology information:

   1. Prerequisite. Make sure that the minimum patch level for the OM for Windows management server is installed:

      • Version 8.16: Patch OMW_00121 or superseding patch

      • Version 9.00: Patch OMW_00122 or superseding patch

   2. Clear the agent repository cache on the OM management server by using the following command:

      %OvBinDir%\ovagtrep -clearall

   3. Remove the service auto-discovery policies from the OM management server node:

      %OvBinDir%\ovpolicy -remove DiscoverOM

      %OvBinDir%\ovpolicy -remove DiscoverOMTypes

   4. Synchronize the policy inventory on the OM management server:

      1. In the console tree, right-click the management server.

      2. Select All Tasks > Synchronize inventory > Policies.

      The management server creates a deployment job to retrieve the inventory from the local agent.

   5. Make sure the listener process is running:

      1. In the console tree, right-click Operations Manager, and select Configure Server.

      The Server Configuration dialog box opens.

      2. Click Namespaces, and select Discovery Server.

      A list of values appears.

      3. Set the value of Enable discovery WMI listener to true. This is the default value.

      4. Click OK to save your changes and close the Server Configuration dialog box.

      5. Restart the OvAutoDiscovery Server service for your changes to take effect:

      net stop "OvAutoDiscovery Server"

      net start "OvAutoDiscovery Server"

   6. Start the initial synchronization of topology data:

      1. In the console tree, select Tools > HP Operations Manager Tools.

      2. Right-click Synchronize Topology and select All Tasks > Launch Tool....

      The startInitialSync.bat tool is started and begins to send all the topology data to the configured target servers.

   Configure topology synchronization on OM for UNIX or Linux systems

   This section describes how to configure topology synchronization on OM for UNIX or Linux management servers. For further details, see the OM for UNIX or Linux documentation.

   To forward topology data to OMi, complete the following steps on the OM for UNIX or Linux management server from which you want to receive topology information:

   1. Prerequisite. Make sure that the minimum patch level for the OM 9.10 for UNIX or Linux management server is installed:

      • HP-UX: Patch PHSS_42736 or superseding patch
      • Linux: Patch OML_00050 or superseding patch
      • Solaris: Patch ITOSOL_00772 or superseding patch

   2. Prerequisite. Configure trusted certificates for multiple servers.

      In an environment with multiple servers, you must configure each server to trust certificates that the other servers issued.

   3. Prerequisite. Set up the forwarding target (OMi Gateway Server, Reverse Proxy, or Load Balancer) in the node bank as a managed node. To do so, run the following command:

      /opt/OV/bin/OpC/utils/opcnode -add_node node_name=<node_name> net_type=NETWORK_IP mach_type=<machine_type> group_name=<group_name> node_label=<node_name>

      In this instance, <machine_type> relates to the operating system of the OMi host system, MACH_BBC_WIN2K3_X64 (Windows) or MACH_BBC_LX26RPM_X64 (Linux), whereas <group_name> relates to the operating system of the OM server host system, hp_ux, solaris, or linux.

   4. Type the following command to enable topology synchronization:

      /opt/OV/contrib/OpC/enableToposync.sh -online -target <comma_separated_server_list>

      Replace <comma_separated_server_list> with the fully qualified domain name of the target management server. If you have more than one target management server, separate each server name with a comma (,). Do not include spaces in the server list.

      This command restarts the service discovery server. The source management server begins to send any topology data changes immediately.

   5. Type the following command to start the initial synchronization of topology data:

      /opt/OV/bin/OpC/startInitialSync.sh

   Migrate from scheduled synchronization on OM for UNIX or Linux Systems

   This section describes how to migrate from scheduled synchronization on OM for UNIX or Linux management servers. For further details, see the OM for UNIX or Linux documentation.

   To migrate from scheduled synchronization, complete the following steps on the OM for UNIX or Linux management server from which you want to receive topology information:

   1. Prerequisite. Make sure that the minimum patch level for the OM 9.10 for UNIX or Linux management server is installed:

      • HP-UX: Patch PHSS_42736 or superseding patch
      • Linux: Patch OML_00050 or superseding patch
      • Solaris: Patch ITOSOL_00772 or superseding patch

   2. Clear the agent repository cache on the management server by using the following command:

      /opt/OV/bin/ovagtrep -clearall

   3. Remove the service auto-discovery policies from the management server node:

      /opt/OV/bin/ovpolicy -remove DiscoverOM

      /opt/OV/bin/ovpolicy -remove DiscoverOMTypes

   4. Deassign the service auto-discovery policies from the management server node:

      /opt/OV/bin/OpC/utils/opcnode -deassign_pol node_name=<management_server> net_type=NETWORK_IP pol_name=DiscoverOMTypes pol_type=svcdisc

      /opt/OV/bin/OpC/utils/opcnode -deassign_pol node_name=<management_server> net_type=NETWORK_IP pol_name=DiscoverOM pol_type=svcdisc

      /opt/OV/bin/OpC/opcragt -dist <management_server>

      Replace <management_server> with the name of the management server.

   5. Type the following command to enable topology synchronization:

      /opt/OV/contrib/OpC/enableToposync.sh -online

      This command restarts the service discovery server. The source management server begins to send any topology data changes immediately.

   6. Type the following command to start the initial synchronization of topology data:

      /opt/OV/bin/OpC/startInitialSync.sh

6. Configure the OM for WindowsLinux forwarding policy

   To enable event synchronization between OM and OMi, set up a message forwarding policy on the OM server. The policy includes the node name of the target OMi server. Alternatively, specify the load balancers, if configured, or one Gateway Server for each OMi installation, as appropriate for your high-availability arrangement.

   Before setting up a policy and to avoid overwriting the current settings, verify if a policy of the type Server-based Flexible Management is already active on the OM for Windows server. If a policy does not exist, create a new policy as described in Create a New Policy. If a policy already exists and is active, adapt the policy as described in Adapt an Active Policy.

   Create a New Policy

   To set up a new policy on OM for Windows, complete the following steps:

   1. Start the OM for Windows console as follows:

      Start > Programs > HP > HP Operations Manager

   2. In the left pane of the OM for Windows console, select the following:

      Policy management > Policies grouped by type > Server Policies > Server-based Flexible Management

   3. Verify that no Server-based Flexible Management policy exists. If such a policy does exist, go to Adapt an Active Policy.

   4. Right-click Server-based Flexible Management (or a blank space in the right pane), and then select New > Policy.

      The Server-based Flexible Management Editor dialog box opens.

   5. In the General tab text pane, insert the following policy text:

      TIMETEMPLATES
      # none
      RESPMGRCONFIGS
         RESPMGRCONFIG DESCRIPTION "Forward all messages to OMi"
         SECONDARYMANAGERS
         ACTIONALLOWMANAGERS
         MSGTARGETRULES
            MSGTARGETRULE DESCRIPTION "Forward all messages rule"
               MSGTARGETRULECONDS
               MSGTARGETRULECOND DESCRIPTION "Forward all messages"
               MSGTARGETMANAGERS
                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<OMi fully qualified host name>"
      

      Note This forwards all messages to OMi. If you want to reduce the number of messages to be sent, modify the text of the policy so that only a selected subset of messages is sent to OMi. For details, see the OM documentation.

   6. Replace <OMi fully qualified host name> in the policy text with the fully qualified hostname of the Gateway server to receive OM messages (for example, GwSrv.example.com).

      In deployments involving a load balancer, a NAT device, or a reverse proxy, use the fully qualified hostname of the system used to access the Gateway server (for example, VirtualSrv.example.com).

   7. Click Check Syntax to check for syntax errors in the new policy text.

   8. After correcting any syntax errors, click Save and Close.

   9. In the Save As dialog box that opens, enter a name and a description for the new policy.

   10. Click OK to close the Save As dialog box.

   11. From the Policy Management folder, right-click the policy, and the select All Tasks > Deploy on.

   12. In the Deploy server policy on dialog box that opens, select the name of your OM management server.

   13. Click OK to deploy the server-based flexible management policy on the OM for Windows management server.

   Adapt an Active Policy

   If a message forwarding policy already exists on the OM for Windows system, complete the following steps to edit this policy and add another message target manager to it:

   1. Start the OM for Windows console as follows:

      Start > Programs > HP > HP Operations Manager

   2. In the left pane of the OM for Windows console, select the following:

      Policy management > Server policies grouped by type > Server-based Flexible Management

   3. In the right pane of the OM for Windows console, double-click the existing policy that you want to edit. The Server-based Flexible Management Editor dialog opens.

      If such a policy does not exist, go to Create a New Policy.

   4. Add another message target manager as shown in the following example policy text:

      TIMETEMPLATES
      # none
      RESPMGRCONFIGS
         RESPMGRCONFIG DESCRIPTION "Forward all messages to OMi"
         SECONDARYMANAGERS
         ACTIONALLOWMANAGERS
         MSGTARGETRULES
            MSGTARGETRULE DESCRIPTION "Forward all messages rule"
               MSGTARGETRULECONDS
               MSGTARGETRULECOND DESCRIPTION "Forward all messages"
               MSGTARGETMANAGERS
                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<First Target Manager>"

                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<OMi fully qualified host name>"

      Note This forwards all messages to OMi. If you want to reduce the number of messages to be sent, modify the text of the policy so that only a selected subset of messages is sent to OMi. For details, see the OM documentation.

   5. Replace <OMi fully qualified host name> in the text with the fully qualified hostname of the Gateway server that should receive OM messages (for example, GwSrv.example.com).

      In deployments involving a load balancer, a NAT device, or a reverse proxy, use the fully qualified hostname of the system used to access the Gateway server (for example, VirtualSrv.example.com).

   6. Click Check Syntax to check for syntax errors in the new policy text.

   7. After correcting any syntax errors, click Save and Close.

   8. Redeploy the server-based flexible management policy on the OM for Windows management server.
   
   

   To enable event synchronization between OM and OMi, you must set up a message forwarding policy on each OM management server with the node name of the load balancer, if configured, or one Gateway Server, as appropriate for your high-availability arrangement.

   Before setting up a policy, make sure that the forwarding target is set up as a node (see Set up a Forwarding Target in the OM for UNIX or Linux Node Bank). In addition, verify if the msgforw policy is already active on the OM for UNIX or Linux server. If the msgforw does not exist, create a new policy as described in Create a New Policy. If the msgforw policy already exists and is active, adapt the policy as described in Adapt an Active Policy.

   Set up a Forwarding Target in the OM for UNIX or Linux Node Bank

   The forwarding target (OMi Gateway Server, Reverse Proxy, or Load Balancer) must be set up in the node bank as a managed node. You must add the managed node and put it in a node group by using the opcnode command line tool:

   /opt/OV/bin/OpC/utils/opcnode -add_node node_name=<node_name> net_type=NETWORK_IP mach_type=<machine_type> group_name=<node_group_name> node_label=<node_name>

   In this instance, <machine_type> relates to the operating system of the OMi host system, MACH_BBC_WIN2K3_X64 (Windows) or MACH_BBC_LX26RPM_X64 (Linux). <group_name> is the name of a node group, which can be an operating system name like linux, or any other name.

   To verify that the node was added successfully, run the following command:

   /opt/OV/bin/OpC/utils/opcnode -list_nodes

   Create a New Policy

   To set up a new message forwarding policy on OM for UNIX or Linux, complete the following steps:

   1. Change to the work_respmgrs directory as follows:

      cd /etc/opt/OV/share/conf/OpC/mgmt_sv/work_respmgrs/

      Note Policy template files can be found in /etc/opt/OV/share/conf/OpC/mgmt_sv/tmpl_respmgrs.

   2. Create a new policy file by using the following command:

      vi <policy file name>

   3. Insert the following text into the new policy file:

      TIMETEMPLATES
      # none
      RESPMGRCONFIGS
         RESPMGRCONFIG DESCRIPTION "Forward all messages to OMi"
         SECONDARYMANAGERS
         ACTIONALLOWMANAGERS
         MSGTARGETRULES
            MSGTARGETRULE DESCRIPTION "Forward all messages rule"
               MSGTARGETRULECONDS
               MSGTARGETRULECOND DESCRIPTION "Forward all messages"
               MSGTARGETMANAGERS
                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<OMi fully qualified host name>"
      						

      Note This forwards all messages to OMi. If you want to reduce the number of messages to be sent, modify the text of the policy so that only a selected subset of messages is sent to OMi. For details, see the OM documentation.

   4. Replace <OMi fully qualified host name> in the text with the fully qualified hostname of the Gateway server that should receive OM messages (for example, GwSrv.example.com).

      In deployments involving a load balancer, a NAT device, or a reverse proxy, use the fully qualified hostname of the system used to access the Gateway server (for example, VirtualSrv.example.com).

   5. Enter the following command to check for syntax errors in the new policy text:

      /opt/OV/bin/OpC/opcmomchk -msgforw <policy file name>

   6. After correcting any syntax errors, copy the policy to the msgforw policy file in the respmgrs directory as follows:

      cp <policy file name> /etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs/msgforw

   7. Inform the server processes to reread the configuration as follows:

      /opt/OV/bin/ovconfchg

      Message forwarding from OM to OMi is now configured and enabled.

   Adapt an Active Policy

   If the message forwarding policy already exists on the OM for UNIX or Linux system, complete the following steps to edit this policy and add another message target manager to it:

   1. Change to the work_respmgrs directory as follows:

      cd /etc/opt/OV/share/conf/OpC/mgmt_sv/work_respmgrs/

      Note Policy template files can be found in /etc/opt/OV/share/conf/OpC/mgmt_sv/tmpl_respmgrs/.

   2. Edit the existing policy to which you want to add the OMi server as a target as follows:

      vi <policy file name>

   3. Add another message target manager as shown in the following policy text:

      # none
      RESPMGRCONFIGS
         RESPMGRCONFIG DESCRIPTION "Forward all messages to OMi"
         SECONDARYMANAGERS
         ACTIONALLOWMANAGERS
         MSGTARGETRULES
            MSGTARGETRULE DESCRIPTION "Forward all messages rule"
               MSGTARGETRULECONDS
               MSGTARGETRULECOND DESCRIPTION "Forward all messages"
               MSGTARGETMANAGERS
                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<First Target Manager>"

                  MSGTARGETMANAGER
                  TIMETEMPLATE "$OPC_ALWAYS"
                  OPCMGR IP 0.0.0.0 "<OMi fully qualified host name>"

      Note This policy forwards all messages to OMi. If you want to reduce the number of messages to be sent, modify the text of the policy so that only a selected subset of messages is sent to OMi. For details, see the OM documentation.

   4. Replace <OMi fully qualified host name> in the text with the fully qualified hostname of the Gateway Server system that should receive OM messages (for example, GwSrv.example.com).

      In deployments involving a load balancer, a NAT device, or a reverse proxy, use the fully qualified hostname of the system used to access the Gateway Server system (for example, VirtualSrv.example.com).

   5. Enter the following command to check for syntax errors in the new policy text:

      /opt/OV/bin/OpC/opcmomchk -msgforw <policy file name>

   6. After correcting any syntax errors, copy the policy to the msgforw policy file in the respmgrs directory as follows:

      cp <policy file name> /etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs/msgforw

   7. Inform the server processes to reread the configuration as follows:

      /opt/OV/bin/ovconfchg

      Message forwarding from OM to OMi is now configured and enabled.

7. Validate event synchronization

   Do the following to validate the event synchronization between OMi and OM:

   Verify Message Forwarding from OM to OMi

   To check if the message forwarding policy for sending messages from OM to OMi is configured correctly, follow these steps:

   1. Make sure the OMi servers are running.

   2. Make sure at least one open message interface policy is deployed on your OM system. For instructions and details, see the OM documentation.

   3. On the OM system, open a command or shell prompt and create a new message by executing the following command:

   • Windows:

     opcmsg a=App o=Obj msg_text="Hello"

   • UNIX or Linux:

     /opt/OV/bin/OpC/opcmsg a=App o=Obj msg_text="Hello"

   If you configured the message forwarding policy correctly, the message arrives at the OM server and is forwarded to OMi. You can view the events with the OMi Event Browser.

   Note If the message is sent multiple times, no new message is generated by OM. These messages are regarded as duplicates and only the message duplicate count is increased.

   To generate a new message, modify the message text. For example:

   • opcmsg a=App o=Obj msg_text="Hello_002"

   • /opt/OV/bin/OpC/opcmsg a=App o=Obj msg_text="Hello_002"

   Synchronize OMi events with OM messages

   To check if a change to an event in OMi that is already synchronized between OMi and OM is resynchronized in OM, change the severity of an event as follows:

   1. Select Workspaces > Operations Console.

   2. In the Event Browser, select the event for which you want to change the severity. Choose the event that was already synchronized in OM and OMi and change its severity, for example, from minor to major.

   3. In the OM event browser, verify the severity of this event and make sure it was set to the new severity value.