CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

Discovery Improvements
Eureka Release

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Fri, 14 Mar 2014 19:03:35 PST

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

CIM Discovery
CIM Discovery
Overview
CIM probes can explore any device based on the Common Information Model (CIM) by querying a CIM server, also referred to as a CIMOM - Common Information Model Object Manager. By default, Discovery uses CIM probes to explore storage systems as well as to get the serial numbers of ESX servers. This feature is available starting with the Berlin release.

Architecture
The following components are part of CIM: Common Information Model (CIM): CIM [1] allows multiple parties to exchange information about managed elements. CIM represents these managed elements and the management information, while providing the mechanism to actively control and manage the elements. Storage Management Initiative Specification (SMI-S): SMI-S [2] is a standard of use that describes methods for storage discovery on the vendor's side. ServiceNow uses SMI-S to determine how to discover CIM. SMI-S is based on the Common Information Model (CIM) and the Web-Based Enterprise Management (WBEM) standards, which define management functionality via HTTP. The main objective of SMI-S is to enable management of dissimilar storage products. ServiceNow supports SMI-S version 1.5 or higher.

Web-Based Enterprise Management (WBEM): WBEM [3] defines a particular implementation of CIM, including protocols for discovering and accessing each CIM implementation. Service Location Protocol (SLP): SLP [4] is an ad hoc protocol for retrieving and associating configuration information about CIM servers, such as default paths, capabilities, and the exact interop namespace [5]. ServiceNow Discovery retrieves the interop namespace of a CIM server via SLP and passes that information to the CIM Classify probe. SLP, referred to here as the SLP server, uses service agents (SA) to gather and disseminate information about a CIM server on a subnet. A subnet can have multiple service agents.

CIM Discovery

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

How CIM Discovery Works

1. Shazzam launches the wbem port probe. 2. The wbem port probe detects activity on target ports SLP 427, CIM 5989 and 5988, and then examines the Service Registry Queries related list, at Discovery Definition > Port Probes, for the SLP query. The base system provides this query is provided to detect the service:wbem service type, which indicates the presence of an SLP server. 3. Shazzam launches a scanner for this service type. The scanner retrieves the attributes of the service from the SLP server, including the interop namespaces [5] of CIM servers in the network, and appends the values it finds to the port probe results. 4. The wbem port probe appends the SLP data it carries to the CIM Classify probe. 5. The CIM Classify probe uses that information to explore the CIM servers.

CIM Discovery

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

wbem Port Probe

The wbem probe stores the data it retrieves in the CIM Classification [discovery_classy_cim] table. The wbem port probe is defined in Discovery Definition > Port Probes.

SLP Query
The SLP query detects the wbem service (service:wbem) on an SLP server and gathers the attributes of the service. The SLP query is defined in the Service Registry Queries related list in the wbem port probe record (Discovery Definition > Probes).

CIM Discovery

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

CIM Classify Probe

The wbem port probe appends the SLP data it carries to the CIM Classify probe before launching it. The CIM Classify probe extracts VMware ESX serial numbers and connector relationships between the SAN and NAS components from CIM Servers in the network.

To access the CIM Classify probe, navigate to Discovery Definition > Probes.

References
[1] [2] [3] [4] [5] http:/ / en. wikipedia. org/ wiki/ Common_Information_Model_(computing) http:/ / www. snia. org/ tech_activities/ standards/ curr_standards/ smi http:/ / en. wikipedia. org/ wiki/ Web-Based_Enterprise_Management http:/ / en. wikipedia. org/ wiki/ Service_Location_Protocol http:/ / sfdoccentral. symantec. com/ ccstor/ 5. 1. 1/ win_unix/ html/ cc_hscg/ apas01. htm

CIM Probe

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

CIM Probe
Overview
The CIM probe uses WBEM protocols to query a particular CIM server, the CIM Object Manager, for a set of data objects and properties.

Parameters
The following parameters may be passed to the CIM probe:
Parameter Description Default Value

source port

The initial host to connect to. The port to connect to. If empty, the value is determined by the "schema" parameter: http = 5988, https = 5989. The schema to use: '"http"' or '"https"'. The CIM namespace. May be overridden by query. A semicolon-delimited list of CIM probe queries to process and return results for. The number of times to retry a query if it fails due to network connectivity issues.

required none

schema namespace queries retries

required required required 2 5000 5000

connection_timeout The number of milliseconds to wait on each attempt to connect to a server. socket_timeout The number of milliseconds to wait to read data.

Parameter is internal use only. Not supported.

Query Language
The CIM probe query language (CimIQL) uses keys, filters, and dot-walking to traverse the CIM schema.

Parameter Expansion
The CIM query language supports standard SNC preprocessed probe parameter expansion. Place variables in queries by encapsulating their names like this: ${foobar}.CIM_RunningOS[0].Name CIM_ComputerSystem.${barfoo} The text ${foobar} is replaced with the contents of the foobar probe parameter passed to the CIM probe; likewise for barfoo.

CIM Probe

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

Enhancements
Eureka
Provides improved support of CIM probes with the CimIQL queries.

CimIQL
CimIQL
CimIQL (short for CIM Intermediate Query Language, pronounced "simickle") is an intermediate language designed to simplify the process of querying CIM providers. It currently supports the standard WBEM protocol stack, but others, such as WS-MAN, may be added in the future. The query language syntax borrows from elements of Microsoft's WMI query language and Unix's 'wbemcli' command. The CimIQL library is a pure-Java implementation.

Syntax
The end-user provides CimIQL with a valid statement, which contains multiple queries, delimited by the period . character. A query represents a single high-level protocol-independent request. Each query is comprised of nested language components and sub-components known as tokens. A token describes a specific lexical aspect of the CimIQL syntax. The first token of each query must be an operation token, which represents the overall logical operation to be performed. Each query is paired with a result, which is then provided as input to the next query in the statement. A result is comprised of a set of objects and their properties.

Operation Tokens
Each of the following core operations has a counter-part in the CIM Operations over HTTP [1] standard: Get Object (GetInstance) Enumerate Objects (EnumerateInstances) Enumerate Associated Objects (Associators) Method Call (extrensic MethodCall)

The following are "psuedo-operation" tokens that act as no-op placeholders: Substitution (references the results of a named statement)

CimIQL Get Object Token <classname>{<key token>,<parameter token>,...}

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

Retrieves a single object of a specific class by specifying all of its unique keys (as key tokens) and any optional parameter tokens, separated by commas. The classname is the case-sensitive CIM class name of the desired object. By default, objects of the specified class and of any extended classes are retrieved. The key and parameter tokens are enclosed by a single pair of curly brackets { ... }. This token must only be used as the first query in a statement. Enumerate Objects Token <classname>{{<condition token>,<parameter token>,...}}<array index token> OR <classname><array index token> Retrieves objects that match a set of condition tokens and parameter tokens. The condition tokens and parameter tokens are enclosed by two pairs of curly brackets {{ ... }}. The curly brackets are optional if there are no conditions or parameters necessary, as shown in the second format. The classname is the case-sensitive CIM class name of the desired objects. By default, objects of the specified class and of any extended classes will be retrieved. The index token is optional. This token must only be used as the first query in a statement. Enumerate Associated Objects Token
<association classname>{{<property filter token>,<parameter token>,...}}<array index token>

OR <association classname><array index token> Retrieves objects associated with each result from the preceding query. The condition tokens and parameter tokens are enclosed by two pairs of curly brackets {{ ... }}. The curly brackets are optional if there are no properties filters or parameters necessary, as shown in the second format. The association classname is the name of the many-to-many or one-to-many class that associates two objects together. By default, objects of the specified class and of any extended classes will be retrieved. The parameter token, ResultClass, may be specified to filter results based on the resulting objects' classname. The index token is optional. This token must not be used as the first query in a statement.

CimIQL Method Call Token <method name>(<parameter token>,...) Calls a method on each object of the preceding query's result set.

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

The method name is the name of a valid method of each preceding result object. Substitution Token ${<statement name>} A no-op token that feeds the results of a previous named statement as input into the next query of its own statement. Internal Method Call Token _<internal method name>(<parameter token>,...) Calls an internal method on each object of the preceding query's result set. Internal methods are defined by CimIQL and do not necessarily involve communication with the server. The internal method name is prefixed with an underscore character.

Component Tokens
The following tokens are sub-components of operation tokens. Properties Token *

OR <property name>,<property name>,... Specifies which properties are to be returned for each object of the final result set. The wildcard * returns all properties available. Otherwise, each property name desired is provided within a comma-separated list. This token is required at the end of each statement. Query Delimiter Token .

Separates queries. Index Token [index]

Reduces a preceding query's results to a single object at the specified integer index. This token is always optional.

CimIQL Key Token <key name>='<value>' Matches an object property designated as a key by exact value. The key name is the name of the property used as a key. Condition Token

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

<property name><conditional operator><enclosed value> Matches a single property of an object, conditionally. The property name is the name of the property to match against. The conditional operator determines how the property's actual value is compared to its expected value. The operators available are equality (=) and inequality (!=). The enclosed value should be one of the following: Literal value enclosed in single-quotes ' ... '. E.g., foo='bar' Regular expression, enclosed by a pair of slashes / ... /. E.g., foo=/bar.*/ Parameter Token <parameter name>:'<value>' Passes a parameter by parameter name to the operation being called. The parameter may be consumed during CimIQL pre-processing or by the CIMOM via request, depending on the parameter.

Examples
A tutorial by example. Each example builds on the last ... CIM_ComputerSystem[0].*

Retrieves the first result of all instances of CIM_ComputerSystem and its descendants. Retrieves all properties. CIM_ComputerSystem.PrimaryOwnerContact

Retrieves all instances of CIM_ComputerSystem and its descendants. Retrieves only one property, PrimaryOwnerContact. CIM_ComputerSystem{CreationClassName='Linux_ComputerSystem',Name='runtime'}.*

Retrieves a single unique instance of CIM_ComputerSystem and its descendants. All keys must be specified within the { } identity token. Key format is provided as PropertyName='VALUE", comma-separated between multiple keys. CIM_ComputerSystem{{Name!='runtime'}}.*

Retrieves one or more instances of CIM_ComputerSystem and its descendants - all that do not have Name property of 'runtime'. The filter token filters out instances that do not contain all of the properties/keys specified. Filter tokens work similar to the identity token { }, with a few differences: The not-equals operator != can be used (as well as the equals = operator).

CimIQL

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

10

Both keys and properties can be specified. Slower and more resource-intensive than using the { } identity tokens. Regex can be used. See below. CIM_ComputerSystem{{Name=/^run.*$/}}.*

Retrieves one or more instances of CIM_ComputerSystem and its descendants - all that have a value matching the regex contained within the / / characters. Note that the single quotations are not used for regex. CIM_ComputerSystem{{Name='runtime'}}[2].*

Retrieves the second result of all instances of CIM_ComputerSystem and its descendants filtered. Matches all instances that have a property Name of 'runtime'. Note the order of operations follows the query syntax ... 1. Query server for all CIM_ComputerSystem and descendants. 2. Filter results based on Name property. 3. Retrieve the second instance that passed the filter. CIM_ComputerSystem.CIM_RunningOS[0].Name

Retrieves the Name property for first CIM_OperatingSystem of each CIM_ComputerSystem. The middle-token, CIM_RunningOS, is the name of the Associator class, not the end-result. CIM_ComputerSystem.CIM_RunningOS{{Name=/CentOS/}}[0].Name

The same as above, except that each CIM_OperatingSystem found is then filtered by its Name property (containing 'CentOS').

Results
Results can be transformed to XML, with extendibility to other formats in the future.

XML
A commented example:
<!-- document root --> <cimqueryset> <!-- A single query and query result. Multiple <cimquery> tags may be provided. --> <cimquery> <!-- The original query, enclosed by CDATA. --> <query><!CDATA[[>CIM_ComputerSystem[0].PrimaryOwnerContact<! ]]></query> <!-- The resulting data is enclosed within a single <result> tag. --> <result> <!-- A single class instance result. Multiple <instance> tags may be provided. Special tags are prefixed with an underscore character. --> <instance> <!-- The instance's CIM classname --> <_classname>Linux_ComputerSystem</_classname> <!-- A set of this instances identifying keys. Always provided, regardless of property filters.

CimIQL

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized
Within here, each key is provided as <KeyName>VALUE</KeyName> with the VALUE

11

enclosed as CDATA. --> <_key> <CreationClassName><![CDATA[Linux_ComputerSystem]]></CreationClassName> <Name><![CDATA[runtime]]></Name> </_key> <!-- Each property that matches the query's property filter will be provided here, in the same format as keys; As <PropertyName>VALUE<PropertyName> where VALUE is enclosed as CDATA --> <PrimaryOwnerContact><![CDATA[root@runtime]]></PrimaryOwnerContact> </instance> </result> </cimquery> </cimqueryset>

References
[1] http:/ / www. dmtf. org/ sites/ default/ files/ standards/ documents/ DSP0200_1. 3. 1. pdf

Data Collected by Discovery on Storage Devices

Overview
Discovery uses CIM probes to explore storage systems based on the Common Information Model (CIM) and determine the relationships between Storage Area Network (SAN) and Network-Attached Storage (NAS) components. The CIM probe uses WBEM protocols to query a particular CIM server, the CIM Object Manager, for a set of data objects and properties. See CIM Discovery.

Tables and Fields

Discovery uses the following tables and fields for storage devices.
Label Sys ID File Share ID Path Disk space (GB) Pool ID Speed (GFC) WWPN Device ID Table Name Storage Disk [cmdb_ci_stoarge_disk] Field Name sys_id Source N/A CIM probe CIM probe CIM probe CIM probe CIM probe CIM probe CIM probe

Storage File Share [cmdb_ci_storage_fileshare] fileshare_id Storage File Share [cmdb_ci_storage_fileshare] path Storage Pool [cmdb_ci_storage_pool] Storage Pool [cmdb_ci_storage_pool] Storage Port [cmdb_ci_storage_port] Storage Port [cmdb_ci_storage_port] Storage HBA [cmdb_ci_storage_hba] disk_space pool_id speed wwpn device_id

Firmware version Storage Server [cmdb_ci_storage_server] Disk Space (GB) LUN Storage Volume [cmdb_ci_storage_volume] Storage Volume [cmdb_ci_storage_volume]

firmware_version CIM probe disk_space lun CIM probe CIM probe

Data Collected by Discovery on Storage Devices World Wide Port Name Host Bus Adapter

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

12

Relationships
Discovery can establish the correct relationships between an IP device and the storage device to which it attaches regardless of which device Discovery explores first. Discovery maps the local World Wide Name (WWN) [1] port on the IP device to the fiber channel port on the storage device to establish the relationship between the volume on the IP device and the correct pool on the storage device. This diagram illustrates the process flow.

References
[1] http:/ / www. tech-faq. com/ world-wide-name-wwn. html

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

13

Probe Results Cache

Probe Results Cache
Overview
Discovery probes and sensors perform data collection and processing tasks. The probe collects the information and the sensor processes it. Both get their instructions from the ECC queue. There is a worker job on the MID Server that monitors the queue for work. The monitor checks for any entries where the Queue is output and the State is ready.

The MID Server then processes all the outputs, runs the necessary probes, and returns the probes results to the ECC queue. These results are put in the ECC Queue as input entries.

After an entry is inserted in the ECC Queue table, a Business Rule fires (on insert) that takes that information and runs it through a sensor processor. The sensor processor's job is to take the input data, find any sensors interested in that data, and pass it along to be processed. Those sensors ultimately update the CMDB. For tips and instructions for creating your own custom probes and sensors, visit the ServiceNow community [1].

Probes
Probes are launched by the MID Server to collect all the information that you want returned from a device. For example, the base ServiceNow system has probes to get the names of Windows and Linux devices, and separate exploration probes that return disk information for devices with those operating systems. View each probe's results in the ECC queue, which displays specifics such as the time the probe ran and its payload. For each probe, you must also create a sensor to process the data that the probe returns. To view existing probes, navigate to Discovery > Discovery Definition > Probes. The Probe form provides the following unique fields.

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

14

Field Probe type

Description Select the probe for the operating system of the device it will query. CIM Probe: Select this probe type to query a CIM server using WBEM protocols. Multiprobe: Multiprobes can run one or more simple probes of any type or mix probes of different types. This type of probe can make several queries simultaneously that return all the results at the same time. You cannot add multiprobes to other multiprobes. Probe: Select this generic probe type to define a probe class. Specify the name of the probe class in the ECC queue topic field. SNMP Probe: Select this probe type for network devices, such as routers. WMIRunner Probe: Use this probe type for Windows devices.

ECC queue topic

Enter a descriptive term for the function of the probe. The probe uses this label as the Topic field for incoming ECC queue messages. The term does not have to be unique. For example, all the UNIX probes might have an ECC queue topic value of SSHCommand. By default, ServiceNow probes use the following ECC queue topics: CimProbe Multiprobe Powershell SCPRelay SSHCommand SNMP WMIRunner

ECC queue name Cache Results

Enter either a descriptive name for human use, or the actual command the probe is to run. For example, if the value in the ECC queue topic field is SSHCommand, then enter the actual shell command to run in this field. Cache this probe's results in the probe results cache (starting with the Eureka release).

Setting Probe Parameters

Use probe parameters to control the behavior of a particular probe every time it is triggered. 1. Create or select the probe you want to set parameters for. 2. From the Probe Parameters related list, click New. 3. Create a probe parameter record (see table). The Probe parameter form has the following fields.
Field Name Value Description Enter the parameter name. See the probe reference page for a list of available parameters. Enter the parameter value or script.

Value script [Optional] Enter the script you want the parameter to run if you have not already specified a script in the Value field. Probe Displays the probe this parameter relates to.

Global Parameters
The following parameters are available for all probe types.

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

15

Parameter

Description

payload_max_length Specifies the maximum string length of probe results that the MID Server will send to the instance for probes where the Used by Discovery field is true. The MID Server verifies the size of the results before sending them to the instance. If the results exceed the limit, the MID server discards the results and returns a warning message. This parameter is available starting with the Eureka release. source Type: integer (characters) Default value: 5000000

[Required] The initial host to connect to. Type: string (URL) Default value: None

Probe Results Cache

The probe results cache improves overall discovery performance by caching probe results on the instance and only processing results that have changed. The results of probes that have not changed do not need sensor processing and therefore do not run. The cache can be enabled or disabled for individual probes. The probe results cache is available starting with the Eureka release.

Enabling and Disabling the Cache for Specific Probes

If you have created probes, you can turn on the cache individually by enabling the Cache Results field for that probe. The probe results cache should be enabled only for those probes and sensors whose output is unlikely to change. For example, the Linux CPU sensor is cached because CPU information seldom changes. The cache is turned on by default for base system probes and sensors whose output is unlikely to change.
Warning: Do not turn on the cache for classification and identification probes. Furthermore, do not turn on the cache for probes that trigger additional probes because this may prevent them from being triggered.

Sensors
Every probe in Discovery must have a corresponding sensor to process the data returned. For example, if incoming data is the result of a WMI probe, then the WMI sensor is triggered to process the payload.
Note: If you create a multiprobe, you must create a multisensor to process the data returned from this probe. For details, see Multiprobes and Multisensors.

To view the list of sensors in the system, navigate to Discovery > Discovery Definition > Sensors. The sensor form provides the following unique fields.

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

16

Field Reacts to probe Condition script Sensor Type [sys_class_name]

Description Select the probe whose payload this sensor must process. Create a predetermined requirement for this sensor to run. Select the type of sensor to create: Import Export Map: This option is not currently used. MultiSensor: Multisensors process the data returned from multiprobes. Select this type to create a multisensor that responds to the simple probes used in a multiprobe. Sensor: Select this type if this sensor is a simple sensor that responds to a simple probe.

Sensor type [sensor_type]

Specify how the answer from the probe is processed. Classifier: This field is not currently used. Java: This field is not currently used. Javascript: Returned data from the probe is processed in the sensor itself, outside the application, and is visible to the user. This is the most common sensor type. Multiline Text: This field is not currently used. XML: The XML data from the probe is broken into pieces. Some pieces can be used to launch other probes that the original sensor needs to complete all the necessary information about a device.

Script

Enter a script to run when processing the probe package. You can use the g_probe_parameters hashmap in a sensor script to set probe parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.

g_probe_parameters['node_port'] = 16001;

Multiprobes and Multisensors

Multiprobes contain one or more simple probes configured to extract specific information from manageable devices by executing multiple queries with a single authentication. You can schedule multiprobes to run any time in the discovery process to make exploration more efficient. One common use for multiprobes is as identity probes. Identity probes ask a device for information such as its name and serial number, and then use the results of those queries to update existing CIs in the CMDB. To process the data returned from a multiprobe, you must create multisensors, which run scripts that process the data returned by the multiprobes. Multisensors typically use the same name as their corresponding multiprobes.

Creating Multiprobes
1. Navigate to Discovery > Discovery Definition > Probes. 2. Click New. 3. Complete the form using the following settings: Probe type: Multiprobe. ECC queue topic: MultiProbe. 4. In the Includes probes related list, add the probes you want to include in the multiprobe. 5. Click Save.

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

17

Adding Simple Probes

Add simple probes to your multiprobe in the Includes Probes related list. You can add simple probes of any type to a multiprobe and mix probe types if necessary.
Warning: Do not add a multiprobe to the Includes Probes related list.

To add simple probes, do one of the following: Click Edit to add existing simple probes to the multiprobe. Move the appropriate simple probes into the Includes probes List. Click New to create a new simple probe for the multiprobe. This is an advanced procedure and requires a strong knowledge of JavaScript.
MultiProbe record

Multiprobes Included with ServiceNow

The following multiprobes are included with the base ServiceNow system. The corresponding multisensors have the same names.

Editing the list of included probes

Multiprobe AIX - ADM

Includes These Probes AIX - Active Processes: Gets active running processes Unix - Active Connections: Retrieves active connections information AIX - Network: Determines network interfaces, IPs, and MACs AIX - Serial Number: Retrieves the AIX serial number CIM - SMI-S - Computer System: Gets a CIM Computer System per SMI-S HP-UX - Active Processes: Gets active running processes Unix - Active Connections: Retrieves active connections information HP-UX - Hardware Serial Number: Retrieves HP-UX serial number HP-UX - Network: Retrieves HP-UX networking information Linux - Hardware Information: Gets DMI (BIOS) information Linux - Network: Gets network information Mac OS X - Network: Gathers network information from Macintosh machines Mac OS X - CPU/Memory: Gathers CPU and memory information from Macintosh machines SNMP - Identity Info: Identifies a printer CI SNMP - F5 BIG-IP - Identity - Serial: Retrieves the BIG-IP chassis serial number, which is globally unique for this vendor SNMP - Identity Info: Identifies an SNMP device

AIX - Identify

CIM - SMI-S - Identity HP-UX - ADM

HP-UX - Identify

Linux - Identify

Mac OS X - Identify

SNMP - Identify SNMP - Load Balancer Identity

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

18

Solaris - ADM

Solaris - Active Processes: Gets active running processes Unix - Active Connections: Retrieves active connections information Solaris - Network: Gets network information about Solaris devices Solaris - Serial Number: Gets the serial number for Solaris devices Unix - Active Processes: Gets active running processes Unix - Active Connections: Retrieves active connections information ESX - OS: Identifies ESX machines UNIX - OS: Runs after the ESX - OS probe to determine the operating system for SSH devices not identified as ESX Windows - Active Processes: Gets active running processes Windows - Active Connections: Retrieves active connections information Windows - Network: Probes a Windows machine for network information Windows - OS/Hardware Information: Probes a Windows machine for WMI information

Solaris - Identify

Unix - ADM

UNIX - Classify

Windows - ADM

Windows - Identify

Note: This probe requires the installation of a command line tool from Oracle called SNEEP. To download and install this tool, log in to the Oracle website [2]. After this tool is installed, the serial number probe runs automatically when Discovery detects a Solaris device.

Creating Multisensors
To create a new multisensor, navigate to Discovery > Discovery Definition > Sensors, and then click New. The MultiSensor form provides the following unique fields:
Field Reacts to probe Condition script Sensor Type Sensor type Select the probe whose payload this sensor must process. Description

Create a predetermined requirement for this sensor to run.

Select MultiSensor. Specify how the answer from the probe is processed. Classifier: This field is not currently used. Java: This field is not currently used. Javascript: Returned data from the probe is processed in the sensor itself, outside the application, and is visible to the user. This is the most common sensor type. Multiline Text: This field is not currently used. XML: The XML data from the probe is broken into pieces. Some pieces can be used to launch other probes that the original sensor needs to complete all the necessary information about a device.

You must configure the sensor to process the data returned from the individual probes in the multiprobe. Scroll down to the Responds to Probes related list and click New. Define the scripts that process the multiprobe data using the following unique fields.

Probe Results Cache

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

19

Field Reacts to probe Script

Description Select the probe within the multiprobe that this sensor reacts to. The sensor must be linked to the probe by function, such as network identification or serial number. Enter a script to run before the script in the multisensor. This script defines how the data returned from each probe should be processed.

The Responds to Probes related list contains two separate links. The first link opens the record for the probe this sensor responds to. The link in the Script column opens the record that defines the sensor's response to the probe.

Enhancements
Eureka
Provides improved probe performance by caching probe results on the instance and only processing results that have changed. Provides a global probe parameter to set the maximum probe payload size.

References
[1] http:/ / community. service-now. com [2] https:/ / login. oracle. com/ mysso/ signon. jsp

Article Sources and Contributors

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

20

Article Sources and Contributors

CIM Discovery Source: http://wiki.servicenow.com/index.php?oldid=209605 Contributors: Cheryl.dolan, Roy Laurie, Steve.wood, Vaughn.romero CIM Probe Source: http://wiki.servicenow.com/index.php?oldid=210323 Contributors: Cheryl.dolan, George.rawlins, Vaughn.romero CimIQL Source: http://wiki.servicenow.com/index.php?oldid=210108 Contributors: Roy Laurie, Vaughn.romero Data Collected by Discovery on Storage Devices Source: http://wiki.servicenow.com/index.php?oldid=214980 Contributors: Vaughn.romero Probe Results Cache Source: http://wiki.servicenow.com/index.php?oldid=214881 Contributors: Cheryl.dolan, Chris.nguyen, George.rawlins, Vaughn.romero

Image Sources, Licenses and Contributors

CONCEPT RELEASE NOT FOR USE IN PRODUCTION Features in the release may or may not be productized

21

Image Sources, Licenses and Contributors

Image:CIM_SMI-S_Standard_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_SMI-S_Standard_Diagram.png License: unknown Contributors: Steve.wood Image:CIM_Agents_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_Agents_Diagram.png License: unknown Contributors: Joseph.messerschmidt, Steve.wood Image:CIM_Shazzam_Processing_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_Shazzam_Processing_Diagram.png License: unknown Contributors: Steve.wood Image:CIM_wbem_Port_Probe.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_wbem_Port_Probe.png License: unknown Contributors: Steve.wood Image:CIM_SLP_Query.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_SLP_Query.png License: unknown Contributors: Steve.wood Image:Shazzam_with_CIM_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Shazzam_with_CIM_Diagram.png License: unknown Contributors: Steve.wood Image:CIM_CLassify_Probe.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_CLassify_Probe.png License: unknown Contributors: Steve.wood Image:CIM_Data_Model1_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:CIM_Data_Model1_Diagram.png License: unknown Contributors: Steve.wood Image:ECC_Queue_Output.png Source: http://wiki.servicenow.com/index.php?title=File:ECC_Queue_Output.png License: unknown Contributors: Steve.wood Image:ECC_Queue_Input.png Source: http://wiki.servicenow.com/index.php?title=File:ECC_Queue_Input.png License: unknown Contributors: Steve.wood Image:Caution-diamond.png Source: http://wiki.servicenow.com/index.php?title=File:Caution-diamond.png License: unknown Contributors: John.roberts Image:Warning.gif Source: http://wiki.servicenow.com/index.php?title=File:Warning.gif License: unknown Contributors: CapaJC Image:Discovery Multiprobe.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multiprobe.gif License: unknown Contributors: Steve.wood Image:Discovery Multiprobe Edit Probes.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multiprobe_Edit_Probes.gif License: unknown Contributors: Steve.wood Image:Discovery Multisensor and Script.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multisensor_and_Script.gif License: unknown Contributors: Steve.wood