Omnibus Connector Msscom

Tivoli Netcool/OMNIbus Probe for Microsoft System Center
Operations Manager
Version 3.0.5
Reference Guide
December 31, 2010

SC23-8843-02
Tivoli Netcool/OMNIbus Probe for Microsoft System Center
®
Operations Manager
Version 3.0.5
Reference Guide
December 31, 2010

SC23-8843-02
Note
Before using this information and the product it supports, read the information in “Notices and Trademarks,” on page 45.
Edition notice
This edition applies to version 3.0.5 of IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations
Manager 2007 (SC23-8843-02) and to all subsequent releases and modifications until otherwise indicated in new
editions.
This edition replaces SC23-8843-01.
© Copyright IBM Corporation 2006, 2010.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Document control page . . . . . . . . v Exporting a client certificate for the probe . . . 22
Configuring and running the probe . . . . . . 22
IBM Tivoli Netcool/OMNIbus Probe for Configuring the probe properties and probe hosts
file . . . . . . . . . . . . . . . . 22
Microsoft System Center Operations Configuring the probe for scom_tool.pl . . . . 23
Manager 2007 . . . . . . . . . . . . 1 Internationalization support . . . . . . . . 23
Summary . . . . . . . . . . . . . . . 1 Data acquisition . . . . . . . . . . . . 24
Obtaining the required patches and libraries . . . . 3 Properties and command line options . . . . 27
Installing probes . . . . . . . . . . . . . 3 Running the probe . . . . . . . . . . . 29
Configuration . . . . . . . . . . . . . . 4 Elements . . . . . . . . . . . . . . 31
Setting environment variables . . . . . . . 4 Error messages . . . . . . . . . . . . 33
Setting-up the HTTPS communication . . . . . 6 ProbeWatch messages . . . . . . . . . . 36
Creating SSL certificates . . . . . . . . . . 6 Desktop and webtop tools . . . . . . . . 37
Creating and using an OpenSSL CA . . . . . 7 Troubleshooting . . . . . . . . . . . . . 38
Creating and using a stand-alone Microsoft CA 10 Probe Java debug logging . . . . . . . . 39
Creating and using an Enterprise Microsoft CA 14
Managing CA certificates . . . . . . . . . . 17 Appendix. Notices and Trademarks . . 45
Installing trusted certificates on Windows . . . 17
Notices . . . . . . . . . . . . . . . . 45
Configuring OMCF to use the server certificate 19
Trademarks . . . . . . . . . . . . . . 47
Configuring SCOM SDK Web service . . . . . 20
Importing CAs into the trusted CAs of the JRE 21
© Copyright IBM Corp. 2006, 2010 iii

iv IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations Manager: Reference Guide
Document control page
Use this information to track changes between versions of this guide.
The IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations
Manager 2007 documentation is provided in softcopy format only. To obtain the
most recent version, visit the IBM® Tivoli® Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=/
com.ibm.tivoli.nam.doc/welcome_ptsm.htm
Table 1. Document modification history
Document Publication Comments
version date
00 December 07, First IBM publication.
2007
01 February 1, Summary section updated.
2009
Installing the probe section updated.
Configuration section updated.
Obtaining the components section added.
Setting environment variables section added.
Creating SSL CAs chapter added.
Maintaining CA certificates chapter added.
Running the probe on Windows section updated.
Properties and command line options section updated.
Details about how the probe acquires data clarified.
Elements section updated.
Error messages section updated.
Troubleshooting and known issues chapter added.
© Copyright IBM Corp. 2006, 2010 v

Table 1. Document modification history (continued)
Document Publication Comments
version date
02 December 31, Supported operating systems information updated in
2010 “Summary” on page 1.
The commands required to enable the use of the Subject

Alternative Names field corrected in “Enabling the use of
the Subject Alternative Name field for the CA” on page
11.
Steps corrected in “Configuring SCOM SDK Web service”

on page 20.
“Connecting to and disconnecting from the SCOM

server” on page 26 updated.
Topic describing peer-to-peer functionality removed.
Default values for several properties updated in

“Properties and command line options” on page 27.
vi IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations Manager: Reference Guide
IBM Tivoli Netcool/OMNIbus Probe for Microsoft System
Center Operations Manager 2007
Microsoft System Center Operations Manager 2007 is an event and performance
management tool for Windows Server System. It provides system diagnostic
functionality that includes indicating potential problems in applications and
recommending possible resolutions.
The Probe for Microsoft System Center Operations Manager 2007 uses the SCOM
Connector Framework and receives and acknowledges events from the SCOM
server. The probe can also resolve alerts in the SCOM server.
This guide contains the following sections:

v “Summary”
v “Obtaining the required patches and libraries” on page 3
v “Installing probes” on page 3
v “Configuration” on page 4
v “Creating SSL certificates” on page 6
v “Creating and using a stand-alone Microsoft CA” on page 10
v “Creating and using an Enterprise Microsoft CA” on page 14
v “Managing CA certificates” on page 17
v “Configuring and running the probe” on page 22
v “Data acquisition” on page 24
v “Properties and command line options” on page 27
v “Running the probe” on page 29
v “Elements” on page 31
v “Error messages” on page 33
v “ProbeWatch messages” on page 36
v “Desktop and webtop tools” on page 37
v “Troubleshooting” on page 38
Summary
Each probe works in a different way to acquire event data from its source, and
therefore has specific features, default values, and changeable properties. Use this
summary information to learn about this probe.
The following table provides a summary of the Probe for Microsoft System Center
Operations Manager 2007.
Table 2. Summary
Probe target Microsoft System Center Operations Manager (SCOM)
2007
Probe executable name nco_p_scom2007
Package version 3.0
© Copyright IBM Corp. 2006, 2010 1

Table 2. Summary (continued)
Probe supported on Windows
For details of the operating system versions on which

this probe is supported, see the following page on the
IBM Tivoli Netcool Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/
v8r1/index.jsp?topic=/com.ibm.netcool_OMNIbus.doc/
Supported_Platforms.htm
Properties file %OMNIHOME%\probes\arch\scom2007.props
Rules file %OMNIHOME%\probes\arch\scom2007.rules
Requirements A currently supported version of IBM Tivoli
Netcool/OMNIbus.
Microsoft System Center Operations Manager with Web

Console and Connector.
Note: The probe can run with Microsoft SCOM running
with or without Service Pack 1 installed.
probe-command-port-3
probe-nonnative-base-10
Java 1.5 (this is supplied with Netcool/OMNIbus).
Note: You must include the path to the bin/ directory

of the JRE in the $PATH environment variable.
JAXWS-RI 2.1.1
WSIT 1.0
Unrestricted JCE Policy files for SDK 1.4 (for AIX)
Perl 5.6 or later
This is required to run the scom_tool.pl file supplied

with the probe.
Note: The scom_tool.pl file provides the telnet details

for connecting to the probe, and is installed in
%OMNIHOME%\probes\win32
Connection method HTTPS Web Service
Remote connectivity The Probe for Microsoft System Center Operations
Manager 2007 can connect to a remote device. Details of
the remote device are specified using the HostsFile
property.
Licensing Electronic licensing was deprecated with the release of
IBM Tivoli Netcool V7.2.0. All IBM Tivoli Netcool V7.2.0
(and later) products use the IBM software licensing
process.
Internationalization Available
Peer-to-peer failover functionality Not available
IP environment IPv4 and IPv6
2 IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations Manager: Reference Guide
Table 2. Summary (continued)
Federal Information Processing IBM Tivoli Netcool/OMNIbus V7.2.1 and 7.3.0 use the
Standards (FIPS) FIPS 140-2 approved cryptographic provider: IBM
Crypto for C (ICC) certificate 384 for cryptography. This
certificate is listed on the NIST website at
http://csrc.nist.gov/groups/STM/cmvp/documents/
140-1/1401val2004.htm For details about configuring
Netcool/OMNIbus for FIPS 140-2 mode, see IBM Tivoli
Netcool/OMNIbus Installation and Deployment Guide
(SC23-6370).
Obtaining the required patches and libraries

The probe requires various third party patches and libraries.
To obtain JAXWS-RI 2.1.1, visit the following Web address:
https://jax-ws.dev.java.net/2.1.1/JAXWS2.1.1_20070501.jar
To obtain WSIT 1.0, visit the following Web address:
https://jax-ws.dev.java.net/files/documents/4202/55930/wsit-1_0-fcs-bin-b14-
09_apr_2007.jar
To install the jar files on the probe host, entrer the following command:
java -jar filename
Where filename is the name of one of the jar files.
Installing probes
All probes are installed in a similar way. The process involves downloading the
appropriate installation package for your operating system, installing the
appropriate files for the version of Netcool/OMNIbus that you are running, and
configuring the probe to suit your environment.
The installation process consists of the following steps:

1. Downloading the installation package for the probe from the Passport
Advantage Online website.
Each probe has a single installation package for each operating system
supported. For details about how to locate and download the installation
package for your operating system, visit the following page on the IBM Tivoli
Information Center:
com.ibm.netcool_OMNIbus.doc/probes/install/wip/out-html/reference/
install_download_intro.html
2. Installing the probe using the installation package.
The installation package contains the appropriate files for all supported
versions of Netcool/OMNIbus. For details about how to install the probe to
run with your version of Netcool/OMNIbus, visit the following page on the
IBM Tivoli Information Center:
IBM Tivoli Netcool/OMNIbus Probe for Microsoft System Center Operations Manager 2007 3
com.ibm.netcool_OMNIbus.doc/probes/install/wip/out-html/reference/
install_install_intro.html
3. Configuring the probe.
This guide contains details of the essential configuration required to run this
probe. It combines topics that are common to all probes and topics that are
peculiar to this probe. For details about addition configuration that is common
to all probes, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide
(SC23-9684).
Configuration
After installing the probe, you need to make various configuration settings to suit
your environment.
After installing the Probe for Microsoft System Center Operations Manager 2007
and the various required patches, you must perform the following configuration
tasks:
v “Setting environment variables”
v “Setting-up the HTTPS communication” on page 6
Setting environment variables

For the probe to run properly, you need to set various environment variabes.
Setting the PATH environment variable

You must include the path to the bin/ directory of the JRE in the $PATH
environment variable.
Setting the CLASSPATH environment variable
The probe requires the following files from Jaxws 2.1.1:

v activation.jar
v jaxb-api.jar
v jaxb-impl.jar
v jaxb-xjc.jar
v jsr173_api.jar
v sjsxp.jar
The probe also requires the following files from WSIT 1.0
v webservices-api.jar
v webservices-extra-api.jar
v webservices-extra.jar
v webservices-rt.jar
v webservices-tools.jar
v wstx-services.war
You must include the paths both sets of files explicitly in the CLASSPATH
environment variable.
The following shows an example setting for the CLASSPATH environment
variable:
CLASSPATH=%JAVA_HOME%\lib\endorsed\activation.jar:%JAVA_HOME%\lib\endorsed\
jaxb-api.jar:%JAVA_HOME%\lib\endorsed\jaxb-impl.jar:%JAVA_HOME%\lib\
endorsed\jaxb-xjc.jar:%JAVA_HOME%\lib\endorsed\jsr173_api.jar:%JAVA_HOME%\
lib\endorsed\sjsxp.jar:%JAVA_HOME%/lib\endorsed\webservices-api.jar:
%JAVA_HOME%\lib\endorsed\webservices-extra-api.jar:%JAVA_HOME%\lib\
endorsed\webservices-extra.jar:%JAVA_HOME%\lib\endorsed\webservices-rt.jar:
%JAVA_HOME%\lib\endorsed\webservices-tools.jar:%CLASSPATH%
export CLASSPATH
Note: The explicit paths to the files must be specified, not just the folder in which
they reside.
Setting the SCOM_INCLUDES environment variable
You must include the following jar files in the SCOM_INCLUDES environment
variable:
v activation.jar
v jaxb-api.jar
v jaxb-impl.jar
v jaxb-xjc.jar
v jsr173_api.jar
v sjsxp.jar
v wstx-services.war
The following shows an example setting for the SCOM_INCLUDES environment

variable:
SCOM_INCLUDES=C:\D\activation.jar;C:\D\jaxb-api.jar;C:\D\jaxb-impl.jar;C:\
D\jaxb-xjc.jar;C:\D\jsr173_api.jar;C:\D\sjsxp.jar;C:\D\webservices-
api.jar;C:\D\webservices-extra.jar;C:\D\webservices-api-extra.jar;C:\D\
webservices-rt.jar;C:\D\webservices-tools.jar
Important: You should not set SCOM_INCLUDES explicitly when the following
command installs the probe as a Windows service:
%OMNIHOME%\probes\nco_p_scom2007.bat /INSTALL
Setting SCOM_INCLUDES explicitly would override the CLASSPATH in the batch

script and would prevent the probe from starting. You must only set the
CLASSPATH as shown in the example above.
Setting-up the HTTPS communication
You can use client authentication only when a server requests a certificate from a
client. In client authentication the server requests a certificate from the client to
verify that the claim of the client is reliable. The certificate must be an X.509
certificate and must be signed by a certificate authority (CA) trusted by the server.
You should use these self-signed certificates in the following scenarios:

v Before using certificates from external certificate authorities, validate your setup
using these self-signed certificates.
v If the probe encounters problems connecting to the SCOM server (for example,
403 Forbidden), before contacting IBM support.
OpenSSL is free software, which is available under an Apache-style licence. It is

available for both UNIX and Windows platforms, and can be obtained from
http://www.openssl.org/.
Setting up the HTTPS communication for OpenSSL

The following steps describe how to set up the HTTPS communication using
self-signed certificates generated with OpenSSL:
1. Generate a certificate authority (CA).
2. Generate a server certificate trusted by clients.
3. Generate a client certificate trusted by servers.
4. Import the CA into the SCOM server.
5. Create trusted certificates.
6. Import the server certificate into the SCOM server.
7. Set the SCOM Connector Framework to use SSL.
8. Configure the SCOM SDK Web service.
Note: Setting up of the SSL requires accessing the CA, server, and client
directories that are in the same level, and generating related certificates from those
directories. So, the command line argument examples given for each section to
create a particular certificate also include arguments to access the related directory.
Creating SSL certificates

If you are waiting to receive a certificate from a CA, you can temporarily use a
self-signed certificate until you receive the CA certificate. You can use OpenSSL,
stand-alone Microsoft, or enterprise Microsoft Certification Authority (CA)
certificates to create a CA.
Tip: If you think the self-signed certificate provides adequate security, you can use
it permanently.
The client and server certificates accepted by the CA that you created become valid
and trusted in the self-signed SSL environment. This enables the probe to use the
trusted client certificate, and make a successful SSL handshake with the SCOM
server.
The following topics describe how to create the different types of the CA that the
probe supports:
v “Creating and using an OpenSSL CA” on page 7
v “Creating and using a stand-alone Microsoft CA” on page 10
v “Creating and using an Enterprise Microsoft CA” on page 14
Creating and using an OpenSSL CA

To create and use an OpenSSL CA, you must generate a CA, then generate a server
certificate and a client certificate, and their key pairs.
Note: As a precaution, you must securely backup all certificates and key pairs.
The following topics describe how to create and use OpenSSL CA:
v “Generating a CA using OpenSSL”
v “Generating a server certificate using OpenSSL” on page 8
v “Generating a client certificate using OpenSSL” on page 9
Generating a CA using OpenSSL

A certificate authority (CA) is a central administrative entity, which issues trusted
digital certificates to the clients and servers. A CA uses its CA certificate and key
pairs to sign a digital certificate as trusted.
To generate a certificate authority and select a password for the private key using
OpenSSL, use the following steps:
1. Generate CA certificate and its private key using the following command:
openssl req -out CA.pem -new -x509
Note: By default, when you create certificates using OpenSSL, they have a life
of 30 days. You can create certificates with a longer life by using the -days
argument at the end of the openssl command. For example, to create a
certificate with a life of 365 days, use the following command:
openssl req -out CA.pem -new -x509 -days 365

2. Enter the distinguished name details for the certificate request and select a
password for the private key.
3. Export the private key onto the CA using the following command:
openssl pkcs12 -export -out CA.pfx -inkey privkey.pem -in CA.pem
4. Enter the password of the private key and generate the CA.
5. Insert the CA into %JRE_HOME%\lib\security\cacerts using the commands.
6. Use the following command and change to the directory where the certificates
need to be inserted:
cd %JRE_15_HOME%\lib\security
7. Use the following command to make a backup copy of the certificates:
cp cacerts cacerts.save
Where, the cacerts.save is a backup of the CA certificates. You can use it, if
anything goes wrong.
8. Import the CA certificates into the directory using the following command:
keytool -import -trustcacerts -alias "name_of_the_trusted_certificate"
-file path_to_your_CA.pem -keystore cacerts
Note: For the probe to use a different CA certificate file without changing the
existing java keystore of the JRE, specify the path to this certificate in the
CACertTrustStore property.
Generating a server certificate using OpenSSL
A server certificate authenticates the server to which the probe connects.
To generate a server certificate using OpenSSL, use the following steps:

1. Create the server.cnf file.
2. Generate an RSA private key for the server.
3. Generate a certificate request.
4. Sign the generated RSA private key.
5. Assign the private key onto the generated server certificate.
6. Importing the certificate to the SCOM server.
Creating the server.cnf file
OpenSSL commands expect to receive a file named: server.cnf. This file stores
information that helps generate extension fields to the certificate. You must create
the server.cnf file with the following information:
[dir_sect]
keyUsage=digitalSignature,keyEncipherment
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName=IP:IP of the SCOM server
extendedKeyUsage=serverAuth
Note: The OpenSSL commands also require the file.srl file. This file contains a
serial number starting with "00". Each generation of a certificate by the CA
increments this serial number.
Generating the private key
Generate an RSA private key for the server using the following command:
openssl genrsa -out server.key 1024
Creating a certificate request
Enter all the distinguished name information required to create a certificate request
using the following command:
openssl req -key server.key -new -out server.req
Note: For the Common Name field of the server certificate, enter the Fully Qualified
Host Name of the server to which the probe connects.
Signing the generated private key
Sign the generated RSA private key using the following commands:
openssl x509 -req -in server.req -CA ../CA/CA.pem -CAkey ../CA/privkey.pem

-CAserial file.srl -extfile server.cnf -extensions dir_sect -out server.pem
Assigning the private key of the certificate
Enter the password of the private key, and then export the server key onto the
generated server certificate using the following command:
openssl pkcs12 -export -out server.pfx -inkey server.key -in server.pem
Generating a client certificate using OpenSSL

A client certificate authenticates the probe as a user on the SCOM system, and also
contains information about the organization that issued the certificate.
To generate a client certificate using OpenSSL, use the following steps:

1. Create the client.cnf file.
2. Generate an RSA private key for the client.
3. Generate a certificate request.
4. Sign the generated RSA private key.
5. Export the private key onto the generated client certificate.
Creating the client.cnf file
OpenSSL commands expect to receive a file named: client.cnf. This file stores
information that help generate extension fields to the certificate. You must create
the client.cnf file with the following information:
[dir_sect]
keyUsage=digitalSignature,keyEncipherment
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName=otherName:1.3.6.1.4.1.311.20.2.3;UTF8:xyz@ibm.com,
email:xyz@ibm.com
Where the xyz@ibm.com is the UPN of the user that the probe uses for the telnet
connection. The user must be part of the SCOM Administrator Group and must be
a domain user.
extendedKeyUsage=msEFS,emailProtection,clientAuth
To locate the UPN value, use the following steps:

1. Log in to the Active Directory domain controller.
2. Within Windows, select Control Panel → Administrative Tools → Active
Directory Users and Computers → Users.
3. Locate the user referenced in the client certificate.
4. Select Properties for that user.
5. Navigate to the Account tab.
The UPN Value is the same entry as the Windows Logon Name, for example,
the name@fqdn.com.
Note: The OpenSSL commands also require the file.srl file. This file contains a
serial number starting with "00". Each generation of a certificate by the CA
increments this serial number.
Note: To authenticate the user, the user must be an Active Directory user, and the
SCOM server must be a member of the AD domain.
Generating the private key
Generate the RSA private key for the client using the following command:
openssl genrsa -out client.key 1024
Creating a certificate request
Enter all the distinguished name information required to create a certificate request
using the following command:
openssl req -key client.key -new -out client.req
Note: For the Common Name field of the client certificate, enter the user name that
the probe will use to connect to the server.
Signing the generated private key
Sign the generated RSA private key using the following command:
openssl x509 -req -in client.req -CA ../CA/CA.pem -CAkey ../CA/privkey.pem

-CAserial file.srl -extfile client.cnf -extensions dir_sect -out
client2.pem
Exporting the private key of the certificate
Enter the password of the private key, and then export the client key onto the
generated client certificate using the following command:
openssl pkcs12 -export -out client.pfx -inkey client.key -in client2.pem
Note:
Use the ClientCertificate property to specify the path to this generated client
certificate.
The Export Password field should not be blank. The same value must be specified
in the ClientCertificatePassword property in encrypted format.
Creating and using a stand-alone Microsoft CA

Stand-alone Microsoft CAs issue certificates for authentication to a secure Web
server using Secure Sockets Layer (SSL). They differ from enterprise Microsoft CAs
in that they do not require the use of the Active Directory directory service.
The following topics describe how to create and use stand-alone Microsoft CAs:
v “Installing a Microsoft Stand-alone CA” on page 11
v “Enabling the use of the Subject Alternative Name field for the CA” on page 11
v “Importing the CA certificate into the Enterprise NTAuth store” on page 11
v “Installing the client certificate” on page 12
v “Installing the server certificate” on page 13
v “Configuring OMCF to use the server certificate” on page 19
Installing a Microsoft Stand-alone CA

To install a stand-alone Microsoft CA, use the following steps:
1. Select Add or Remove Programs.
2. Select Add/Remove Windows Components.
3. In the list of components, select Certificate Services.
You will receive a warning stating that the machine name and domain
membership may not be changed after installing certificate services.
4. Click Yes to acknowledge the warning and then click Next.
5. Select Stand-alone root CA.
6. Click Next.
7. Type a name for the CA.
8. Click Next.
9. Keep the default values for Certificate Database Settings.
10. Click Next.
11. When you receive the message about restarting IIS services, click Yes .
12. If prompted, enter the location of the Windows Server 2003 setup files.
Note: Make sure that the Windows Server 2003 setup files are available and that
IIS is installed on the server. To simplify OMCF configuration, you should install
the CA on the RMS. However, you can install the CA on any Windows Server 2003
computer that is running IIS.
Enabling the use of the Subject Alternative Name field for the CA
To enable the use of the Subject Alternative Name field for the CA, run the
following commands on the CA server pressing Enter after each command:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Importing the CA certificate into the Enterprise NTAuth store

Importing the CA certificate into the Enterprise NTAuth store is only required if
Net3.0 Service Pack1 is present. To import the CA certificate into the Enterprise
NTAuth store, use the following steps:
1. Start Internet Explorer on the CA and access the following URL:
http://localhost/certsrv
2. Click Download a CA certificate, certificate chain, or CRL.
3. Click Download CA certificate.
4. Click Save.
5. Copy the CA certificate file to a domain controller.
6. On the domain controller, run the following command:
certutil -dspublish -f filename NTAuthCA
Where filename is the path and filename for the CA certificate file that you
downloaded in Step 3.
7. On the RMS, run the following command:
gpupdate /force
8. Open the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\
Certificates
9. Under the Certificates key, verify that you have a sub-key with a name that
matches the thumbprint of the CA certificate.
Note: To determine the CA certificate's thumbprint, use the following steps:

a. Double-click the CA certficate file.
b. Click the Details tab.
c. Click Thumprint in the list of fields.
The thumbprint is displayed in the box below. This number must match one
of the sub-keys under HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\
NTAuth\Certificates.
Installing the client certificate

To install the client certificate, use the following steps:
1. Log on to the RMS using an account that is a member of the Operations
Manager Administrators User Role.
Note: To check the role of the user, use the following steps:
a. Open the SCOM 2007 Console.
b. Go to Administration.
c. Select User Roles.
d. Double-click Operations Manager Adminstrators.
The user account must be a member of this role, either explicitly or
through membership in a security group that is a role member.
2. Start Internet Explorer and access the following URL:
http://localhost/certsrv
Note: If you installed the CA on server remote from RMS, replace localhost
in the URL with the name of the CA.
3. Select Request a certificate.
4. Select Advanced certificate request.
5. Select Create and submit a request to this CA.
6. In the Name field, type the user name.
7. Under Type of Certificate Needed, make sure that Client Authentication
Certificate is selected.
8. Under Key Options, select Mark keys as exportable. This allows the client
certificate to be exported with the private key later.
9. Under Additional Options, type the following in the Attributes box:
san:upn=username@DomainFQDN.local
Where username@DomainFQDN.local is the User Principal Name (UPN) for the
user in Active Directory.
Note: To determine the correct UPN, open the properties for the user in
Active Directory Users and Computers and click the Account tab. The UPN is
listed under User logon name.
10. Click Submit.
11. Click Yes if prompted with a security warning in Internet Explorer.
12. Leave the Internet Explorer window open; you will use it in a later step.
13. Select Administrative Tools → Certification Authority .
14. Click Pending Requests.
15. Right-click the pending request, point to All Tasks and click Issue.
16. Leave the Certification Authority snap-in open.
17. In Internet Explorer, return to the Certificate Services Home page.
18. Click View the status of a pending certificate request.
19. Select the certificate request.
20. Click Install this certificate.
21. If you are prompted with a security warning in Internet Explorer, click Yes.
22. In the Certification Authority snap-in, click Issued Certificates.
23. Double-click the client certificate.
24. Click the Details tab.
25. Click Copy to File.
26. Click Next in the Certificate Export Wizard.
27. Select a location and filename for the client certificate file and click Next.
28. Click Finish.
Installing the server certificate

To install the server certificate, use the following steps:
1. Start Internet Explorer on the RMS and access the following URL:
http://localhost/certsrv. If you installed the CA on another server besides the
RMS, replace "localhost" in the URL with the name of the CA.
5. In the Name field, type the fully qualified domain name (FQDN) of the RMS.
6. Under Type of Certificate Needed, select Server Authentication Certificate.
7. Select the option store the certificate in the local computer certificate store.
8. Under Additional Options, type the following in the Attributes box:
san:dns=FDQN
Where FDQN is the FQDN of the RMS.
9. Click Submit.
10. If prompted with a security warning in Internet Explorer, click Yes.
11. Leave the IE window open; you will use it in a later step.
12. Select Administrative Tools → Certification Authority.
13. Select Pending Requests.
14. Right-click the pending request, point to All Tasks and click Issue.
15. In Internet Explorer, return to the Certificate Services Home page.
16. Select View the status of a pending certificate request.
17. Select the certificate request.
18. Select Install this certificate.
19. If you are prompted with a security warning in Internet Explorer, click Yes.
Creating and using an Enterprise Microsoft CA

Enterprise Microsoft CAs issue certificates for authentication to a secure Web
server using Secure Sockets Layer (SSL). To do so, they require the use of the
Active Directory directory service.
The following topics describe how to create and use Enterprise Microsoft CAs:
v “Generating a user template”
v “Generating a client certificate using a template” on page 15
v “Generating a server template” on page 15
v “Generating a server certificate using a template” on page 16
Generating a user template

A user template is a copy of the client certificate in use. You generate a user
template for the CA to use while it issues new client certificates for members of the
Domain Users group in Active Directory Users and Computers. To generate a user
template, perform the following steps on the issuing CA (SCOM):
2. Select Certificate Templates.
3. Right-click and select Manage.
4. Select the User template from the list of templates.
5. Right-click and select Duplicate Template.
6. Specify a name for the new template, (for example, Probe User).
7. Select the following options under the tabs indicated:
v General:
– Publish certificate in Active Directory.
v Request Handling (allow export):
– Purpose is Signature and encryption.
– Include symmetric algorithms allowed by the subject.
– Minimum Key size is 1024.
– Allow private key to be exported.
– Enroll subject without requiring any user input.
v Subject Name :
– Build from this Active Directory information.
– Subject name format : Fully Distinguished Name.
– Include e-mail name in subject name .
– E-mail name.
– User principal name (UPN).
v Issuance Requirements : nothing
v Superseded Templates : nothing
v Extensions : the following extensions are included
– Application Policies
– Certificate Template Information
– Issuance Policies
– Key Usage
v Security (add enroll):
– Add the probe user to the list of Group and User names
– The assigned user (scomuser) must have read, write, and enroll
permissions.
8. Click Apply and then OK.
9. Create the template option in the Issuing CA server by performing the
following steps:
a. Select the Certificate Templates in the Certificate Authority Window .
b. Select New.
c. Select Certificate Template.
d. Select the newly created template.
e. Click OK.
10. Force the propagation of the template by performing the following steps:
a. At the root of the window Certification Authority, select the Issuing CA.
b. Right-click and select All Tasks → Stop Service.
c. Restart the Issuing CA service by right-clicking on the Issuing CA and
selecting All Tasks → Start Service.
d. Run the following on the command line:
gupdate /force
Generating a client certificate using a template

To generate a client certificate based on the new template, perform the following
steps:
1. Log on to the probe server (or other computer within the CA’s domain) as the
user to issue the certificate
2. Start Internet Explorer and access the Issuing CA’s URL; for example:
http://scom1.scomad.bobdns/certsrv
6. In the Advanced Certificate Request window, select the newly created
certificate template, (for example, Probe User).
7. Keep the default values, and select Submit.
8. In the following page, click Install this certificate.
The certificate will then appear in the Certificate snap-in under Local User.
Generating a server template

A server template is a copy of the server certificate in use. You generate a server
template for the CA to use while it issues new server certificates. To generate a
server template, perform the following steps on the issuing CA (SCOM):
2. Select Certificate Templates.
3. Right-click and select Manage.
4. Select the Web Server template from the list of templates.
5. Right-click and select Duplicate Template.
6. Specify a name for the new template, for example SDK Web Server.
7. Select the following options under the tabs indicated:
v General:
– Keep all the default values.
v Request Handling (allow export):
– Purpose is Signature and encryption.
– Minimum Key size is 1024.
– Allow private key to be exported.
v Subject Name :
– Supply in the request.
v Issuance Requirements: nothing
v Superseded Templates: nothing
v Extensions: the following extensions are included
– Application Policies (Server Authentication)
– Certificate Template Information
– Issuance Policies
– Key Usage
v Security (add enroll):
– Add the probe user to the list of Group and User names
– The SDK Service user (scomuser) should have read, write, and enroll
permissions.
– The hostname of the SDK service server (SCOMA) must have
read/enroll permissions.
8. Click Apply, then Ok
9. Create the template option in the Issuing CA server using the following steps:
a. Select Certificate Templates in the Certificate Authority Window.
b. Select New → Certificate Template .
c. Select the newly created template (for example, SDK Service Web Server).
d. Select Ok.
10. Force the propagation of the template using the following steps:
a. At the root of the Certification Authority window, select the Issuing CA.
b. Right-click and select All Tasks → Stop Service.
c. Restart the Issuing CA service, by right-clicking on the Issuing and
selecting All Tasks → Start Service.
d. Run the following command as a domain administrator:
un : gupdate /force
This pushes the CA certificate from the SCOM host to the domain
controller in the PKI environment, so that all hosts and domain controllers
have an updated trusted CA issuers list. This allows each host within the
domain in the enterprise environment (for example, the probe host and
SCOM host), to allow the CA certificate to issue and trust any certificates it
has created. When the probe needs to authenticate using that client
certificate, the CA will trust the certificate.
Generating a server certificate using a template

To generate a server certificate based on the new template, perform the following
steps:
1. Log on to the probe server (or other computer within the CA’s domain) as the
user to issue the certificate.
2. Start Internet Explorer and access the Issuing CA’s URL; for example:
http://scom1.scomad.bobdns/certsrv
6. In the Advanced Certificate Request window, select the newly created
certificate template, (for example, SDK Web Server).
7. Select the following options :
v Specify the Identifying information for offline template (for example,
FQDN) and user mail address.
v Under Key Options, click Store certificate in local computer.
v Under Additional options, specify the FQDN (DNS) attribute in the
Attributes field.
8. Click Submit.
The certificate is then installed in the Certificate snapin under Local Computer.
Managing CA certificates
You can make the generated PKI certificates as trusted, and import them into their
host machines for the probe and the SCOM server to use. You also need to set up
the SCOM SDK connector framework to use the SSL and the SCOM SDK Web
service.
The management of the certificates themselves is the same regardless of how you
created them. There may be small differences in the screens used depending on
which patch level of Microsoft .Net3.0 Service Pack1 you have installed on the
SCOM RMS host.
The following topics describe how to manage CA certificates:

v “Installing trusted certificates on Windows”
v “Importing CAs into the trusted CAs of the JRE” on page 21
v “Configuring OMCF to use the server certificate” on page 19
v “Exporting a client certificate for the probe” on page 22
Installing trusted certificates on Windows

The CA, server, and client certificates must be imported to create trusted
certificates that the probe can use when making an SSL connection to the SCOM
server.
To import the PKI objects and create trusted certificates, perform the following
steps using the Microsoft certificate console on the SCOM server:
1. Add user and computer accounts.
2. Import the CA as a trusted authority.
3. Import the client certificate.
4. Import the server certificate.
Adding user and computer accounts
To create user and computer accounts using the Microsoft certificate console,
perform the following steps:
1. Open the certificates console window by entering mmc in the Run dialog.
2. Select File → Add/Remove Snap-in....
3. In the Add/Remove Snap-in window, select Add.
4. In the Add Standalone Snap-in window, select Certificates.
5. In the Certificates snap-in window, select My user account, and then click
Finish.
6. In the Add/Remove Snap-in window, select Add.
7. In the Add Standalone Snap-in window, select Certificates .
8. In the Certificates snap-in window, select Computer account, and then click
Next.
9. Select the local computer running the Microsoft certificate console that you
are using.
10. Click Finish.
11. Click OK on the Add/Remove Snap-in window.
The Microsoft certificate console window now lists the available certificates.
Importing the CA as a trusted authority
To import the generated CA as a trusted authority, perform the following steps:

1. In the Console Root window, select Certificates (Local Computer).
A list of PKI objects appears at the right pane.
2. Right-click Trusted Root Certification Authorities, and select All Tasks →
Import....
3. Select the ca.pfx file in the File to import section.
4. Click Next.
5. Enter the password of the CA certificate and click Next.
6. Select Place all certificates in the following store.
7. Click Browse ->Trusted Root Certification Authorities store -> Ok.
8. Click Next.
9. Click Finish.
The certificate now appears in the main window.
Import the client certificate
To import the client certificate, perform the following steps:

1. From the Console Root window, select Certificates (Current User).
2. Right-click Trusted Root Certification Authorities, and select All Tasks →
Import....
3. Select the client.pfx file in the File to import section.
4. Click Next.
5. Enter the password of the client certificate, and click Next.
8. Click Next.
9. Click Finish.
The certificate now appears in the main window under Certificates - Current User
/ Personal / Certificates.
Import the server certificate
To import the server certificate, perform the following steps:

1. From the Console Root window, select Certificates (Local Computer).
2. Select the server.pfx file in the File to import section.
3. Click Next.
4. Enter the password of the server certificate, and click Next.
7. Click Finish.
The certificate now appears in the main window under Certificates (Local
Computer) - Current User / Personal / Certificates.
Configuring OMCF to use the server certificate

Operations Manager Connector Framework (OMCF) is a custom service Operation
Manager, which creates a connector to track alerts sent to Netcool/OMNIbus.
Netcool/OMNIbus updates the Operation Manager about status of the received
alert.
Note: Due to a limitation in the SCOM design, updates to the RepeatCount and
the LastModifiedTime fields are notified to the OMCF.
To use the server certificate, configure Operations Manager Connector Framework

(OMCF) using the following steps:
1. On the RMS, rename the following file in the SCOM 2007 installation folder:
Microsoft.Mom.Sdk.ServiceHost.exe.config
2. In the same folder, create a new text file containing the sample config file.
3. In the config file, change both instances of the string RMSFQDN to the FQDN
of the RMS.
4. Save the file and rename it as follows:
Microsoft.Mom.Sdk.ServiceHost.exe.config
5. Copy the thumbprint of the server certificate to a text editor.
Note: To obtain the server certificate's thumbprint, use the following steps:
a. Select Administrative Tools → Certification Authority.
b. Click Issued Certificates.
c. Double-click the server certificate.
d. Click the Details tab.
e. Click Thumprint in the list of fields.
The thumbprint is displayed in the box below.
f. Highlight the thumbprint and press Ctrl+C.
g. Paste the thumbprint into the text editor.
6. In the text editor, remove all spaces from the certificate thumbprint.
7. At a command prompt, run the following command:
httpcfg query ssl
Note: httpcfg.exe is included in the Windows Server 2003 Support Tools.

8. In the query results, make sure that you do not have an entry with the
following IP:
0.0.0.0:51905
9. If you do not have an entry with the above IP, go to Step 10.
If you do have an entry with the above IP, copy its hash value to the
clipboard and delete the entry using the following command:
httpcfg delete ssl -i 0.0.0.0:51905 -h thumbprint -n LOCAL_MACHINE -c
MY -f 2
Where thumbprint is the hash value that you copied to the clipboard. If there
are any blanks in hash value, replace them with 0.
10. Run the following command:
httpcfg set ssl -i 0.0.0.0:51905 -h thumbprint -n LOCAL_MACHINE -c MY
-f 2 Where thumbprint is the server certificate thumbprint from the text file
that you created in Steps 5 and 6.
httpcfg query ssl
12. In the query results, make sure that you have a new entry with the following
IP:
0.0.0.0:51905
Note: The hash value for this entry must match the thumbprint of the server
certificate. Some instances of 0 may appear as blanks.
13. Ensure that the SDK service account is a member of the Operations Manager
Administrators User Role.
14. Restart the OpsMgr SDK service.
15. In Internet Explorer, access the following URL:
https://RMSFQDN:51905/ConnectorFramework?wsdl
Where RMSFQDN is the FQDN of the RMS.
16. If you are prompted to choose a digital certificate, select the client certificate
and click OK.
17. Click the Lock icon in Internet Explorer and click View certificates.
The server certificate should be displayed.
Configuring SCOM SDK Web service

The SCOM SDK configuration file controls the connection of non-Windows clients
with the SCOM SDK Web service through HTTPS. Make the following changes to
the Microsoft.Mom.Sdk.ServiceHost.exe.config file to achieve this:
1. Remove the following section within the <services> </services> section:
<endpoint address="mex" binding="mexHttpBinding" name="WsdlPublishing"
contract="IMetadataExchange"/>
2. Change the value of baseAddressMcfV3 to:
<add key="baseAddressMcfV3" value="https://FQDN:port/
ConnectorFramework"/>
where FQDN (fully qualified domain name) and port are the values on your
target SCOM RMS. The dafault https port is 51905.
3. Add the following section within the <readerQuotas> </binding> section:
<security mode="Transport"> <transport
clientCredentialType="Certificate"/> </security>
4. Update the service metadata element as below:
<serviceMetadata httpGetEnabled="true" httpGetUrl="http://FQDN:port
+1/ConnectorFramework" httpsGetEnabled="true"/>
where FQDN (fully qualified domain name) and port are the values on your
target SCOM RMS. The dafault https port is 51906.
5. Add the serviceCredentials section after <serviceThrottling
maxConcurrentSessions="1000"/> tag:
<serviceCredentials>
<clientCertificate>
<authentication mapClientCertificateToWindowsAccount="true"/>
</clientCertificate>
</serviceCredentials>
Importing CAs into the trusted CAs of the JRE

Whether the probe is remote or local to the SCOM SDK, and whether the probe is
running on Windows or UNIX, you must import the CA certificate into the trusted
CAs of the JRE at the probe host.
The SSL certificate used by the SCOM Connector Framework must be a certificate
trusted by the Java VM that runs the probe. If the certificate is not already in the
list of those trusted, you can add a Trusted Authority using the following method:
To import the CA certificate on the probe host, use the following steps:
1. Copy the CA.cer certificate file from the SCOM server to the probe server.
Note: This is the file copied to the active directory domain controller and
added to the NTAuth store.
2. Import the CA.cer file into the keystore using the following comand:
keytool -import -trustcacerts -keystore java_keystore_path -alias SCOM
-file SSL_certificate_file_path
Where java_keystore_path is the CA certificate file of the JRE 1.5, and
SSL_certificate_file_path is the path to the SSL certificate used by SCOM.
Note: The file to import into cacerts is CA.pem and the default password of this
files is changeit.
3. Enter keystore password.
4. At the prompt Trust this certificate? [no]: enter yes.
The certificate has been added to keystore.
Note: For the probe to use a different CA certificate file without changing the
existing CA certificate file of the JRE, specify the path to this certificate in the
CACertTrustStore property.
Exporting a client certificate for the probe
For the probe to be used either locally, or on a remote host, the client certificate
must be exported into a .PFX file.
To export the certificate, use the following steps:

1. Locate the certificate you want to export using the Microsoft Management
Console (MMC).
For details about how to do this, see “Adding user and computer accounts” on
page 18
2. Right-click on it and select All tasks → Export.
3. In the pop-up window, select Yes, export the private key.
4. Under Export File Format, select Personal Information Exchange – PKCS #12
(.PFX).
5. Select Include all certificates in the certification path if possible.
6. Select Enable strong protection.
7. Under Password, type in an export password.
This password will be the one used by the ClientCertificatePassword property
of the probe after it is encrypted using nco_g_crypt.
8. Specify a file name for the export file.
Note: You must specify this file name in the ClientCertificate property of the
probe.
Configuring and running the probe

When you have set and generated the CA certificates for the server and the client,
you are ready to configure and run the Probe for Microsoft System Center
Operations Manager 2007.
This chapter contains the following topics:

v “Data acquisition” on page 24
v “Properties and command line options” on page 27
v “Elements” on page 31
v “Running the probe” on page 29
v “Error messages” on page 33
v “ProbeWatch messages” on page 36
v “Desktop and webtop tools” on page 37
Configuring the probe properties and probe hosts file

The following is a summary of the steps required to configure the probe:
1. Copy the client certificate (.pfx file) to the probe server.
2. Edit the hosts file (the default location is $OMNIHOME/probes/arch/
scom2007.hosts).
3. Add the fully qualified domain name and port number of the SCOM server in
the format FQDN:port
Note: The details that you specify must match the name and port configured in
the SCOM server file Microsoft.Mom.Sdk.ServiceHost.exe.config
4. Edit the probe properties file (the default location is $OMNIHOME/probes/
arch/scom2007.props). As a minimum, set the following properties:
a. CACertTrustStore
Note: Make sure that the CA certificate is correctly imported into the
$JAVA_HOME\lib\security\cacerts file in the probe host for the Java to trust
the client certificate
b. ClientCertificate
c. ClientCertificatePassword
Note: The client certificate must have a valid password. It cannot function
with a null value.
d. Server
e. HostsFile. Modify hosts file (scom2007.hosts) to include FQDN:port for the
SCOM2007 SDK.
Note: For a full description of the properties, see “Properties and command
line options” on page 27.
Configuring the probe for scom_tool.pl

The probe is supplied with a Perl script (scom_tool.pl) that allows you modify
events in SCOM. To run this script you must have Perl 5.6 or later installed.
For details about the configuration that you need to do within Netcool/OMNIbus
and how to run the script, see the README.scom_tool file supplied with the probe.
Internationalization support
The probe supports multibyte character sets (for example, Japanese) and character
sets that contain individual multibyte characters (for example German, French, and
Spanish). To view the character sets correctly, you must configure the locale
settings on the host machine correctly.
If you are using a language that contains multibyte characters, you must set the
LANG environment variables to the name of your character set, and export the
LC_ALL environment variable. For example, if you are using Japanese, set these
environment variables to ja_JP.UTF-8; if you are using German, set these
environment variables to de_DE.UTF-8. This will enable the probe to recognise the
multibyte characters used by your character set when they occur in any network
events.
The probe supports the following language locales:

Table 3. Supported language locales
Languages AIX HP-UX Solaris Linux
English (US) en_US en_US en_US en_US
Simplified zh_CN zh_CN zh_CN zh_CN
Chinese
Traditional zh_TW zh_TW.eucTW Zh_TW.big5 zh_TW.big5
Chinese
Czech cs_CZ cs_CZ cs cs_CZ
Table 3. Supported language locales (continued)
Languages AIX HP-UX Solaris Linux
French fr_FR fr_FR fr fr_FR
(standard)
German de_DE de_DE de de_DE
(standard)
Hungarian hu_HU hu_HU hu hu_HU
Italian (standard) it_IT it_IT it it_IT
Japanese ja_JP ja_JP ja ja_JP
Korean ko_KR ko_KR ko ko_KR
Polish pl_PL pl_PL pl pl_PL
Portuguese pt_BR pt_BR pt pt_BR
(Brazilian)
Russian ru_RU ru_RU ru ru_RU
Spanish es_ES es_ES es es_ES
Data acquisition
Each probe uses a different method to acquire data. Which method the probe uses
depends on the target system from which it receives data.
The Probe for Microsoft System Center Operations Manager 2007 acquires data by
creating and subscribing a connector to receive events from the HTTPS Web service
running on the SCOM server.
Data acquisition is described in the following topics:

v “Encrypting the SCOM password”
v “Secure sockets layer (SSL) authentication” on page 25
v “Acknowledging alerts” on page 25
v “Receiving resolved events” on page 25
v “Command line interface” on page 25
v “Hosts file format” on page 26
v “Modes of operation” on page 26
Encrypting the SCOM password
The client certificate export password must be specified in the

ClientCertificatePassword property in encrypted format.
To encrypt the password, run the following command:
$OMNIHOME/bin/nco_g_crypt password
Where password is the password of the client certificate.
You must then set the ClientCertificatePassword property to the encrypted string
that the command generates.
Secure sockets layer (SSL) authentication
You use SSL authentication service to provide Secure Sockets Layer (SSL)
authentication with the SCOM server. The probe connects to the SSL authentication
service using the port specified in the hostsfile.
Acknowledging alerts
The SCOM server keeps sending alerts until the connector acknowledges their
receipt. For each event received, the connector immediately acknowledges the alert
with the time when the alert was last modified.
Receiving resolved events

If an event is resolved in SCOM, the Probe for Microsoft System Center Operations
Manager 2007 receives a resolved event. This event indicates that the event is
cleared. When the probe sends this event to the ObjectServer, the corresponding
event in the ObjectServer is also cleared.
Command line interface
The Probe for Microsoft System Center Operations Manager 2007 is supplied with
a Command Line Interface (CLI). This interface allows you to perform commands
using the probe (for example, to acknowledge an alarm, or resolve alerts on the
SCOM server).
Command port functionality
When the probe starts, it opens a command port that the IBM Tivoli Netcool tools
use to send requests to the probe to perform the following actions:
v Acknowledge an alert - you can change the state of an alert on the SCOM server
to Acknowledged by opening a telnet session with the probe and issuing the
command:
acknowledge_alarm alarmID
Where alarmID is the identifier of the alert within SCOM.
v Resolve an alert - you can change the state of an alert in SCOM to Resolved by
opening a telnet session with the probe and issuing the following command:
resolve_alarm alarmID
Where alarmID is the identifier of the alert within SCOM.
v Update the TicketId field - you can change the value set for the TicketId field of
an alert on the SCOM server by opening a telnet session with the probe and
issuing the following command:
set_ticket_id alertID newTicketId
Where alertID is the identifier of the alert within SCOM to be updated, and
newTicketId is the new value for the TicketId field of the alert.
v Update any field - you can change the value set for several fields in one or more
alerts in SCOM by opening a telnet session with the probe and issuing the
following command:set_field alertID(fieldName=value) alertId(fieldName=
value)alertId(fieldName=value)...
Where alertID is the identifier of an alert within SCOM and the value is the
new value for the specified fieldName field.
You can only change values of the following fields:
v customFieldn
Where n is a value between 1 and 10.
v Owner
v ResolutionState
v TicketId
Note: Use the recommended command syntax which includes parentheses and the
equals signs (=).
Hosts file format
The Probe for Microsoft System Center Operations Manager 2007 needs a hosts file
in order to connect to multiple hosts. The HostsFile property specifies from which
file the probe gets host information. The probe reads through the hosts file and
attempts to connect to each host at a given time.
If the HostsFile property is defined, the probe attempts to open the specified file.
This file should contain the required connection information for the probe in the
following format:
FQDN:port
Modes of operation
You can run the probe in one of the following modes:

v Normal: When the probe starts-up, the connector sends all the events that have
been queued up while the probe was down.
v Cleanstart: The probe ignores the older events and starts reading events sent
after the probe started. To run the probe in cleanstart mode, set the Cleanstart
property to 1.
Connecting to and disconnecting from the SCOM server

Using the HTTPS Web service, the probe connects to and registers with an SCOM
2007 server listed in the host file specified by the HostsFile property. After the
connection, the probe registers a connector in the SCOM server with a name
specified by the ConnectorName property.
Use the Operations Manager console to specify the SCOM connectorevent

subscriptions. If no subscriptions are currently available, you can add a
subscription and then configure the Groups, Targets and Criteria of the associated
alerts that the probe should receive. To get events from SCOM to Netcool, you
must make a subscription for Netcool within SCOM. This registers a connector. For
details of how to make a subscription within SCOM, refer to the online help in the
SCOM Administration console.
Note: If there are multiple connectors, only one connector with an existing
subscription receives events from SCOM at any given time.
By default, the probe uses the poll period defined by the PollInterval property to
retrieve only those events that are subscribed in the SCOM server. It parses these
alerts and sends them to the ObjectServer.
If the CleanUpOnShutdown property is set to true, the probe deletes its connector
if it has no subscriptions when the probe disconnects from the SCOM server. The
SCOM server can no longer use the connector created for the probe.
Tip: You can remove a connector that has lost its registration ID manually. For
more information, refer to “Troubleshooting” on page 38.
If the CleanUpOnShutdown property is set to false, the probe does not delete its
connector when it disconnects from the SCOM server.
The probe uses this connector with its next connection to the SCOM server, and
receives all events generated since it was shut down.
Properties and command line options

You use properties to specify how the probe interacts with the device. You can
override the default values by using the properties file or the command line
options.
The following table describes the properties and command line options specific to
this probe. For information about default properties and command line options, see
the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide, (SC23-6373).
Table 4. Properties and command line options
Property name Command line option Description
CACertTrustStore string -cacerttruststore string Use this property to specify a
different CA keystore without
changing the existing CA keystore
of the JRE.
The default is " ".

CleanStart string -cleanstart (This is Use this property to specify
equivalent to CleanStart whether or not the probe should
with a value of true.) ignore the recovery file and start
reading events created after the
-nocleanstart (This is probe started.
equivalent to CleanStart
with a value of false.) false: The probe disables clean
start.
true: The probe enables clean start.
The default is false.

CleanUpOnShutdown -cleanuponshutdown (This Use this property to specify
string is equivalent to whether or not the probe
CleanUpOnShutdown uninitializes the registration ID on
with a value of true.) shutdown and removes its
connector from the SCOM server.
-nocleanuponshutdown
(This is equivalent to false: The probe does not remove
CleanUpOnShutdown its connector on shutdown.
with a value of false.)
true: The probe removes its
connector on shutdown.
Table 4. Properties and command line options (continued)
ClientCertificatePassword -clientcertificatepassword Use this property to specify the
string string password to access certificates in
the ClientCertificate file.
The default is " ".
Note: The password must be

encrypted using the nco_g_crypt
tool.
ClientCertificate string -clientcertificate string Use this property to specify the
path to the file that contains a
client certificate for SSL
communication.
The default is " ".
Note: The file should be in

Personal Information Exchange -
PKCS 12 (.PFX) format
CommandPort integer -commandport integer Use this property to specify the
port to which users can telnet to
send commands to the SCOM
server using the Command Line
Interface (CLI) supplied with the
probe.
The default is 6970.

CommandPortLimit -commandportlimit integer Use this property to specify the
integer maximum number of telnet
connections that can be made to
the probe.
The default is 10.

ConnectorName string -connectorname string Use this property to specify the
name used to register the probe as
a connector in SCOM.
The default is Netcool probe.

HostsFile string -hostsfile string Use this property to specify the
file that the probe uses to connect
to multiple hosts.
The default is scom2007.hosts.

LanguageCode string -languagecode string Use this property to specify the
default three-letter language code
of the language in which the
element name is shown.
The default is ENU.
Table 4. Properties and command line options (continued)
PeerCommandPort string -peercommandport string Use this property to specify the
port of the peer probe to which
users can telnet to send
commands to the SCOM server
using the Command Line Interface
(CLI).
The default is 6970.

PollInterval integer -pollinterval integer Use this property to specify the
frequency (in seconds) with which
the probe waits between
successive polls of the SCOM
server for alerts.
The default is 10.

RegistrationIdRecovery -registrationidrecoveryfile Use this property to specify the
File string string path of the recovery file that the
probe uses to retrieve the
identifier required to release its
connector from the SCOM server.
The default is
%OMNIHOME%\\var\\
scom2007.reco
Retry string -noretry (This is Use this property to specify
equivalent to Retry with a whether the probe retries the
value of false.) connection to the SCOM server if
there is an error while attempting
-retry (This is equivalent a connection:
to Retry with a value of
true.) false: The probe does not retry the
connection.
true: The probe retries the

connection if there was an error.

Timeout integer -timeout integer Use this property to specify the
time (in seconds) the probe waits
to connect to the SCOM server
before shutting down.
The default is 10.
Running the probe

All probes are run in a similar way. The Probe for Microsoft System Center
Operations Manager 2007 can be run from the command line or as a service.
Running the probe from a command line
Set the SCOM_INCLUDES environment variable to include the following jar files
from JAXWS 2.1.1 and WSIT 1.0 patches:
Include the following jar files from JAXWS 2.2.1:

v activation.jar
v jaxb-api.jar
v jaxb-impl.jar
v jaxb-xjc.jar
v jsr173_api.jar
v sjsxp.jar
Include the following jar files from WSIT 1.0:

Run the following command:
%OMNIHOME%\probes\win32\nco_p_scom2007
Running the probe as a service
If you want to run the probe as a service, run the following command:
%OMNIHOME%\probes\win32\nco_p_scom2007 /INSTALL
This command installs the probe as a service, which you can then run as any other
Windows service.
Note: When installing the probe as a service, set the CLASSPATH environment
variable before running the /INSTALL command.
Tip:
If you want to run the Probe for Microsoft System Center Operations Manager
2007 as a Windows service, set all property values in the properties file and not by
using the command line.
Due to a known issue with nco_p_nonnative, the log file does not contain all the
information required. To remedy this, set the following environment variables:
v Set NDE_DEFAULT_LOG_LEVEL to the value set for the MessageLevel
property.
v Set NDE_FORCE_LOG_MODULE to the value set for the MessageLog property.
To remove the service corresponding to the probe, run the following command:
%OMNIHOME%\probes\win32\nco_p_scom2007 /remove
Note: The Windows service must be run in the same network domain as the
probe.
For details about the command line options available for ClientCertificate and
ClientCertificatePassword properties, see “Properties and command line options”
on page 27.
Elements
The probe breaks event data down into tokens and parses them into elements.
Elements are used to assign values to ObjectServer fields; the field values contain
the event details in a form that the ObjectServer understands.
The following table describes the elements that the Probe for Microsoft System
Center Operations Manager 2007 generates. Not all the elements described are
generated for each event; the elements that the probe generates depends upon the
event type.
Table 5. Elements
Element name Element description
$alertParams This element indicates whether the method
parameters is declared for the alarm.
$category This element shows the category of the alarm.
$connectorId This element contains the connector ID that the
probe registered with the SCOM server.
$connectorStatus This element identifies the status of the
Connector ID created in the SCOM server.
$context_tagName This element shows the context of the alarm with
a field name. The field name denotes the content
of $context field.
$customFieldn This element contains data from a user-defined
field.
$description This element shows the description of the alarm.
$displayString This element contains the string for display.
$id This element identifies the unique identifier of
the event.
$isMonitorAlert This element indicates whether the event can be
monitored.
$languageCode This element indicates the language of the code
in which the events are presented.
$lastModified This element shows the time of the latest update
on the event.
$lastModifiedBy This element contains the User ID of the last
person to modify the event.
$lastModifiedByNonConnector This element shows the time when the latest
update on the alert is done through the CLI.
$lastTimeStateModified This element shows the time at which the state of
the alert was last modified.
$maintenanceModeLastModified This element shows the time when the
maintenance mode was last modified.
$managementGroupId This element shows the identifier of the
management group.
$managementGroupName This element contains the name of the
management group.
$managementPackCategoryType This element indicates the category type of the
management pack.
$modifiedBy This element shows name of the user who
modified the alert.
Table 5. Elements (continued)
$monitoringClassId This element contains the identifier of the
monitoring class.
$monitoringObjectDisplayName This element shows the name displayed for the
monitoring object.
$monitoringObjectFullName This element contains the full name of the
monitoring object.
$monitoringObjectHealthState This element shows status of the monitoring
object.
$monitoringObjectId This element contains the ID of the monitoring
object.
$monitoringObjectInMaintenanceMode This element identifies whether the monitoring
object is in maintenance mode.
$monitoringObjectName This element shows the name of the monitoring
object.
$monitoringObjectPath This element contains the path to the monitoring
object.
$monitoringRuleId This element contains the identifier of the rule set
for the monitoring object.
$name This element shows the name of the element.
$netbiosComputerName This element contains the NetBios computer
name of the Windows Server 2003 Service Pack1
computer.
$netbiosDomainName This element contains the domain name of the
NetBios computer.
$owner This element shows the User ID of the owner of
the event. The user ID is usually a user account.
$ownerName This element shows the name of the owner of the
alert.
$principalName This element contains the principle name.
$priority This element indicates the priority as defined by
the SCOM server.
$problemId This element contains the identifier of the
problem.
$repeatCount This element shows number of times this alert
has occurred.
$resolutionState This element identifies the resolution state of the
alert.
$resolvedBy This element shows the name of the user account
responsible for resolving the alert; appears when
the alert is resolved.
$severity This element indicates the severity of the alert.
$siteName This element shows the name of the site where
SCOM is installed as given in the header of the
alarm buffer display.
$stateLastModified This element contains the name of the user
account last modified the alert.
Table 5. Elements (continued)
$ticketID This element shows the identifier of the ticket in
which the alert is described.
$timeAdded This element contains the time at which the alert
was added to the SCOM system.
$timeCreated This element contains the time at which the
SCOM system has created the alarm.
$timeCreatedUTC This element contains the time (in UTC format) at
which the SCOM system has created the alarm.
$timeLastModified This element contains the time at which the
details of the alert were last modified.
$timeRaised This element contains the time when the alert
was raised.
$timeResolutionStateLastModified This element contains the time when the
resolution state of the alert last modified.
Error messages
Error messages provide information about problems that occur while running the
probe. You can use the information that they contain to resolve such problems.
The following table describes the error messages specific to this probe. For
information about generic error messages, see the IBM Tivoli Netcool/OMNIbus
Probe and Gateway Guide, (SC23-6373).
Table 6. Error messages
Error Description Action
Failed to acknowledge Either the alarm received Check that the SCOM server
alert: ackId from the SCOM server is running correctly.
contained corrupt data or the
Failed to acknowledge wrong identifier was sent for
discovery event:ackId acknowledgement.
Failed to parse alert:

ackId
Failed to set alert

alertId to resolution
state setResolution State
Failed to clean up probe Problem removing resolution Check that the SCOM server
resolution state state from SCOM. is running correctly, and
restart the probe.
Failed to acknowledge The probe failed to send or Check that you have set up
alert receive the specified the IBM Tivoli Netcool tools
information to the SCOM correctly. Check the
Failed to get company server. connection to the SCOM
knowledge server.
Failed to get vendor

knowledge
Failed to resolve alert
Table 6. Error messages (continued)
Failed to read There was a problem reading Check that the permissions
registration ID from the recovery file. have been set correctly on the
recovery file file specified by the
RegistrationIdRecoveryFile
Failed to write property.
registration ID
registrationId to
recovery file
Command_Port Failed to There was a problem Check that you have specified
close client socket communicating with the a valid command port using
SCOM server using the the CommandPort property.
Command_Port Failed to command port of the probe. Check the connection to the
get CommandPortLimit SCOM server.
property - using 10
Command_Port Failed to
open listening socket
Command_Port host_name
Failed to close command
socket
Failed to get socket IO
Failed to read command
Failed to set socket
timeout
Failed to write to client
Failed to accept new

client connection
Failed to connect to SCOM There was a problem Check the client SSL
interface connecting to the SCOM certificate used by the probe,
service. This is possibly due if the message appears with a
Failed to get global to a problem with 403 Forbidden exception.
config authentication.
Failed to print global

config
Failed to clean up There was a problem creating Check whether the resolution
resolution state the new resolution state. state already exists on the
SCOM server.
Failed to get alerts
Failed to initialize new

resolution state
Failed to set up with

resolution state
Failed to setup with new

resolution state
Failed to uninitialize
connector
Please remove the

resolution state from the
SCOM server and try again
Failed to set ticket ID An exception was raised Check whether a correct
while executing the alertId, or ticketId is specified
set_ticket_id command on the in the command.
command port.
Argument : detail doesn't The command sent is not in Verify that the command
have the expected format, the expected format. format is in the format of:
and will be ignored. set_field alertId
fieldname=value
Expected format is :
alertId(field=value)
Problem while creating The probe could not connect Check the value set for Host
ConnectorInfo object to the SCOM 2007 Web and Port properties in the
Service. properties file. Check the SSL
Failed to create certificate of the SCOM
ConnectorFrameworkDat server.
aAccess object
Failed to get connector

service
The hosts list is empty,

there are no Scom2007
server details available
Failed to print global This shows that the probe has Check the SSL certificate of
config problems reaching the SCOM the SCOM server, if the
2007 Web Service. message appears with a 403
Failed to get global Forbidden exception.
config
Failed to get alerts The probe found an exception Check that the SCOM server
while retrieving alerts, is running correctly.
Failed to parse alerts parsing them, or while trying
to acknowledge them.
Failed to uninitialize The probe could not Check that the connector is
connector uninitialize the connector. properly created, or the
SCOM server is running
correctly.
Failed to clean up The probe could not clean up Check that the connector is
connector the existing connector ID at properly created, or the
the beginning or end of the SCOM server is running
connection to the server. correctly.
Exception while calling The probe found an exception Check whether the alert IDs
update MonitoringAlerts while updating the alerts. specified in the update
command exist in the SCOM
All the requested alerts server.
haven't been found
This alertId has not been

found in Scom
Cannot find the The probe could not find the Check the value specified for
appropriate set method value specified to set the the set_field command. Also
for this attribute. The field. check the format of the
attribute is probably specified value.
unknown
Couldn't find method :

method_name of object
AlertGenerated
The type of the attribute

attribute is unknown
unknown method_arg Cannot

update the attribute
Couldn't set the

attribute field of the
alert to value
There are no updates to The probe found that the Check whether an unknown
submit to Scom 2007 updates submitted to SCOM attribute, a wrong value
server have failed. format, or unknown alert IDs
specified in the command.
ProbeWatch messages
During normal operations, the probe generates ProbeWatch messages and sends
them to the ObjectServer. These messages tell the ObjectServer how the probe is
running.
The following table describes the raw ProbeWatch error messages that the probe
generates. For information about generic ProbeWatch messages, see the IBM Tivoli
Netcool/OMNIbus Probe and Gateway Guide, (SC23-6373).
Table 7. ProbeWatch messages
ProbeWatch message Description Triggers/causes
Failed to open listening The probe failed to open a The port specified by the
socket socket on that command port. CommandPort property is
already in use. Specify a
different port in the properties
file.
Table 7. ProbeWatch messages (continued)
ProbeWatch message Description Triggers/causes
Received connection from The command port has A user logged onto the
hostname received a connection to its command port specified by
CLI. the CommandPort property
to send a request to the
SCOM server.
Failed to connect to SCOM The probe failed to connect to An authentication problem
interface the SCOM interface. occurred. Check your SSL
settings.
Connected to SCOM The probe has connected The probe was started and
interface successfully. successfully connected to the
SCOM server.
Desktop and webtop tools

The Probe for Microsoft System Center Operations Manager 2007 is shipped with
the following set of Webtop and Desktop tools that can do the following:
v Acknowledge Alert - this tool telnets to the command port and executes the
acknowledge_alarm @AlertKey command (AlertKey will be set to the value of the
$alertId token of the event, which is the identifier required to acknowledge
alerts in SCOM). This action sets the resolution state of the corresponding alert
in SCOM to 85 (Acknowledged). The tool also sets the event in IBM Tivoli
Netcool to Acknowledged.
v Resolve Alert - this tool telnets to the command port and executes the
resolve_alarm @AlertKey command (AlertKey will be set to the value of the
$alertId of the event, which is the identifier required to resolve alerts in
SCOM). This action sets the corresponding alert in SCOM to resolution state to
55 (Resolved). The tool also sets the severity of the event in IBM Tivoli Netcool
to 0 (clear).
Tip: These tools provide additional functionality, such as acknowledging and

resolving the alerts, and are not required for the normal operation of the probe.
The installation of these tools is described in the following sections.
Installing tools on Windows

This section describes how to install Webtop and Desktop tools on Windows
platforms.
Note: Due to a change in the directory structure between IBM Tivoli

Netcool/OMNIbus versions 7.0 and 7.1, the commands required to install the tools
have also changed. The following sections describe the steps required to install the
tools on IBM Tivoli Netcool/OMNIbus versions 7.0 and 7.1.
Installing desktop tools on IBM Tivoli Netcool/OMNIbus v7.0
To install the Desktop tools into the database, run the following command:
%OMNIHOME%\bin\redist\isql.exe -U username -P password -S server_name -i

WindowsSCOMTools.sql
The tools for Windows use a script that requires the DLL
netcool_tivoli_socket.dll, which is included with the probe. This script must be
registered by the operating system before you can run the tools. To do this, run the
following command:
%SYSTEMROOT%\system32\regsvr32 C:\Progra~1\Netcool\OMNIbus\probes\nt351\
netcool_tivoli_socket.dll
Installing desktop tools on IBM Tivoli Netcool/OMNIbus v7.1
To install the Desktop tools into the database, run the following command:
C:\Program Files\Micromuse\netcool\bin\redist\isql.exe -U username -P

password -S server_name -i WindowsSCOMTools.sql
The tools for Windows use a script that requires the DLL netcool_tivoli_socket.dll,
which is included with the probe. This script must be registered by the operating
system before you can run the tools. To do this, run the following command:
%SYSTEMROOT%\system32\regsvr32 C:\Progra~1\Micromuse\netcool\omnibus\
probes\win32\netcool_tivoli_socket.dll
Installing webtop tools on IBM Tivoli Netcool/OMNIbus v7.0
To install the Webtop tools into the database, use the following steps:
1. Replace instances of win32 with nt351 in the file WindowsSCOMTools.sql to
reflect differences in the IBM Tivoli Netcool/OMNIbus V7.0 directory structure.
cd %OMNIHOME%\probes\nt351 "%WEBTOP_HOME%\waapi\bin\runwaapi" -file

WindowsSCOMTools.xml
Installing webtop tools on IBM Tivoli Netcool/OMNIbus v7.1
To install the Webtop tools into the database, run the following command:
cd %OMNIHOME%\probes\win32 "%WEBTOP_HOME%\waapi\bin\runwaapi" -file

WindowsSCOMTools.xml
Troubleshooting
This section contains troubleshooting information and details about known issues.
Retrieving a connector with a lost registration ID
To retrieve a connector whose registration ID is lost, use the following steps:

1. Create a file with the name getConnector.txt. The file must contain the
following commands:
use OperationsManager
Select * from Connector
2. Enter the following command to run the commands in the getConnector.txt
file:
C:\>Sqlcmd -i C:\getConnector.txt
This lists all the available connectors.
3. Locate the lost connector ID within the list displayed.
Removing a connector with a lost registration ID
To find and remove a connector whose registration ID is lost, use the following
steps:
1. Create a file with the name removeConnector.txt. The file must contain the
following commands:
use OperationsManager
execute [dbo].[p_ConnectorDelete] ’3C4111C1-E3E5-4415-B3CF-
7A61056F5EF2’
2. Replace the connector ID 3C4111C1-E3E5-4415-B3CF-7A61056F5EF2 in the
removeConnector.txt file with the lost connector ID.
3. Use the following command to remove the specified connector ID:
C:\>Sqlcmd -i C:\removeConnector.txt
Note:
You can also remove a connector using the Microsoft System Center Operations
Manager GUI.
Removing the specified connector ID is successful only when the related

connector is not initialized or subscribed.
HTTP 403 Forbidden error
An HTTP 403 Forbidden error is usually due to a problem with the user certificate.
It could be that the user cannot be mapped to a domain user on the Windows box,
see “Installing the client certificate” on page 12.
User errors usually happen when the probe tries to call getGlobalConfig() just
after retrieving successfully the ConnectorFramework object. If this is the case, put
the SDK in debug mode and run the probe again.
Probe Java debug logging

If the probe stops, you can debug the problem by setting the MessageLevel to
debug in the properties, and enabling Java debugging by using the following steps:
1. Backup the nco_jprobe file using the following command:
cp %OMNIHOME%\probes\nco_jprobe into %OMNIHOME%\probes\nco_jprobe.orig
2. Edit %OMNIHOME%\probes\nco_jprobe
3. Replace the last line:
----------------------------
# Execute probe
exec $OMNIHOME/probes/$ARCH/nco_p_nonnative java $NCO_JPROBE_JAVA_FLAGS
-cp $CLASSPATH
$NCO_JPROBE_JAVA_XFLAGS -DOMNIHOME="$OMNIHOME" $PROGRAM "$@
----------------------------
with the following :
----------------------------
# Execute probe
exec $OMNIHOME/probes/$ARCH/nco_p_nonnative java
-Djavax.net.debug=ssl:handshake:verbose $NCO_JPROBE_JAVA_FLAGS -cp
$CLASSPATH $NCO_JPROBE_JAVA_XFLAGS -DOMNIHOME="$OMNIHOME" $PROGRAM "$@"
----------------------------
4. Set the following environment variables to enable nonnative debug output as
well as Java debug output:
NCO_P_NONNATIVE_TRANSCRIPT=\tmp\debug.txt
NDE_DEFAULT_LOG_LEVEL=debug
NDE_FORCE_LOG_MODULE=\tmp\MOM_FORCED.log
5. Run the probe and generate the required debug log files.
Testing the connection using the test application

You can test the client certificate to authenticate the probe to the SCOM server
using the OMCF test application.
To obtain the testing tool (MCF.exe), you must contact Microsoft Support.
To test a client certificate, use the following steps:

1. Obtain a copy of the OMCF Test Application.
2. Extract the files from OMCF-app.zip to a folder on the RMS/SCOM host.
3. Copy the client certificate to the same folder in which you extracted the OMCF
Test Application files.
Note: The client certificate is the .cer file that you exported using the SCOM
administration console
mcf RMSFQDN client.cer
Where RMSFQDN is the FQDN of the RMS and client.cer is the name of the client
certificate file.
If the connection is successful, you will receive the following message:
Successfully Connected to MCF. Here is the Global Configuration:

Name=Management_Group_Name, Guid=Management_Group_GUID
This indicates that the client certificate is valid and will work with the probe when
installed as such.
If the message does not display Global Configuration, then this indicates that the
client certificate is not valid and will not work with the probe.
If the MCF test tool cannot connect, this indicates that there is a client certificate
issue in the relevant type being used, that must be fixed first before the probe can
attempt a succesful connection using the same type of client certificate when
presented.
Support of Certificates and their usage with the SCOM PROBE

For issues relating to the management or creation of certificates (including the
management of OpenSSL certificates on the SCOM server and any relevant domain
controller), contact Microsoft Support for clarification.
For issues relating to the creation commands of the OpenSSL certificates, contact
IBM Software Support.
Net3.0 Service Pack1

Some installations on the SCOM server, have a service pack present for .NET
Framework 3.0. This can change the way you manage CA certificates on the SCOM
server.
There was a design change in the Windows Communication Foundation (WCF)

that was included in Net Framework 3.0 Service Pack1. This change requires
certificate chaining using NTAuth when a certificate impersonates a user.
If the service pack for Net3.0 is present on the SCOM host, you must perform the
following steps to get the CA certificate to trust the client certificate, other wise all
client certificates will fail:
1. Determine whether the service pack for Net3.0 has been installed on the SCOM
host by using the following steps:
a. Select Windows → Start Menu → Control Panel → Add remove programs →
Windows Components .
b. b. Select Show updates ticked.
c. c. Verify whether the patch is present on the SCOM host.
If the service pack is present, you must add the CA certificate to the trusted
issuers list on the Underlying Domain Controller in active directory.
2. Enable use of the Subject Alternative Name field for the Standalone/Enterprise
Microsoft CA by running the following commands on the CA server, pressing
Enter after each command:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
3. Import the CA certificate into the Enterprise NTAuth store using the following
steps:
a. Open Internet Explorer on the CA and access the following URL:
http://localhost/certsrv (or relevant OpenSSL certificate previously
created).
b. Select Download a CA certificate, certificate chain, or CRL.
c. Select Download CA certificate.
d. Click Save.
e. Copy the CA certificate file to a domain controller.
f. On the domain controller, run the following command:
certutil -dspublish -f filename NTAuthCA
Where filename is the path and filename for the CA certificate file that you
downloaded in Steps b to d.
g. On the RMS, run the following command:
gpupdate /force.
This command pushes the CA certificate from the local registry onto the
relevant domain controller, making the CA certificate become an Enterprise
CA certificate.
Note: Contact Microsoft support, if execution of the command requires

Domain Administrator rights.
h. Open the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\
Microsoft\EnterpriseCertificates\NTAuth\Certificates
i. Under the Certificates key, verify that you have a sub-key with a name that
matches the thumbprint of the CA certificate.
j. Use the following steps to determine the CA certificate’s thumbprint:
1) Double-click the CA certficate file.
2) Click the Details tab.
3) Click Thumprint in the list of fields.
The thumbprint is displayed in the box below. This number must match one
of the sub-keys under HKLM\SOFTWARE\Microsoft\
EnterpriseCertificates\NTAuth\Certificates. You must do this for all CA
certificates.
Alerts not being sent to the connector through OMCF

When an alert is automatically updated within SCOM using a SCOM rule, the
RepeatCount and the LastModifiedTime of the alert gets updated in SCOM.
However, this updated alert is not sent to the connector through the Operations
Manager Connector Framework (OMCF). This is due to a design limitation of
SCOM, as confirmed by Microsoft.
In this case, the Probe for Microsoft System Center Operations Manager 2007
cannot receive these updated alerts as they are not available at the connector. This
results in a mismatch in the LastModifiedTime and the Count of the same alert
between the OpsMgr and the ObjectServer.
Additional references
This section contains a list of links to useful information about SSL and CA
certificates.
How SSL works:
http://technet2.microsoft.com/windowsserver/en/library/c22a4d3d-6335-4b9b-
b344-bbae041203b41033.mspx?mfr=true
Importing third-party CA certificates into the Enterprise NTAuth Store:
http://support.microsoft.com/kb/295663
Certificates used for authentication require CRL - 281245 (see section 5):
Subject Alternative Name field needs to contain the UPN of the user from Active
Directory.
To enable SAN field on Microsoft CA server:
How to add a Subject Alternative Name to a secure LDAP certificate:
How to import third-party certification authority (CA) certificates into the
Enterprise NTAuth store:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/
com.ibm.netcool_OMNIbus.doc/probes/msopman07/msopman07-pdf.pdf
MCF from non-Windows Clients:
http://blogs.msdn.com/jakuboleksy/archive/2007/04/02/mcf-from-non-windows-
clients.aspx
Creating PKCS#12 certificates with Microsoft's Certification Authority console:
http://technet.microsoft.com/en-us/library/cc135718.aspx
OpenSSL commands:
http://www.openssl.org/docs/apps/openssl.html
http://shib.kuleuven.be/docs/ssl_commands.shtml
http://www.slproweb.com/products/Win32OpenSSL.html
Background information about certificates:
http://technet2.microsoft.com/windowsserver/en/library/3f5fdc52-8623-4336-
840d-e90b2399c8541033.mspx?mfr=true
http://technet2.microsoft.com/WindowsServer/en/Library/0e4472ff-fe9b-4fa7-
b5b1-9bb6c5a7f76e1033.mspx?mfr=true
Appendix. Notices and Trademarks
This appendix contains the following sections:
v Notices
v Trademarks
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation

Licensing 2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
© Copyright IBM Corp. 2006, 2010 45

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
Software Interoperability Coordinator, Department 49XA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs.
Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights
reserved.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks
IBM, the IBM logo, ibm.com®, AIX®, Tivoli, and Netcool® are trademarks of
International Business Machines Corporation in the United States, other countries,
or both.
Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-based
trademarks are either registered trademarks or trademarks of Adobe Systems
Incorporated in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation
in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or

both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Other company, product, or service names may be trademarks or service marks of

others.
Appendix. Notices and Trademarks 47


Printed in USA
SC23-8843-02

Omnibus Connector Msscom

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Omnibus Connector Msscom

Uploaded by

Copyright:

Available Formats

Tivoli Netcool/OMNIbus Probe for Microsoft System Center

© Copyright IBM Corp. 2006, 2010 iii

Configuration section updated.

Obtaining the components section added.

Setting environment variables section added.

Creating SSL CAs chapter added.

Maintaining CA certificates chapter added.

Running the probe on Windows section updated.

Properties and command line options section updated.

Details about how the probe acquires data clarified.

Elements section updated.

Error messages section updated.

Troubleshooting and known issues chapter added.

© Copyright IBM Corp. 2006, 2010 v

The commands required to enable the use of the Subject

Steps corrected in “Configuring SCOM SDK Web service”

“Connecting to and disconnecting from the SCOM

Topic describing peer-to-peer functionality removed.

Default values for several properties updated in

This guide contains the following sections:

© Copyright IBM Corp. 2006, 2010 1

For details of the operating system versions on which

Microsoft System Center Operations Manager with Web

Java 1.5 (this is supplied with Netcool/OMNIbus).

Note: You must include the path to the bin/ directory

Unrestricted JCE Policy files for SDK 1.4 (for AIX)

Perl 5.6 or later

This is required to run the scom_tool.pl file supplied

Note: The scom_tool.pl file provides the telnet details

Obtaining the required patches and libraries

To obtain JAXWS-RI 2.1.1, visit the following Web address:

To obtain WSIT 1.0, visit the following Web address:

java -jar filename

Where filename is the name of one of the jar files.

The installation process consists of the following steps:

Setting environment variables

Setting the PATH environment variable

Setting the CLASSPATH environment variable

The probe requires the following files from Jaxws 2.1.1:

Setting the SCOM_INCLUDES environment variable

The following shows an example setting for the SCOM_INCLUDES environment

Setting SCOM_INCLUDES explicitly would override the CLASSPATH in the batch

You should use these self-signed certificates in the following scenarios:

OpenSSL is free software, which is available under an Apache-style licence. It is

Setting up the HTTPS communication for OpenSSL

Creating SSL certificates

Creating and using an OpenSSL CA

Generating a CA using OpenSSL

openssl req -out CA.pem -new -x509 -days 365

To generate a server certificate using OpenSSL, use the following steps:

Creating the server.cnf file

subjectAltName=IP:IP of the SCOM server

Generating the private key

openssl genrsa -out server.key 1024

Creating a certificate request

openssl req -key server.key -new -out server.req

Signing the generated private key

openssl x509 -req -in server.req -CA ../CA/CA.pem -CAkey ../CA/privkey.pem

openssl pkcs12 -export -out server.pfx -inkey server.key -in server.pem

Generating a client certificate using OpenSSL

To generate a client certificate using OpenSSL, use the following steps:

Creating the client.cnf file

To locate the UPN value, use the following steps: