ServiceNow Discovery in Detail

Discovery ServiceNow

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Tue, 20 Nov 2012 00:44:21 PST

1

Introduction Getting Started Overview Discovery uses conventional techniques and technology to extract information from computers and other devices. It uses a wide variety of probes (simple commands or queries) to gather information, and matching sensors (small, simple programs, usually in JavaScript that you can modify) to analyze that information and load it into the CMDB. Discovery uses these probes and sensors to explore any given computer or device, starting first with basic probes and then using more specific probes as it learns more. Discovery finds out about the existence of any device connected to the network by using the Shazzam probe to determine what TCP ports are open, and whether the device responds to SNMP queries. From this information, Discovery infers what kind of device is at that IP address – a Unix server, a Windows computer, network switch, and so on. For each type of device, Discovery uses different kinds of probes to extract more information about the computer or device, and the software that's running on it: • Windows computers and servers: remote WMI queries, shell commands • Unix and Linux servers: shell command (via SSH). Discovery supports Bourne Shell (sh) and Bourne-again Shell (bash). • Printers: SNMP queries • Network gear (switches, routers, etc.): SNMP queries • Web servers: HTTP header examination • Uninterruptible Power Supplies (UPS): SNMP queries

What Discovery Does with the Information The information that Discovery gathers about devices can be used to update the Configuration Management Database (CMDB) automatically. Discovery employs Identifiers to search the CMDB for Configuration Items (CI) that match devices discovered in the network. These Identifiers can be configured to instruct Discovery to take certain actions when device matches are made or not made. There are three possible result states that Discovery recognizes: • When a discovered device is found to match an existing CI in the CMDB, then continue Discovery and update the CI. • When a discovered device is not found to match an existing CI, then continue Discovery and create a new CI in the CMDB. • Take no action in the CMDB, whether a match is made or not. Discovery stops after the identification process.

Getting Started

Discovery Architecture ServiceNow is normally hosted in ServiceNow's data center, and it does not have the ability to access the enterprise's network – but Discovery needs access to do its job. Many enterprises have multiple networks, often separated by slow WAN links or security barriers – and Discovery needs access to all of them. Discovery uses special server processes (called MID Servers), that are installed on each enterprise network that has computers or devices to be discovered. Each MID server is a lightweight Java process that can run on a Linux, Unix, or Windows server. A dedicated server is not required, as the MID server's resource consumption is quite low (and is controllable). The MID server's job during Discovery is simply to execute probes and return the results back to the ServiceNow instance for processing; it does not retain any information. In effect, a MID server is a remote extension of the ServiceNow instance, on an enterprise network. MID servers communicate with the ServiceNow instance they are associated with by a simple model: they query the instance for probes to run, and they post the results of probes they've completed back to the instance. There, the data collected by the probes is processed by sensors, which decide how to proceed. The MID server starts all communications, using SOAP on HTTPS – which means that all communications are secure, and all communications are initiated inside the enterprise's firewall. No special firewall rules or VPNs are required. Discovery is agentless - meaning that it does not require any permanent software to be installed on any computer or device to be discovered. The MID server uses several techniques to probe devices without using agents. For example, the MID server will use SSH to connect to a Unix or Linux computer, and then run a standard command (such as uname or df) to gather information. Similarly, it will use the Simple Network Management Protocol (SNMP) to gather information from a network switch or a printer. For more details, see Discovery Agentless Architecture.

Discoverable Windows Operating Systems Discovery can classify and discover Windows servers and workstations that use the following operating systems: • • • • • • •

Windows NT Server Windows 2000 Server Windows 2003 Server Windows 2008 Server Windows XP Windows Vista Windows 7

Discovery vs. Help the Help Desk Help the Help Desk is a standard ServiceNow feature available through the self-service application (Self Service > Help the Help Desk). It will gather information (much as Discovery does) about a single Windows computer by running a script on that computer. Discovery does many things that Help the Help Desk can not do. Here's a comparison of the two:

2

Getting Started

3

Capability

Discovery Help the Help Desk

Automatic discovery by schedule Automatic discovery on user login Manually initiated discovery Windows workstations Windows servers

*

Linux systems Unix systems (Solaris, AIX, HP-UX, Mac (OSX)) Network devices (switches, routers, UPS, etc.) Printers Automatic discovery of computers and devices Automatic discovery of relationships between processes running on servers

* Returns information about Windows server machines when Discovery is installed.

Discovery Made Easy Overview What is Discovery? The easiest way to sum up Discovery is to say that it's a set of conventional (and common) techniques used to extract information from computers and other devices. The techniques used are nothing new and have been around for years. In fact, some are over 10 years old. (e.g., SSH - Secure Shell on UNIX).

The Census Agent Discovery is like the United States Census - the government headcount that sends census agents to your door to gather information about your household - such as how many people live there and whether you have been to college. The census agents report their findings back to the government, who puts all the data into a database. That’s exactly what Discovery does, but instead of a census agent, we use an agent called a MID Server. Before a census agent can survey a neighborhood, he needs to know where to go. So does the MID Server. However, the MID Server doesn't quite understand a street address, but instead understands IP addresses. An IP address (e.g., 34.237.9.72) is the address to a computer on a network. The census agent can get to your house just fine, using your address, but when he arrives, he needs some kind of identification or badge, so that you will talk to him. In the Internet world, this identification is known as credentials. Access to computers is normally granted to you if you have the correct credentials - a user name and password. What have we learned so far? Before we can discover anything, we need a MID Server, IP addresses, and credentials. This is simple enough. Now that we have Discovery configured, we need to start working. Nothing gets accomplished if the census agent doesn’t start knocking on some doors. The next step is to have our MID Server start knocking on doors. The MID Server finds the devices it needs to question by using the IP addresses it was given. When it visits a device, the MID Server attempts to question the device about what language it speaks. A census agent would probably ask the person at the door what language they speak in their home. To achieve this, our MID Server does a simple port scan. It will scan a few commonly known ports to determine what kind of operating system the device uses. For example, the MID Server checks to see if port 22 is listening. What does this mean? When a

Discovery Made Easy device is online and communicating with other devices, it usually does this using a protocol called TCP/IP (or just TCP for short). TCP uses ports to establish a connection and communicate. For example, Web sites usually run on port 80. When you type in www.google.com, you're connecting to that address via port 80. Using this example, if we scan a device's ports and determine that it is listening on port 80, we can assume that it's running a Web server/Web site. We use this same approach to determine what kind of operating system the device is using. Back to port 22 – that's the port most UNIX or Linux machines use for their command line administrator. So we know that if a device is listening on port 22, the odds are pretty good that it's a UNIX or Linux machine. We use the same approach for Windows, which listens on port 135. Once we've determined the operating system, we can talk the talk and communicate with the device using its own native language. For UNIX we use SSH (Secure Shell), and for Windows we use WMI (Windows Management Instrumentation). For other devices like Netgear (routers and switches) and printers, we use SNMP. So now we know what kind of operating system the device has, and we know what language to speak. Now we need to ask it some questions. The census agent would probably ask questions like “How many kids do you have?" or "How much money do you make?” The MID Server needs to ask questions like “What version of Windows are you running?", "How much RAM do you have?", and "How fast are you?” The MID Server ask these questions with probes. When a MID Server runs a probe, it's basically asking a question. Asking the question is only half of the work, however. The other half is writing it down or translating it into terms that ServiceNow can understand. We do this by using sensors. The sensor is the part of the process that analyzes and records the data. The probe's job is simply to ask the questions and pass the information along to the sensor, which properly translates the response.

Probing the Neighborhood Let's go a little more into the world of probes and sensors, since they are the foundation of the Discovery feature. Probes are sent on their errands by the MID Server, and sensors live on the instance. In the census world, the sensor would work out of the census office. The MID Server is out in the network (neighborhood) using probes (census agents) to gather information. That information is returned to the instance where the sensor processes the data. Sometimes, when the MID Server passes the information to the sensor, the sensor decides that it needs more information and makes the MID Server run more probes. For example, if the MID Server tells the sensor the device is running a Web server, then the sensor is going to tell the MID Server to go back to that IP address and run a probe to ask the device what Websites it hosts. The following diagram demonstrates the conversation between the MID Server and the sensor.

4

Discovery Made Easy

Hopefully, you have a basic understanding of Discovery by now. To recap, we'll go over the fundamentals of Discovery, then run through a scenario that uses these fundamentals. • • • •

Discovery is the process of extracting information out of devices and recording it in a uniform way. The Discovery process uses your ServiceNow instance and one or more MID Servers. The MID Server is a light-weight (e.g., small and simple) agent that runs on a server in your network. The MID Server needs ranges of IP Addresses and credentials (user names and passwords) before it can begin discovering. • The MID Server gathers information (using probes) and passes it to the instance to be processed (using sensors).

No Secrets The MID Server is very adept at ferreting out information, but it's up to you to give it the tools it needs to do the job. Here's a simple scenario, stepped out to make it easy to follow. Your ServiceNow instance is running, and Discovery is enabled. You also have a MID Server somewhere in your network that you think is communicating with your instance. We'll do a Discovery on a single device.

MID Server Preparation 1. The first thing we do is to make sure the MID Server is started and connected to the instance. For information about connecting MID Servers to an instance, see MID Server Configuration. 2. We must configure our Discovery IP address ranges to include the address of the single device. In this case the device has an IP address of 10.10.10.5. 3. We must remember to specify credentials for the MID Server to use to log in to the device. Now that we've configured all the basics, we're ready to kick off a Discovery on 10.10.10.5. 4. To enable Discovery manually, click the Discover Now link in a Discovery Schedule record.

5

Discovery Made Easy

Discovery Happens Once Discovery has started, it's all up to the MID Server. 1. The instance prepares a probe for the MID Server with a range of IP addresses to test, and then delivers the probe when the MID Server checks in for jobs to do. 2. The MID Server visits 10.10.10.5 (knocking on the device's door) and scans the ports.

3. 4. 5. 6. 7. 8.

The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linux machine. The MID Server advises the instance of what it has discovered. The sensor creates the Get Operating System probe and delivers it when the MID Server checks in for jobs again. The MID server probes the Linux machine to determine its operating system. When the machine replies Linux, the MID Server passes this information to the sensor. Because this is a Linux machine, the sensor asks the MID Server to send a few more probes to get information about the hard disk, the network adapters, and any processes that are running. The MID Server runs each of those probes and sends the results back to the sensor, which translates the findings for the instance.

Have We Met? So now you have a list of devices that you found and a lot of information about those devices, but what can you do with this information? Chances are, you already know about many of the devices that Discovery finds in your network. Most of the computers, routers, printers, and so forth that you have in your Configuration Management Database (CMDB) will show up every time you run Discovery. Then there are those devices that you don't know about yet - devices recently added to the network perhaps - that are not in your CMDB. Well, it makes sense that you should add those new devices to your database, and it also makes sense to update existing devices, particularly if someone has installed new memory, new software, or added a disk drive. Discovery can do these things automatically. Discovery can launch probes that return identity data from the devices it finds. Discovery then feeds that information into a handy tool called an Identifier that searches the CMDB for a matching device. If the Identifier determines that ServiceNow already has a record of the device, the Identifier can tell Discovery to launch more probes and update the existing record. If the Identifier cannot find a matching device in the database, it can tell Discovery to continue exploring and then create a new record in the database. If you don't want these automatic updates for any reason, you can tell the Identifier to stop Discovery and not change anything in the CMDB. And that's all there is to it! We've learned how to Discover a device by using lightweight, remote probes, and we've learned that we can use the information returned to update our Configuration Management Database automatically.

6

Discovery Agentless Architecture

Discovery Agentless Architecture Overview This page describes the architecture for ServiceNow's Agentless Discovery. The two important parts we will cover are Communications and Data Collection and Processing. Communication is how your ServiceNow instance talks to the MID Servers and how the MID Servers talk to your devices. Data Collection and Processing is how we scan your devices and process the information we have gathered.

Communications

This diagram demonstrates a typical Discovery setup for a hosted ServiceNow instance. The MID Server is installed on the local internal network (intranet). All communications between the MID Server and the ServiceNow instance is done via SOAP over HTTPS (Secure HTTP - blue lines). Since we use the highly secure and common protocol HTTPS, the MID Server can connect to the instance directly without having to open any additional ports on the firewall. The MID Server can also be configured to communicate through a proxy server if certain restrictions apply (dashed blue lines). The MID Server is deployed in the internal network, so it has access to connect directly to discoverable devices (orange lines). Typical protocols the MID Server uses to communicate with devices are: • UDP • SNMP (Routers / Switches / Printers) • TCP • SSH (Secure Shell, UNIX) • WMI (Windows Management Instrumentation)

7

Discovery Agentless Architecture

8

• Windows PowerShell Note: Proper login credentials are required for accessing devices.

Data Collection and Processing (Probes and Sensors)

At ServiceNow, we refer to "Data Collection" as a Probe and "Data Processing" as a Sensor. Hence when you hear the term "Probes and Sensors" you can think of "Data Collection and Processing". The purple lines represent the MID Server probing for information. The MID Server then passes the results of each probe to the ServiceNow instance via SOAP/HTTPS (green lines). Sensors (red box) within the ServiceNow instance process the information gathered and update the CMDB.

9

Discovery Tasks Setting up Discovery Overview Discovery can run on a regular, configurable schedule or can be launched manually. Whenever a Discovery runs, it runs over a specified IP address range which tells the Discovery process which specific devices to investigate. To retrieve useful information, Discovery needs credentials (usually a user name and password pair) for devices within a particular range so that Discovery can connect to and run various probes on the devices it finds. Discovery compares the devices it finds with configuration items (CI) in the CMDB and updates any matching devices. If Discovery does not find a matching CI in the CMDB, it creates a new CI. For details on how Discovery works, see Getting Started with Agentless Discovery. To set up Discovery and configure it to update the CMDB accurately, perform the following tasks in the order in which they appear.

Enhancements October 2011 Preview 1 • Oracle database Discovery: Discovery now detects the Oracle instance name, the Oracle listener, and the port on which the listener communicates. In this release, Discovery replaces the generic Oracle name in the Oracle Instance form (Configuration > Database Instances > Oracle) with the discovered instance name. Oracle listener

Setting up Discovery

Click the link to the listener in the Oracle Instance form.

The new Oracle Listener form appears.

• DNS in device history: Personalize the device history list to display DNS names for discovered devices. • Passing parameters to a probe: It is now possible to use the g_probe_parameters hashmap from within a sensor, a device classification, or a process classification script to set probe parameters for any configured, triggered probes. • The following MID Server parameters were added: • mid.ssh.local: Executes commands for the MID Server host machine (localhost) via SSH rather than from a console. • mid.ssh_max_retries: The maximum number of times to retry an SSH operation after a time-out. This setting overrides the MID Server default retry setting. • Windows uninstall strings: A new column was added to the Software Installed related list in a Windows Server configuration item (CI) record that displays the paths used by the Add or Remove Programs utility to uninstall software detected on Windows operating systems. • Ports added to process applications: Discovery now uses the process identifier (PID) of any application classified as a process to discover the listening ports used by that process. With this release the TCP port field in the process form is automatically populated with one or more ports. In previous versions, this field was populated manually.

10

Setting up Discovery

October 2011 Preview 2 DNS Name Resolver probe: This probe resolves DNS names into IP addresses.

Aspen Support for clustered process Discovery has been generalized to extend beyond Microsoft SQL Server.

Aspen Patch 3 The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from the platform. The localhost MID Server originally was intended for demonstration purposes and was not intended to be a supported feature.

Task 1: Prerequisites • Select a MID Server host: Select a computer to host the MID Server. See MID Server Requirements for Discovery for a complete list of MID Server requirements. • Gather credentials: Gather the login credentials that the MID server must use to access the devices it is expected to discover. See Discovery Credentials for instructions on providing Discovery with the proper credentials. • Select IP Address Ranges: Determine the IP addresses that Discovery must scan. In a very complex network, it is good practice to group IP ranges into a Range Set, which is reusable for different schedules. Discovery will not scan anything outside of these ranges.

Task 2: Enable the Discovery Plugin Contact ServiceNow to activate the Discovery Plugin.

Task 3: Deploy the MID Server to the Host Install one or more MID servers on physical or virtual servers that meet the minimum requirements and configure them to communicate with the appropriate ServiceNow instance. A best practice is to install at least two MID Servers at first and assign them to different schedules and IP ranges. The better use of multiple MID Servers can be utilized through Discovery Behaviors which can balance the work of an overall schedule between two or more MID Servers to help complete discoveries quicker.

11

Setting up Discovery

Task 4: Ensure MID Server Connectivity Open the instance and navigate to Discovery > MID Servers. If the new MID Servers are configured properly, they will appear in the list of MID Servers. If a MID Server does not appear as a choice in the instance, perform the following checks in the MID Server: • Ensure that the URL provided is correct. • If the MID Server is installed on Windows, make sure the ServiceNow MID Server service is configured properly with the correct logon credentials and is running. • Check the MID Server log for errors. This log is located in the MID Server directory on the host machine in agent\logs\agent0.log0. • If Basic Authentication is enabled, a user name and password must be provided. • The MID Server might not have outbound access on port 443 (SSL) or a proxy server might be preventing TCP communication to the instance. • Make sure that no firewalls are blocking communication between the MID Server and the instance.

Task 5: Set Credentials on the Instance Set the Discovery Credentials on the instance for all the devices in the network - Windows and UNIX computers, printers, and network gear. Credentials for Windows devices (using the WMI protocol) are provided by the logon configured for the MID Server service on the Windows server host. Credentials for UNIX, vCenter, and SNMP must be configured on the instance. Discovery will automatically figure out which credentials work for a particular computer or device.

Task 6: Define Discovery Schedules and Run Discovery The Discovery Schedule is the control point for running discoveries. The schedule controls when Discovery runs, defines the MID Server to use, the type of Discovery that should run, and the IP addresses to query. Create as many schedules as necessary, using different types of discoveries, and configure them to run at any time. Let Discovery run on its configured schedule or manually execute Discovery at any time. These schedules can be set up in a variety of ways, including a single schedule for the entire network or separate schedules for each location or VLAN. If you do not know the IP address to scan in your network, run a Network Discovery first to discover the IP networks. Once discovered, you can convert these networks into IP address range sets that you use in a Discovery Schedule. Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use Discovery Behaviors.

Task 7: Validate the Results Initial Discoveries often reveal unexpected results, such as previously unknown devices and processes or failed authentication. Results should also accurately identify known devices and update the CMDB appropriately. Become familiar with the network that is being Discovered and what types of data are returned for the different types of discoveries. Use the Discovery Log and the ECC Queue to monitor the Discovery process as data is returned from the probes. To view the actual payload of a probe, click the XML icon in a record in the ECC Queue.

12

Setting up Discovery

Discovery Log Use the Discovery Log form for a quick look at how the probes are doing. To display the Discovery Log, select Discovery Log in the Related List of a Status record. The log record allows users to drill down into other records from this list. The Discovery Log provides the following information: Column

Information

Created

Displays the timestamp for the probe launched. Click this link to view the record for the probe launched in this list.

Level

Displays the type of data returned by this probe. The possible levels are: • • • •

Debug Error Information Warning

Message

Message describing the action taken on the information returned by the probe.

Source

Probe name

CMDB CI

The CI discovered. Click this link to display the record from the CMDB for this CI.

Sensor

Displays the type of sensor that responded to the probe in this entry. Click this link to open the ECC Queue record for the sensor, including the XML payload.

Device

Displays the IP address explored by the probe. Click this link to examine all the log entries for the action taken on this IP address by this Discovery.

13

Setting up Discovery

Troubleshooting Navigate to Discovery > Status and examine the status record for the current Discovery. From this record, use the links to examine the following: • Discovery Log: this log shows such Discovery issues as: • Failed credentials • Inaccessible ports • Problems with Windows Firewall • Viruses or intrusion products running in the network • WMI Services not running • WMI drivers not installed • UNIX devices with ACLs running to restrict access • ECC Queue: examine the payloads of the individual probes and sensors to validate information returned against what was expected. These results can help explain suspicious errors, such as why no software was detected running on a network server. To check returned data, run queries on the MID Server machine from products such as: • Scriptomatic (WMI) • PuTTY (SSH) • iReasoning (SNMP)

Common Procedures Troubleshoot a Discovery using the procedures outlined in the following stages: 1. 2. 3. 4.

Port Scanning Classification Identification Exploration

14

15

MID Server MID Server Plugin Overview The Management, Instrumentation, and Discovery (MID) Server is a Java server that runs as a Windows service or UNIX daemon. The MID Server facilitates communication and movement of data between the ServiceNow platform and external applications, data sources, and services. For specific requirements for using the MID Server with Discovery, see MID Server Requirements for Discovery. The MID Server is installed automatically for new instances.

Enhancements Aspen Patch 3 The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed from the platform with the Aspen Patch 3 release. This MID Server originally was intended for demonstration purposes and was not intended as a supported feature.

Functional Architecture The MID Server is a Java process that oversees 2 main functional groups of sub-processes, namely Monitors and Workers. A Monitor runs in a separate thread as a timer object and is configured to execute a task periodically, returning its result to ServiceNow's ECC Queue (External Communication Channel Queue). A Worker is an on-demand thread that executes a task when a corresponding ECC output queue record is read from ServiceNow (The Queue Monitor reads the ECC output queue and triggers a Worker). For example, a Discovery probe is a Worker. Monitors 1. 2. 3. 4. 5.

Auto Upgrade Heartbeat Queue Monitor Queue Sender Synchronizers • • • • •

Altiris LanDesk Microsoft SMS IBM Tivoli CCMDB JDBC

Workers 1. Command Line 2. JDBC 3. File

MID Server Plugin 4. Probes • • • •

HTTP WMI SNMP SSH

JAR File Synchronization In the Aspen release, an administrator can upload a JAR file to an instance and synchronize it to all MID Servers. The administrator can then write custom probes that use the synchronized JAR file. To upload a JAR file to the instance: 1. Navigate to MID Server > JAR Files. 2. Click New. 3. Complete the following fields: • Name: A unique and descriptive name for identifying the file in the instance. • Version: A version number for the file, if one is available. • Source: Location of the JAR file for reference purposes. Source information is not used by the system. • Description: Short description of the JAR file and its purpose in the instance. 4. Click the paper clip icon in the banner and attach the JAR file to the record.

5. Click Submit. The platform makes the JAR file available to any MID Server configured to communicate with the instance.

System Requirements The MID Server has run and been tested in the following environments: • • • •

Windows Server 2003 and later. Virtual hosts and 64 bit systems are supported. Linux RedHat ES 3+. On 64-bit Linux systems, the 32-bit GNU C library [1] (glibc) must be installed. Solaris 2.8+ HP-UX 11.0

The minimum configuration suggested is: • • • •

4GB of available RAM per application 2+GHZ CPU (Multi-Core preferred) 500MB of disk space per application deployed Can ride-along with other services (dependent on server utilization and resource availability)

16

MID Server Plugin

Applications The MID Server is used by the following applications: • • • • • • • • • •

Discovery Runbook Automation Import Sets Altiris Microsoft SMS / SCCM Avocent LANDesk HP OpenView Operations Microsoft System Center Operations Manager (SCOM) Borland Starteam Integration Microsoft MIIS

References [1] http:/ / www. gnu. org/ s/ libc/

MID Server Requirements for Discovery Overview The ServiceNow MID Server is used for enterprise application and service monitoring, integration, Runbook Automation, and Discovery. The requirements in this page are specifically for the use of MID Servers with the ServiceNow Discovery and Runbook Automation products.

System Requirements The MID Server has run and been tested in the following environments: • • • •

Windows Server 2003 and later. Virtual hosts and 64 bit systems are supported. Linux RedHat ES 3+. On 64-bit Linux systems, the 32-bit GNU C library [1] (glibc) must be installed. Solaris 2.8+ HP-UX 11.0

The minimum configuration suggested is: • • • •

4GB of available RAM per application 2+GHZ CPU (Multi-Core preferred) 500MB of disk space per application deployed Can ride-along with other services (dependent on server utilization and resource availability)

External Connectivity Requirements The MidServer communicates securely on port 443 to the instance and requires no inbound connections. In some cases, it might be necessary to allow this communication through the firewall if the MID Server fails to register on the instance. To determine if the application or a network security restriction is to blame for connection failure, attempt to telnet to the instance on port 443 from the server that is hosting the MID Server application. If this connection fails, then the problem could be a web proxy (since 443 is a https connecton) or a Firewall rule

17

MID Server Requirements for Discovery preventing external TCP connections from that host. Contact network security personnel for the proxy information to add to the config.xml file, or request that the Firewall be configured to allow access using one of the following syntaxes: • to • to any established • to 443

Internal Requirements The three methods used for discovering various devices on a network are SSH, WMI and SNMP. SSH is used for accessing UNIX-like machines. Discovery logs into a machine with SSH and runs commands within an encrypted session to gather system information. Runbook Automation logs in to UNIX and Linux machines using SSH to perform Workflow activities. WMI is used by Discovery for Windows based machines and is used for querying the remote WMI protocol on targets for gathering of Windows information. Runbook Automation uses PowerShell to run activities on Windows machines. And lastly, SNMP v1/v2 is used on various network devices (Routers, Switches, Printers) by Discovery and Runbook. Detailed information is listed below about these methods.

SSH - UNIX For UNIX-like machines, Discovery and Runbook use SSH [1] to access target machines. SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. SSH communicates on port 22 within an encrypted datastream and requires a login to access the targets using two available methods of authentication: a user name and password combination and a user name and shared private key. Specify SSH authentication information and type in the Credentials module. If multiple credentials are entered, the platform tries one after the other until a successful connection is established or all are ultimately denied. To provide for application relationships a limited number of SUDO commands must be available to be run. Additional details to these requirements can be found in UNIX/Linux commands requiring root privileges for Discovery.

WMI - Windows For Windows machines, Discovery uses the Windows Management Instrumentation (WMI) [2] interface to query devices. Due to Microsoft security restrictions for WMI, the MID Server application executing the WMI queries must run as a domain user with local (target) administrator privileges. When Discovery detects activity on port 135, it launches a WMI query. The response from the Windows device is sent over a Distributed Component Object Model (DCOM) port configured for WMI on Windows machines. This can be any port [3]. Ensure that the MID Server application host machine has access to the targets on all ports due to the unique nature of the WMI requirements.

Windows PowerShell PowerShell [4] is built on the Windows .NET Framework and is designed to control and automate the administration of Windows machines and applications. Runbook Automation uses PowerShell to run Workflow activities on Windows machines. PowerShell must be installed on any MID Server that executes these activities. MID Servers using PowerShell must be installed on a supported Windows operating system. ServiceNow supports PowerShell 2.0. Runbook activities for PowerShell require a credentials Type of Windows.

18

MID Server Requirements for Discovery

SNMP - Network For network devices, a SNMP scan [5] is used to get device specific MIBs and OIDs. SNMP is a common protocol used on most routers, switches, printers, load balancers and various other network enabled devices. Use a "community string" (password) for authentication when scanning a device via SNMP. Many devices have an out-of-box community string of public which Discovery (by default) uses when querying a target. Define additional community strings in the Credentials module which are tried in succession, along with public, until a successful query returns. In addition to the credentials, the platform also requires the ability to make port 161 SNMP requests from the MID Server to the target. If Access Control Lists (ACLs) are in place to control the IP addresses that can make these queries, ensure that the IP address of the MID Server is in the ACL. The out-of-box Runbook activity SNMP Query returns the OID of a device and requires SNMP credentials.

WBEM Web-Based Enterprise Management (WBEM [6]) defines a particular implementation of the Common Information Model (CIM [7]): , including protocols for discovering and accessing each CIM implementation. WBEM requires either of two ports, 5989 or 5988 and uses the HTTP transport protocol. WBEM supports SSL encryption and uses CIM user name/password credentials. ServiceNow Discovery launches a WBEM port probe to detect activity on the target ports and to append gathered data to a classification probe that explores CIM Servers.

References [1] [2] [3] [4] [5] [6] [7]

http:/ / en. wikipedia. org/ wiki/ Secure_Shell http:/ / en. wikipedia. org/ wiki/ Windows_Management_Instrumentation http:/ / support. microsoft. com/ kb/ 832017 http:/ / support. microsoft. com/ kb/ 968929 http:/ / en. wikipedia. org/ wiki/ SNMP http:/ / en. wikipedia. org/ wiki/ Web-Based_Enterprise_Management http:/ / en. wikipedia. org/ wiki/ Common_Information_Model_(computing)

19

MID Server Installation

MID Server Installation Deployment The MID Server must be able to communicate with the machines it is configured to probe. There are several reasons why a probe may fail, even though the MID Server can ping the target device. Ensure that the machine on which the MID Server is installed is granted the following network privileges: • Any firewalls between the MID Server and the target devices must be configured to allow a connection. If your network uses a DMZ, and if your network security protocols limit port access from within the network to the DMZ, you might have to deploy a MID Server to a machine within the DMZ to probe the devices there. • Target devices must be configured to allow the MID Server probe to connect. If network security prevents you from configuring new machines that can connect to the targets, then the MID Server must be installed on an existing machine with connection privileges. • The MID Server must be installed with the proper account: either local or domain administrator. Note: The size and complexity of your network might require the deployment of multiple MID Servers. See Deploying Multiple MID Servers for details.

Installation After the MID Server plugin is enabled on your instance, you will see the MID Server application in the Application Navigator. If you have enabled Discovery, Runbook Automation, or any integration that requires the use of the MID Server, this application is also included during these plugin activations.

To download and install a MID Server, navigate to Mid Server > Downloads on your instance. Select and download the MID Server for the operating system you are targeting in the form that appears.

20

MID Server Installation

Windows Select from the following procedures for installing one or more MID Servers on a single machine.

Installing a Single MID Server on a Machine 1. Logon to the host machine on which you want to install the MID Server. 2. Create a directory for the MID Server on the top level of the drive, with a distinctive name, such as ServiceNow\MID Server1. 3. Extract the downloaded MID Server zip file into your new directory. Right click the package and select Extract All from the pop-up menu. 4. Navigate to the \agent directory that was created when the file was extracted and open the config.xml file using a text editor such as WordPad. 5. Edit this file as follows: • Modify and enter the URL to your instance. • Enter the user credentials if basic authentication is enabled (default behavior) in the mid.instance.username/password parameters. • Modify and enter the name of your MID Server. • Enter connection information for any proxy server used and be sure to remove the comment tags from the proxy configuration information. NOTE: If this MID Server is installed on a machine that contains other MID Servers, edit the wrapper.conf file as described below in the procedure for installing multiple MID Servers. 6. Install the MID Server as a Windows service: a. For Windows XP, Windows 2000 Server, or Windows Server 2003: 1. Open the \agent folder in the directory you created for the MID Server installation files. For example, the path might be C:\ServiceNow\MID Server1\agent. 2. Double-click the start.bat file to install the Windows service. b. For Vista, Windows 2008 Server, or Windows 7: 1. Click the Start button. 2. In the search box, type command prompt or cmd.exe. 3. In the result list, right-click Command Prompt or cmd.exe, and then click Run as administrator. This enables the MID Server to be installed with administrative rights under any Windows User Account Control (UAC) setting. 4. In the command prompt, navigate to \agent in the directory you created for the MID Server files. For example, the path might be C:\ServiceNow\MID Server1\agent. 5. Run start.bat.

21

MID Server Installation 7. Edit the MID Server's credentials. a. Open the Windows Services console. b. Double-click on the ServiceNow service. c. In the properties dialog box, select the Log On tab. d. Set Log on as privileges with Domain User or Local Admin credentials. e. In the General tab, set Startup type to Automatic. f. Click OK. 8. Re-start the ServiceNow service and make sure that ServiceNow\\agent\logs\agent0.log does not have error messages. 9. In the instance to which this MID Server is connected, navigate to MID Server > Servers. If Discovery is installed, navigate to Discovery > MID Servers. All MID Servers connected to this instance are listed. 10. Make sure that the Status of the MID Server you just installed is Up.

Installing Multiple MID Servers on a Single Machine You can install multiple MID Servers on a single host or on a virtual machine. 1. Logon to the host machine or virtual machine on which you want to install multiple MID Servers. 2. Create a directory for the MID Server on the top level of the drive, with a distinctive name, such as ServiceNow\. Make sure you create a unique and descriptive name for each MID Server, such as MIDServer_SMS_Int or MIDServer_Disc1. 3. Extract the downloaded MID Server zip file into each MID Server directory. When this is complete, you should have the a directory that resembles the following for each MID Server: \ServiceNow\\agent. 4. Using WordPad, edit the config.xml file in each MID Server \agent directory as follows: • Modify and enter the URL to your instance. • Enter the user credentials if basic authentication is enabled (default behavior) in the mid.instance.username/password parameters. • Modify and enter the name of your MID Server. • Enter connection information for any proxy server used and be sure to remove the comment tags from the proxy configuration information. 5. Using WordPad, edit the wrapper.conf file for each MID Server in the following directory: \ServiceNow\\agent\conf • wrapper.console.title=: This is the title to use when running the MID Server as a console. • wrapper.ntservice.name= example: snc_agent2: This is the internal Windows name for the service and is not displayed. This name must be unique. • wrapper.ntservice.displayname=: This is the name that is displayed to the user in the Windows Services console. For example, you might enter ServiceNow MID Server1. • wrapper.ntservice.description=: This is the optional long description of the service that appears in the Services console. NOTE: These values CANNOT be edited in this file after you create the service. Make sure you name and describe your services correctly before you complete the next step.

22

MID Server Installation 6. Install the MID Server as a Windows service: a. For Windows XP, Windows 2000 Server, or Windows Server 2003: 1. Open the \agent folder in the directory you created for the MID Server installation files. For example, the path might be C:\ServiceNow\MID Server1\agent. 2. Double-click the start.bat file to install the Windows service. b. For Vista, Windows 2008 Server, or Windows 7: 1. Click the Start button. 2. In the search box, type command prompt or cmd.exe. 3. In the result list, right-click Command Prompt or cmd.exe, and then click Run as administrator. This enables the MID Server to be installed with administrative rights under any Windows User Account Control (UAC) setting. 4. In the command prompt, navigate to \agent in the directory you created for the MID Server files. For example, the path might be C:\ServiceNow\MID Server1\agent. 5. Run start.bat. 7. Edit each MID Server's credentials. a. Open the Windows Services console. b. Double-click on the ServiceNow service for each MID Server. c. In the properties dialog box, select the Log On tab. d. Set Log on as privileges with Domain User or Local Admin credentials. e. In the General tab, set Startup type to Automatic. f. Click OK. 8. Re-start each ServiceNow MID Server service and make sure that \ServiceNow\\agent\logs\agent0.log does not have error messages. 9. In each instance to which these MID Servers are connected, navigate to MID Server > Servers. If Discovery is installed, navigate to Discovery > MID Servers. All MID Servers connected to this instance are listed. 10. Make sure that the Status of the MID Servers you just installed is Up.

Unix/Linux 1. Run mkdir -p /servicenow/ to create the installation directory. 2. Unzip the downloaded MID Server zip file, mid..zip into the /servicenow/ directory. The resulting directory structure is /service-now//agent. 3. Open the /agent directory (cd /service-now//agent) and edit the config.xml file as follows: • Modify the and enter the URL to your instance. • Enter user credentials if basic authentication is enabled (on by default) in the mid.instance.username/password parameters • Enter connection information for any proxy server used and be sure to remove the comment tags from the proxy configuration information. 4. Execute the shell script start.sh. 5. In the instance to which this MID Server is connected, navigate to MID Server > Servers. If Discovery is installed, navigate to Discovery > MID Servers. All MID Servers connected to this instance are listed.

23

MID Server Installation

24

6. Make sure that the Status of the MID Server you just installed is Up.

Uninstalling The MID Server runs as a stand-alone service and can be removed easily to accommodate such tasks as redeploying the MID Server to another host machine, or changing the unique name of a MID Server when deploying multiple MID Servers. 1. 2. 3. 4.

Stop the running MID Server service. Open a command window (Start > Run > cmd). Go to the \agent\bin folder in the MID Server installation folder. Double-click the uninstall.bat file.

Upgrading and Testing With the Aspen release, the MID Server is upgraded automatically when the instance is upgraded. The MID Server automatically tests connectivity through a public scripted Web Service.

Downgrading MID Server downgrades are only possible within the same release family. For example, you can downgrade from Berlin Patch 3 to Berlin Patch 2, but not from Berlin to Aspen.

Upgrade Error Messages The following MID Server upgrade error messages are available: Message

Description

Unable to refresh packages

Generic error when no reason is given

Failed to query instance for MID server buildstamp

Instance is offline or there is a major version mismatch between the MID Server and the instance. This message is available in versions at Berlin or later.

Not a valid package buildstamp

InstanceInfo returned an assigned buildstamp that was not in the correct format (possible version mismatch). This message is available in versions at Berlin or later.

Using Basic Authentication To enforce basic authentication on each request from the service via SOAP messages, you may set the property glide.basicauth.required.soap to true. If you do so, each SOAP request would have to contain the "Authorization" header as specified in the Basic Authentication [1] protocol. Because the request is non-interactive, we always require the Authorization header during a request. Supplying basic authentication information, whether or not it is required, has the added advantage that the data created or updated as a result of the Web Service invocation is done on behalf of the user supplied in the basic authentication credentials. As an example, when creating an Incident record, the journal fields will have the user id of basic authenticated user, instead of the default "Guest" user. Note: The user ID used in the MID server connection is only for authentication if enforcing strict security is not required from the Web Service properties. Enabling the Enforce strict security property will cause the usage of roles associated with the user ID to enforce access control on the tables the MID server is accessing, this is not usual.

MID Server Installation Navigate to C:\Program Files\ServiceNow\\agent and edit the config.xml file as follows, using Wordpad: • Find and enter your instance's administrator user name as the value. For example, you might enter • Find and enter the configured password for this instance as the value. For example, you might enter . • Enter the display name that appears for this MID Server in your ServiceNow instance in the following line:

Monitoring Your MID Server To ensure uninterrupted service from the Windows-based MID Server, monitor the application host for the following: • A running snc_agent service, or custom agent names for multiple installations of the MID Server on a host machine. • Running java.exe and wrapper.exe processes. If the MID Server process is the only Java process running on the host, monitor the memory used by java.exe and alert on less than maximum configured memory, as defined in ~\agent\conf\wrapper.conf. • ~\agent\logs\agent0.log.0 and ~\agent\logs\wrapper.txt for warning/critical/severe errors with appropriate thresholds. • Standard server state-of-health metrics: CPU/Mem/Disk utilization and NT Event log/syslog monitoring

Troubleshooting Startup Errors The MID Server agent log displays detailed information about errors encountered when connecting to the ServiceNow instance. This log is created automatically in the \logs directory in the \agent installation directory. The log provides detailed information about the instance and the MID Server each time the MID Server is started. Use this data to ensure that the instance and MID Server versions are compatible and that the MID Server is configured to contact the correct instance. The log record also indicates if basic authentication and strict security are enabled on the instance. This feature is available with the Aspen release.

Connection Failure A number of possible network issues can prevent connection, including a blocking firewall, an improperly configured proxy server, or a DNS issue. The wording of the message can vary, depending on the cause of the failure. Note: If you configured the MID Server config.xml file to use a proxy server, ensure that the comment tags were removed from around the proxy sections configured.

08/29/11 12:31:46 (055) main Running under Java version: 1.6.0_26 08/29/11 12:31:46 (077) main Initializing MID Server 08/29/11 12:31:46 (180) MIDServer MID Server starting 08/29/11 12:31:46 (397) MIDServer Using configuration: /glide/workspace/com.service_now.agent/config.xml

25

MID Server Installation

26

08/29/11 12:31:46 (858) MIDServer Agent home path: /glide/workspace/com.service_now.agent 08/29/11 12:31:46 (959) MIDServer MID Server started 08/29/11 12:31:46 (983) StartupSequencer Setting basic authentication with user swhipple log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.HttpClient). log4j:WARN Please initialize the log4j system properly. 08/29/11 12:31:47 (109) StartupSequencer SEVERE *** ERROR *** Problem invoking InstanceInfo on http://10.0.5.37/glide/: IOException: Connection refused

InstanceInfo If the error log displays an issue with InstanceInfo (as in the log sample in the previous section), navigate to System Web Services > Scripted Web Services and ensure that the InstanceInfo scripted Web Service is active. If this Web Service was disabled or modified incorrectly, the MID Server cannot get the information from the instance that it needs to connect.

Authentication Failure The user name and/or password configured in the MID Server config.xml file is incorrect or the user is incorrectly configured on the instance. 08/30/11 15:16:19 (531) MIDServer MID Server starting 08/30/11 15:16:19 (656) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml 08/30/11 15:16:20 (078) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent 08/30/11 15:16:20 (093) StartupSequencer Setting basic authentication with user swhipple 08/30/11 15:16:20 (187) MIDServer MID Server started 08/30/11 15:16:21 (031) StartupSequencer Successfully connected to instance: 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer 08/30/11 15:16:21 (031) StartupSequencer

Install name: Demo Server Instance name: demosw Node: 9b1a9ce90a0a3c1801834233f12ce49e Build date: 08-28-2011_2100 Build tag: Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b System ID: bosdemo01.service-now.com:demosw_16245

08/30/11 15:16:21 (031) StartupSequencer

Instance IP: 10.10.60.24

08/30/11 15:16:21 (031) StartupSequencer

MID version: 08-28-2011_1352

08/30/11 15:16:21 (296) StartupSequencer WARNING *** WARNING *** Could not authenticate user 'swhipple' on the ServiceNow instance

MID Server Installation

27

Missing Roles If the configured user is missing any roles, the message names the roles. The configured MID Server user must have the following roles. The hierarchy indicates which roles are contained within other roles. • soap_ecc • mid_server • soap • • • • •

soap_delete soap_query soap_update soap_create soap_script

If the configured user has the required roles, the message states User has all necessary roles. 08/30/11 15:22:23 (078) MIDServer MID Server starting 08/30/11 15:22:23 (203) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml 08/30/11 15:22:23 (578) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent 08/30/11 15:22:23 (593) StartupSequencer Setting basic authentication with user swhipple 08/30/11 15:22:23 (687) MIDServer MID Server started 08/30/11 15:22:24 (953) StartupSequencer Successfully connected to instance: 08/30/11 15:22:24 (953) StartupSequencer 08/30/11 15:22:24 (953) StartupSequencer

Install name: Demo Server Instance name: demosw

08/30/11 15:22:24 (953) StartupSequencer 08/30/11 15:22:24 (953) StartupSequencer 08/30/11 15:22:24 (953) StartupSequencer 08/30/11 15:22:24 (953) StartupSequencer 08/30/11 15:22:24 (953) StartupSequencer

Node: 9b1a9ce90a0a3c1801834233f12ce49e Build date: 08-28-2011_2100 Build tag: Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b System ID: bosdemo01.service-now.com:demosw_16245

08/30/11 15:22:24 (953) StartupSequencer

Instance IP: 10.10.60.24

08/30/11 15:22:24 (953) StartupSequencer

MID version: 08-28-2011_1352

08/30/11 15:22:25 (218) StartupSequencer SOAP basic authentication is enabled 08/30/11 15:22:25 (218) StartupSequencer SOAP strict security is enabled 08/30/11 15:22:25 (218) StartupSequencer WARNING *** WARNING *** Missing role from user swhipple: mid_server

ACL Issues If ACLs on the ServiceNow instance block the MID Server from accessing necessary tables or fields on the instance, the error message names the table or field that is blocked. In this example, read, create, and write privileges on the MID Server [ecc_agent] table are blocked by access control rules configuration. 08/30/11 14:02:50 (406) MIDServer MID Server starting 08/30/11 14:02:50 (531) MIDServer Using configuration: C:\Service-now\DocMIDServer01\agent\config.xml 08/30/11 14:02:50 (921) MIDServer Agent home path: C:\Service-now\DocMIDServer01\agent 08/30/11 14:02:50 (921) StartupSequencer Setting basic authentication with user swhipple 08/30/11 14:02:51 (015) MIDServer MID Server started 08/30/11 14:02:52 (062) StartupSequencer Successfully connected to instance: 08/30/11 14:02:52 (062) StartupSequencer 08/30/11 14:02:52 (062) StartupSequencer 08/30/11 14:02:52 (062) StartupSequencer 08/30/11 14:02:52 (062) StartupSequencer

Install name: Demo Server Instance name: demosw Node: 9b1a9ce90a0a3c1801834233f12ce49e Build date: 08-28-2011_2100

MID Server Installation 08/30/11 14:02:52 (062) StartupSequencer 08/30/11 14:02:52 (062) StartupSequencer 08/30/11 14:02:52 (062) StartupSequencer

28 Build tag: Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b System ID: bosdemo01.service-now.com:demosw_16245

08/30/11 14:02:52 (062) StartupSequencer

Instance IP: 10.10.60.24

08/30/11 14:02:52 (062) StartupSequencer

MID version: 08-28-2011_1352

08/30/11 14:02:52 (843) StartupSequencer SOAP basic authentication is enabled 08/30/11 14:02:52 (843) StartupSequencer SOAP strict security is enabled 08/30/11 14:02:52 (843) StartupSequencer User swhipple has all necessary roles 08/30/11 14:02:52 (859) File sync worker: ecc_agent_mib Starting file synchronization: ecc_agent_mib 08/30/11 14:02:52 (859) StartupSequencer Enabling monitor: FileSyncer 08/30/11 14:02:52 (859) File sync worker: ecc_agent_jar Starting file synchronization: ecc_agent_jar 08/30/11 14:02:53 (218) File sync worker: ecc_agent_mib Finishing file synchronization: ecc_agent_mib 08/30/11 14:02:53 (828) File sync worker: ecc_agent_jar Finishing file synchronization: ecc_agent_jar 08/30/11 14:02:54 (890) StartupSequencer Getting instance ACLs for table: ecc_agent_property 08/30/11 14:02:55 (875) StartupSequencer Getting instance ACLs for table: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer Agent record not found, creating new record.

Instance: DocMIDServer1

08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't write because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't create because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer SEVERE *** ERROR *** Unable to create new agent record on instance: DocMIDServer1 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent 08/30/11 14:02:56 (250) StartupSequencer WARNING *** WARNING *** Can't read because table ACL denies it: ecc_agent

References [1] http:/ / www. w3. org/ Protocols/ HTTP/ 1. 0/ draft-ietf-http-spec. html#BasicAA

Deploying Multiple MID Servers

Deploying Multiple MID Servers Overview Depending upon how you use the MID Server (for an external integration, Discovery, or Runbook Automation) and the load placed on it, you might find it necessary to deploy multiple MID Servers in your network. You can install each MID Server on a separate machine or install multiple MID Servers on a single machine (including virtual machines). For instructions on installing the MID Server on multiple machines, see MID Server Installation.

Integrations Factors determining the number of MID Servers your network will require to support external applications that integrate with ServiceNow include the following: • The security constraints in your network • The amount of traffic between ServiceNow and the integrations • The reliability of the MID Server machines.

Security Security policies in your network (firewalls between network segments, for example) might make direct communication impossible between your instance and an integration's data source (JDBC, LDAP, etc.). To retrieve data for the instance, you can install a MID Server that has access to both the data source and the instance.

Load balancing In some cases, a single MID Server can handle all the transactions that occur between an instance and an external integration. However, in a high volume environment, it might be necessary to deploy multiple MID Servers as load balancers for certain transactions. For example, JDBC data transfers can tie up the resources of a MID Server, making it unable to respond to other requests. The following operations between an integration might require separate MID Servers in a busy network: • • • •

File exports Running scripts JDBC data sources Reading files

High availability model Avoid installing MID Servers for critical integrations on a machine that might experience any type of planned outage or an outage caused by overloaded processes. If necessary for reliability, consider deploying these types of MID Servers to dedicated machines for high reliability. Warning: Do not integrate with an external application on a MID Server provisioned for ServiceNow Discovery or Runbook Automation.

29

Deploying Multiple MID Servers

Discovery When determining if you need multiple MID Servers to discover the configuration items in your network efficiently, the following factors must be considered: • WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth available between your local area networks.  In most cases, the best practice is to install a MID Server on each LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN connections that take advantage of fast Internet connections. If the bandwidth of your WAN connections is comparable to that of your Internet connection, then there is no performance impact in running MID Server probes across WAN connections. • DMZ: Your network policy might require you to install one or more MID Servers in your DMZ to probe the devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall. • High capacity: Deploy multiple MID Servers where capacity is an issue, as when Discovery has to gather information about thousands of configuration items quickly. • Security: If your security policy controls access to network devices (e.g. switches and routers) with an access control lists (ACL), it might be necessary to install one or more MID Servers on a machine in the network that is already on the ACL. • Probe types: If you are conducting probes of different operating systems, your network policy might require a separate MID Server for each type of probe (e.g., one MID server for Windows WMI probes and another for SSH probes on UNIX)

Runbook Automation When determining if multiple MID Servers are necessary to executes Runbook activities, consider the following factors: • WAN deployment: When determining where to deploy MID Servers in a WAN, consider the bandwidth available between your local area networks. In most cases, the best practice is to install a MID Server on each LAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WAN connections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPN connections that take advantage of fast Internet connections. If the bandwidth of the WAN connections is comparable to that of the Internet connection, then there is no performance impact in running MID Server probes across WAN connections. • DMZ: Network policy might require the installation of one or more MID Servers in the DMZ to probe the devices there. This is common in networks that tightly regulate the ports that are opened on the inside firewall. • Security: If a security policy controls access to computers with an access control lists (ACL), it might be necessary to install one or more MID Servers on a machine in the network that is already on the ACL. • Probe types: If Runbook launches probes for different operating systems, network policy might require a separate MID Server for each type of probe (e.g., one MID server for Windows PowerShell and another for SSH probes on UNIX).

30

MID Server Configuration

31

MID Server Configuration Overview You must complete all the steps in MID Server Installation before attempting any of the configuration steps explained here. Set MID Server configuration parameters in either of the following places: • The Configuration Parameters related list in the MID Server record. • The config.xml file in the \agent folder of your MID Server installation folder.

Setting MID Server Memory Size In the base ServiceNow system, the MID Server is configured with reasonable values for its resource consumption. This setting might not be appropriate for the way your organization uses the MID Server. If you want the MID Server to work harder, allocate more resources to it. Or perhaps the MID Server is located in a small branch office with very few devices, and runs in an environment where memory allocation is shared between a print server, mail server, or Web proxy server. In this situation, the MID Server memory allocation might have to be reduced. MID Server memory is set to 512MB by default and is configurable in the \agent\conf\wrapper.conf file in the MID Server installation directory. To edit the memory allocation: 1. 2. 3. 4. 5. 6. 7.

Navigate to \agent\conf and open the wrapper.conf file in a text editor. Locate the following lines in the file: # Maximum Java Heap Size (in MB) wrapper.java.maxmemory=512 Edit the memory allocation. Save the file. Restart the MID Server service.

Available Parameters Note: Changes to parameters only take effect when the MID server is started (or restarted).

Description

Name(s)

Details

Credentials provider

mid.credentials.provider

Debug logging enable

debug.logging

Optional, true/false, default false. If set to true, enables logging of MID server events and messages (both sent and received). Normally this parameter is only used by developers, but it is occasionally useful when troubleshooting a problem. Be aware that setting this parameter to true will cause intensive logging on the MID server, potentially using considerable disk space.

Debug logging level

debug.level

Optional, integer (0-3), default 0. Controls how much debug logging will take place (if debug mode is enabled): 0 = none, 1 = little, 2 = some, and 3 = all.

MID Server Configuration

32

Debug mode enable

debug

Optional, true/false, default false. If true, enables debug logging on the MID server. Normally this parameter is only used by developers, but it is occasionally useful when troubleshooting a problem. Be aware that setting this parameter to true will cause intensive logging on the MID server, potentially using considerable disk space.

Disable monitor checking

disable_monitors

Optional, true/false, default false. It true, disables MID Server from actively checking for monitors on the instance.

Enable automatic inclusion of SNMP public community string

mid.snmp.enable_auto_public

Optional, true/false, default true. To disable the SNMP public community string, set this parameter to false.

Enable PowerShell for Discovery

mid.use_powershell

Optional, true/false, default false. PowerShell must be installed on the MID Server and must be at Version 2 for PowerShell with Discovery to operate. If the correct version of PowerShell cannot be found, the MID Server uses WMIRunner instead.

Environment variable for SSH commands

mid.ssh.set_path

Optional, true/false, default true. Sets the PATH environment variable for SSH commands.

Execute long-running commands against localhost

mid.ssh.local

Optional, true/false, default false. If set to true, executes commands for the MID Server host machine (localhost) via SSH rather than from a console. This allows long-running commands to execute properly.

Fixed MID mid.pinned.version Server version

Optional, string build timestamp. Names the fixed version for the MID Server.

Instance date format

instance.date.format

Optional, string date/time pattern, default "yyyy-MM-dd HH:mm:ss". Set or change this parameter to let the MID server know what format the instance uses for date/times. The primary impact of setting this parameter is to allow the MID server to correctly refresh its start and stop times on the ServiceNow instance's MID server record. The format of this date/time string is identical to that used by the Java [1] SimpleDateFormat class, documented here in the section titled Date and Time Patterns.

Instance password

mid.instance.password or glide.glidesoap.password

Optional, string. If your ServiceNow instance has authentication enabled (the normal case), set this parameter to define the password the MID server should use to log into the instance.

Instance proxy enable

mid.instance.use_proxy or mid.proxy.use_proxy

Optional, true/false, default false. If your MID server must go through a web proxy to access the ServiceNow instance, set this parameter to true to instruct the MID server to use the proxy. Note that you must also set the proxy server's host and port, and perhaps the user name and password as well.

Instance proxy host

mid.proxy.host

Optional, string. If your MID server must go through a web proxy to access the ServiceNow instance, set this parameter to define the proxy's host.

Instance proxy password

mid.proxy.password

Optional, string. If your MID server must go through a web proxy to access the ServiceNow instance, and your proxy requires a password, set this parameter to define that password.

Instance proxy port

mid.proxy.port

Optional, integer (0 - 65535). If your MID server must go through a web proxy to access the ServiceNow instance, set this parameter to define the proxy's port.

Instance proxy user name

mid.proxy.username

Optional, string. If the MID Server must go through a web proxy to access the ServiceNow instance, and the proxy requires a user name, set this parameter to define that user name.

MID Server Configuration

33

Instance URL url

Required, string. Tells the MID server where to contact its associated ServiceNow instance. Normally this would be a URL like [2], where “example” would be replaced by the name of your instance. If your are hosting your own ServiceNow instance, then this URL will be determined by your organization.

Instance user name

mid.instance.username or glide.glidesoap.username

Optional, string. If your ServiceNow instance has authentication enabled (the normal case), set this parameter to define the user name the MID server should use to log into the instance.

MID Server auto-upgrade enable

auto_upgrade

Optional, true/false, default true. If true or absent, enables the MID server to periodically check whether it should upgrade. If it is set to false, the MID server will remain on the same version – generally neither safe or useful.

MID Server connection cache

mid.connection_cache

Optional, true/false, default true. By default this property causes connections to be cached. Set to false to disable connection caching. Used for ssh connections only (Discovery).

MID Server ECC query interval

query_backoff

Optional, true/false, default false. Allows the interval at which the MID Server queries the ECC Queue to lengthen if the MID Server is idle. By default, the MID Server queries the ECC Queue for work every 15 seconds. In a system that employs a large number of MID Servers, these queries can produce unnecessary traffic during periods of light MID Server activity. When the query_backoff parameter is set to true, the query interval slowly lengthens for an idle MID Server. Eventually, the interval slows to one query every four minutes and holds at that rate until the MID Server has a job to do. When the MID Server starts work again, the query interval for that MID Server immediately increases to once every 15 seconds and continues at that rate until the demand on the MID Server backs off again.

MID Server ID

mid_sys_id

Required, automatically set, string (GUID). Records the unique identifier of the MID server's record on the ServiceNow instance. This parameter should be empty when you initially configure a MID server, and you should never change it.

MID Server immediate response enable

glide.mid.fast.responses

Optional, true/false, default false. Normally the MID server sends message to the ServiceNow instance serially (that is, one message at a time). Setting this parameter to true instructs the MID server to try sending messages to the instance as soon as they are ready. In Discovery, when many probes can be run in parallel, this means that often there will be multiple messages being simultaneously transmitted to the instance. Setting this parameter to true may decrease the time between a probe's completion and its response arriving at the instance. However, the multiple simultaneous messages consume resources on the instance, decreasing the instance's overall responsiveness. If there are communications problems, this parameter can also cause a "logjam" on the MID server, as threads normally used for running probes may become consumed for sending messages. Overall we recommend leaving this parameter out of your configuration; it would take a very special circumstance for it to make sense to set it true.

MID Server JMX enable

mid.jmx.enabled

Optional, true/false, default false. If set to true, this parameter enables a JMX server on the MID server, exposing some management information to JMX consoles. This is an experimental feature, not officially released yet. Also, implementing JMX requires additional (and fairly complicated) configuration of the Java runtime environment. Setting this parameter to true is only recommended for those with detailed knowledge of the Java security architecture, a specific need for JMX, and a strong desire to take unreasonable risks with production software.

MID Server Configuration

34

MID Server max transmission queue size

glide.mid.max.sender.queue.size

Optional, string, default "0.5g". When the MID server generates messages to the ServiceNow instance faster than it can send them, it queues them temporarily on the file system of the MID server's host. This queue is normally quite small, and is completely emptied as soon as the MID server is quiescent for a short period. However, when there are communications problems between the MID server and the instance, and especially if there is an integration running on the MID server, this queue can grow in size. This parameter places an upper bound on how large the queue is allowed to get – the MID server will start deleting queued messages if this bound would be exceeded. The parameter is of the form {number}[{multiplier}], where {number} is any positive decimal number (including non-integers), and the optional multiplier is any spelling of "bytes", "kilobytes", "megabytes", "gigabytes", or "terabytes" (only the first character is tested, and the test is case-insensitive). The default multiplier is "bytes". Whitespace is liberally tolerated. The following strings all represent valid parameters: "1000000000", "0.5m", "5 GB", "7.67gigas", "145.69392 mothers", and "1.1 tomatoes".

MID Server maximum number of probe threads

threads.max

Optional, integer, default 25. Controls the number of execution threads (simultaneous work) that may be used by probes. This parameter provides direct control over how much CPU resource the MID server will consume on the computer that hosts it. To throttle the MID server's CPU consumption down, lower the number of threads. To make the MID server work faster, increase the number of threads.

MID Server name

name

Required, string, default is YOUR_MIDSERVER_NAME_GOES_HERE If you do not supply this parameter, the MID server will use the default value. Use this parameter to supply a name that's meaningful for you.

MID Server poll time

mid.poll.time

Optional, integer, default 15. Allows you to override the default MID Server polling interval (in seconds).

MID Server refresh rate

MIDServerRefreshRate

Optional, integer, default 65. Controls how often (in seconds) the MID server checks with the instance to determine if the MID Server should upgrade itself. The usual value for this parameter is 65 seconds. To change this value, add the parameter to the MID Server config.xml file, using the following syntax:

MID Server SSH connection per host

mid.ssh_connections_per_host

Optional, integer, default 3. Controls the number of concurrent probes the MID Server can run against a given host. Lowering the number of concurrent connections can slow Discovery.

MSSQL mid.powershell.use_mssqlauth credentials for PowerShell

Optional, true/false, default false. This parameter determines whether PowerShell should use Windows integrated security or SQL authentication when attempting to log into the MSSQL instance. PowerShell uses Windows integrated security by default.

Port probe packet interval

mid.shazzam.regulator.interval_ms

Optional, integer, default 1. Sets the interval, in milliseconds, in which Shazzam can launch packets. This parameter works with the mid.shazzam.regulator.packets_per_interval parameter to set the number of packets allowed in this interval. By default, Shazzam launches one packet each millisecond.

Port probe packets launched per regulator interval

mid.shazzam.regulator.packets_per_interval Optional, integer, default 1. Sets the number of packets that Shazzam can launch in the configured time interval. This parameter works with the mid.shazzam.regulator.interval_ms parameter, which sets that interval. By default, Shazzam launches one packet each millisecond.

PowerShell credentials

mid.powershell.use_credentials

Optional, true/false, default true. This parameter tells Discovery to use the Windows credentials in the credentials table for PowerShell. To use PowerShell Discovery on a single domain, set this parameter to false, and then restart the MID Server. In this case, the MID Server runs the probes with the credentials of the user for the MID Server process.

MID Server Configuration

PowerShell executable path

mid.powershell.path

35 Optional, string URL. This parameter enables an administrator to point to a specific PowerShell on a MID Server in cases where more than one PowerShell is installed. Supply the path (e.g. C:\mypowershell or C:\mypowershell\) to the folder containing the PowerShell executable, and powershell.exe is appended automatically to the URL. This parameter might be necessary, for example, when 32 bit and 64 bit PowerShells are active on the same MID Server, and it becomes necessary to launch the correct PowerShell for the context. Note that 64-bit Windows employs file system redirection and the MID server runs as a 32-bit application. If trying to specify a path in %WinDir%\System32, Windows will automatically redirect to %WinDir%\SysWOW64. To avoid redirection, specify the path as %WinDir%\Sysnative. An example would be instead of "C:\WINDOWS\system32\WindowsPowerShell\v1.0\", specify "C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\".

Query logging mid.show.queries enable

Optional, true/false, default false. Setting this parameter to true instructs the MID server to log details about every query it makes to the ServiceNow instance. Normally this parameter is only used by developers, but it is occasionally useful when troubleshooting a problem. Be aware that setting this parameter to true will cause intensive logging on the MID server, potentially using considerable disk space.

Remote logging disable

Optional, true/false, default false. If this parameter is set to true, the MID server will not log any information to the MID server log on the ServiceNow instance. Relatively little information is logged on the instance in any case, but setting this parameter will cut that to zero.

disable.remote.logging

Set the PATH mid.ssh.path_override environment paths for SSH commands

Optional, string. Configure an alternate SSH command path with this parameter to override the possible default paths (/usr/sbin: /usr/bin: /bin: /sbin). This MID Server parameter is overridden if an alternate SSH command path is configured in a probe parameter.

Shazzam chunk size

mid.shazzam.chunk_size

Optional, integer, default 100. The maximum number of IP addresses that Shazzam scans in parallel. This parameter primarily controls outbound port consumption.

SSH connection error retry

mid.ssh_max_retries

Optional, integer, default 1. The maximum amount of times to retry an SSH operation after a time-out. The system sleeps two seconds between each connection attempt. By default, the MID Server retries once only. Use the mid.ssh.max_retries parameter setting to override that default. Set the parameter to 0 to disable retries.

SSH remove command override

mid.ssh.alt_rm

Optional, string, default /bin/rm -f. Sets a different SSH remove file command.

Status sending disable.status disable

Optional, true/false, default false. Normally the MID server sends a status report to the ServiceNow instance every 10 minutes. Setting this parameter to true will eliminate that report.

Suppress mid.ssh.suppress_history history file generation for SSH

Optional, true/false, default false. Suppress generation of the SSH history file.

Timeout in ms for SSH socket open

mid.ssh.socket_timeout

Optional, integer, default 60,000. Some devices (such as systems with embedded controllers, like UPSs and PDUs) with SSH enabled require more than 30 seconds to respond to an authentication request. To prevent issues created by a socket timeout, this parameter provides a way to set a higher value.

Upgrade branch

glide.mid.autoupgrade.branch or mid.upgrade.branch

Optional, string. Defines a branch (a directory on the distribution server) from which the MID server should download its upgrades from. This might be set if you had a special MID server version for some reason. Normally you should not have this parameter in your configuration, and you should never include it without consulting with ServiceNow.

MID Server Configuration

36

Upgrade proxy enable

mid.upgrade.use_proxy

Optional, true/false, default false. If your MID server must go through a web proxy to access the upgrade URL, set this parameter to true to instruct the MID server to use the proxy. Note that you must also set the proxy server's host and port. Note that if the instance proxy user name and password are set, they will be used for the upgrade proxy as well.

Upgrade proxy host

glide.mid.autoupgrade.proxy_host or glide.glidesoap.proxy_host

Optional, string. If your MID server must go through a web proxy to access the upgrade URL, define the proxy's host here.

Upgrade proxy port

glide.mid.autoupgrade.proxy_port or glide.glidesoap.proxy_port

Optional, integer (0 - 65535). If your MID server must go through a web proxy to access the upgrade URL, define the proxy's port here.

Upgrade proxy user

glide.mid.autoupgrade.proxy_user

Optional, string. If your MID server must go through a web proxy to access the upgrade URL, define the proxy's user name here.

Upgrade proxy password

glide.mid.autoupgrade.proxy_password

Optional, string. If your MID server must go through a web proxy to access the upgrade URL, define the proxy's password here.

Upgrade URL glide.mid.autoupgrade.host

Optional, string URL, default. [3] Controls where the MID server will download its upgrades from. Normally you should not set this parameter.

Use keyboard mid.ssh.use_keyboard_interactive interactive authentication for SSH

Optional, true/false, default false. Uses the keyboard interactive authentication mode in SSH daemons for MID Servers on which it is activated.

Managing Configuration from the ServiceNow Instance You can view and manage your MID server's configuration from the ServiceNow instance. 1. Navigate to the list of MID Servers using one of the following paths: • MID Server > Servers • Discovery > MID Servers • Runbook Automation > MID Servers 2. From the list of MID servers shown, select the one to configure. The Configuration Parameters Related List shows all the parameters currently in the MID server's configuration file. If there are any passwords, they are displayed in asterisks for security reasons.

3. To add parameters, click New, and then complete the form. After the form is submitted, the MID server's configuration file is modified to include the new parameter. Changes to existing parameters are reflected in the MID server's configuration file as well. Changes made to the MID server's configuration file do not take place immediately, but rather the next time the MID server is restarted. The MID server page has a convenient link to use to restart the MID server at any time.

MID Server Configuration

Note: No changes can be made (such as modifying or deleting parameters) that would make the MID server lose communications with the instance. For example, the url property cannot be changed for this reason. Any changes to these protected properties must be made by directly editing the MID server's config.xml file.

Editing the config.xml File The MID Server's configuration is controlled by an XML file called config.xml. This file is located in the agent directory, immediately under the directory in which the MID Server was installed. Edit this file directly to make any configuration changes. Many configuration changes (those that do not disrupt communication between the MID Server and the ServiceNow instance) may also be made from the instance. The sample file here is from FireFox. Conventional text editors, such as Notepad, Wordpad, or TextEdit, do not display colors and variable fonts. The structure of the config.xml file is simply an outer parameters tag and a series of inner parameter tags. Each parameter tag has name and value attributes. The name attribute contains the name of each parameter, and the value attribute contains the value of the parameter. To change the value of a parameter, edit the value attribute. To add a parameter, add another parameter tag with its name and value. To delete a parameter, delete the entire parameter tag. The order of the parameters within the file is not important. Note the green comment sections in the sample. Use these elements to add useful comments to the configuration file. Note: When configuring the MID Server for use with a proxy server, be sure to remove the comment tags around the proxy sections that you configure.

37

MID Server Configuration

Configuring Thread Use By default, the MID Server is configured to use a maximum of 25 threads. For most CPUs, this requires little effort. However, if the MID Server is running on a host containing many other programs that must compete for CPU time, fewer threads than the default of 25 might be necessary. You can set the MID Server to use as few as 5 threads without issues. If the MID Server needs more speed, and the host is powerful enough (or lightly loaded with other programs), raise the thread setting. The thread limit depends very much on the hardware and the operating system of the host. You might have to experiment to find the optimal value for your situation. The following general observations are useful: • Most MID Server tasks require file handles to do their job. On the Windows operating system, file handles are a rather precious resource available in a fixed quantity. If you configure too many MID Server threads on a Windows host, the MID Server can consume all the file handles before approaching maximum CPU usage. This situation appears as an Out of file handles error in the MID Server log and indicates that the MID Server is trying to use too many threads. UNIX and Linux hosts have a much different scheme for allocating file handles. Generally, you can increase MID Server thread use on these operating systems until the CPU of the host is overloaded. • Each thread on the MID Server requires some memory. Exactly how much memory varies considerably from task to task and is also dependent on the equipment being discovered. To increase the number of threads, you might have to increase the amount of memory that Java uses. If you configure insufficient memory, an Out of memory error appears in the MID Server log. To edit the maximum number of threads allowed for the MID Server: 1. Open the \agent\config.xml file using any text editor. 2. Locate the following lines: 3. Edit the value, with consideration to the cautions described above. 4. Save the record. 5. Restart the MID Server service.

Adding SSL Certificates You can configure your MID server to connect over SSL by adding the following certificates to the cacerts keystore file: • Signing Certificate Authority (CA) certificate • MID Server certificate To add a certificate to a MID server: 1. Open a Command Prompt and navigate to the folder containing your JRE's keytool [4]. For example: cd C:\Program Files (x86)\ServiceNow\\agent\jre\bin 2. Enter the following keytool command to import a certificate into the MID server's cacerts keystore: keytool -import -alias -file "" -keystore "\agent\jre\lib\security\cacerts" For example: keytool -import -alias MyCA -file "C:\myca.cer" -keystore "C:\Program Files (x86)\ServiceNow\MIDserver\agent\jre\lib\security\cacerts"

38

MID Server Configuration

Note: Keytool prompts for a certificate password and, if the certificate is for a CA, whether to trust the certificate authority.

The mid_server Role The existing mid_server role was added to the ACLs, allowing the MID Server to access protected tables when strict SOAP security is in place. Add this role to the MID Server user for any instance on which basic authentication is enabled. The necessary soap roles are added automatically with the mid_server role.

Windows Enhanced Security and PowerShell Enhanced security on Windows operating systems can block PowerShell from working with Discovery and Runbook. If PowerShell does not run with Discovery or Runbook Automation, unblock the following MID Server files. • • • • • • •

Credentials.psm1 LaunchProc.psm1 MSSqlAuth.ps1 MSSqlWinAuth.ps1 PSScript.ps1 WMIFetch.psm1 XmlUtil.psm1

Perform this procedure on each MID Server machine: 1. Navigate to the MID Server \agent\lib folder. 2. Right-click on the first file in the list and select Properties from the pop-up menu.

39

MID Server Configuration

40

3. In the Properties dialog box, click Unblock. 4. Repeat the procedure for each of the remaining files.

References [1] [2] [3] [4]

http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ text/ SimpleDateFormat. html https:/ / example. service-now. com http:/ / install. service-now. com/ glide/ distribution/ builds/ mid/ http:/ / docs. oracle. com/ javase/ 1. 3/ docs/ tooldocs/ win32/ keytool. html

MID Server Clusters Overview MID Server clusters enable multiple MID Servers with the appropriate capabilities to be grouped together for load balancing and fail-over protection. A MID Server can be added to both a load balancing cluster and a fail-over cluster for more flexibility. MID Server clusters are available for Discovery, Runbook Automation, and use with products integrating with ServiceNow.

MID Server Cluster Event The following event is triggered when the platform cannot find a MID Server with the appropriate capabilities to replace a MID Server in a fail-over cluster. Use this event to create an email to notify appropriate users that the cluster has failed. Event

Table

Description

Business Rule

mid_server.cluster.down MID Server Cluster [ecc_agent_cluster] A MID server cluster has failed MID Server Cluster Management

MID Server Clusters

How Clusters Work MID Servers in clusters must be able to connect to the all the devices with which they are expected to communicate. Make sure all the MID Servers are added to any Access Control List (ACL) in use. MID Server clusters are managed by a business rule called MID Server Cluster Management, which checks to see if the MID Server assigned to a job in the ECC Queue belongs to a cluster.

Load Balancing If the cluster business rule determines that a MID Server is part of a load balancing cluster, the application using the MID Server automatically balances the work between the MID Servers in that cluster. It is best practice to put MID Servers with the same capabilities in a load balancing cluster.

Fail-Over Protection MID Servers in a fail-over cluster each have a configured order that the platform uses to determine which MID Server to use next in case of failure. MID Servers in a fail-over cluster work independently and do not load balance with other MID Servers in that cluster (although they might also be members of load balancing clusters). When a MID Server fails, the MID Server Cluster Management business rule selects the highest available MID Server in the order to take over the work. The selected MID Server checks the ECC Queue and starts with jobs that are either Processing or Ready. It is best practice to configure a fail-over MID Server with at least the same capabilities as the MID Server it is intended to relieve.

Combining Clusters A MID Server can be a added to both types of clusters at the same time. This diagram shows a scenario in which a MID Server from a load balancing cluster (MID Server D) is also present in a failover cluster.

If MID Server D fails, MID Server E in the failover cluster is available to the load balancing cluster to perform the tasks previously assigned to MID Server D.

Configuring a Cluster 1. 2. 3. 4. 5. 6.

Navigate to MID Server > Clusters. Click New. Name the cluster and select the cluster type: Failover or Load Balance. Right click in the header bar and select Save from the context menu. Click Edit in the Includes MID Servers Related List. Select appropriate MID Servers for this cluster from the slushbucket. Note: All MID Servers in a cluster must have capabilities defined. Ensure that each MID Server has the appropriate capabilities for the job. A MID Server in a failover cluster must have the same capabilities (or expanded capabilities) as the MID Server it is expected to replace.

41

MID Server Clusters

Controlling the MID Server Version Overview ServiceNow MID Servers are configured to check the instance for the correct MID Server version once every hour. If the version has changed since the last check-in, the MID Server upgrades or downgrades itself accordingly. An administrator might want to edit the MID Server version to enable a new feature or get a fix for a defect. There are two properties that control how and when the MID Server can change its version: • mid.version • mid.version.override Note: Downgrades are only possible within the same release family. For example, you can downgrade from Berlin Patch 3 to Berlin Patch 2, but not from Berlin to Aspen.

Enhancements Aspen Release The MID Server: • Upgrades automatically when the instance is upgraded. • Tests connectivity through a public scripted web service.

Berlin Release • The MID Server property, mid_buildstamp, replaces the mid.version property in versions at or later than Berlin. The mid.buildstamp property identifies the MID Server version with an identifier based on the date of the build. This property uses a date and time format of yyyy-mm-dd-hhmm. • The date and time format for the mid.version.override property has changed yyyy-mm-dd-hhmm.

mid.version The mid.version property provides the current version of the MID Server (the version determined by ServiceNow to be correct for the current application version) and is configurable. The MID Server checks for version information hourly. If no override version is configured, the MID Server looks at the mid.version property for the version to use. This property resets itself to the default version (the version that matches your instance version) when the instance is restarted or upgraded, so any user changes are lost at that time.

42

Controlling the MID Server Version

mid.version.override Use this property to set an override condition for the current MID Server version. When the MID Server checks the version each hour, it looks at the mid.version.override property first. If this property is empty, the MID Server will get its version information from the mid.version property. If an override version is configured, the MID Server uses this value and ignores the version information in the mid.version property. This override value remains when the instance is restarted and is passed to the MID Server at check in. However, the version in the mid.version.override property is deleted during an upgrade, allowing the MID Server to reset itself to the version in the mid.version property. Create the property and then set the value. 1. In the Navigation pane filter, type sys_properties.list. 2. 3. 4. 5.

The list of system properties appears. Click New. Type mid.version.override in the Name field. Enter a description, such as, Set an override value for the current MID Server version. Enter a version for the MID Server to use that is different from the version ServiceNow has selected in the mid.version property.

6. Click Submit.

MID Server Heartbeat Overview The ServiceNow platform checks the MID Server for a response every 5 minutes, using a synthetic transaction monitoring system. When the MID Server changes status ( from Up → Down or from Down → Up), a system event is triggered which can be used for script actions or to send notifications.

Checking for a Heartbeat ServiceNow instances send a synthetic transaction via the Heartbeat probe to every MID server every 5 minutes. The Heartbeat probe functions exactly as a normal probe does and is sent by writing an output record to the ECC queue. A MID Server retrieves the record when it queries the ECC queue for work. The MID Server processes the probe just as it would any other probe and responds back to the instance. If the instance does not detect a response from a MID Server, the instance marks that MID Server as Down. If the MID Server responds, the instance considers the MID Server to be Up.

43

MID Server Heartbeat

System Events When a MID Server transitions from one state to another, one of these events is triggered: • mid_server.up: The MID Server goes from a status of Down to a status of Up. • mid_server.down: The MID Server goes from a status of Up to a status of Down.

Scheduled Job To change the trigger interval for the Heartbeat probe, navigate to System Scheduler > Scheduled Jobs > Scheduled Jobs. Open the MID Server Monitor record and edit the interval.

44

MID Server User Security

MID Server User Security Overview The strict SOAP security feature, enabled by default for any instance that uses basic authentication, protects all tables with Access Control Lists (ACL). The tables that the ServiceNow MID Server must access are protected by these ACLs and are unavailable to the MID Server unless the MID Server user has specific roles.

The mid_server Role The existing mid_server role was added to the ACLs, allowing the MID Server to access protected tables when strict SOAP security is in place. Add this role to the MID Server user for any instance on which basic authentication is enabled. The necessary soap roles are added automatically with the mid_server role.

45

46

Probes and Sensors Shazzam Probe Parameters Overview When you run Discovery, the Shazzam probe (Scan mode) finds all active devices in your network by scanning specified ports on specified IP address ranges. You control the behavior of the Shazzam probe using two types of parameters: Basic and Advanced. To access the Shazzam probe, navigate to Discovery Definition > Probes and select Shazzam. Add or edit parameters in the Probe Parameters related list.

Basic Parameters These parameters are defined in the config.xml file on the MID Server, but you can edit these values in the Shazzam probe record as well. Changes to specific parameters that could disconnect you from the MID Server are prohibited in the probe record and can only be made in the configuration file. Parameter

shazzam_chunk_size

Description

The maximum number of IP addresses Shazzam will scan in parallel. This parameter primarily controls outbound port consumption.

Default Value 100

regulator_max_packets The maximum number of packets allowed per regulator period.

1

regulator_period_ms

1

The number of milliseconds per regulator period.

Advanced Parameters These parameters are available for fine tuning your Shazzam probe. You define these values in the probe record only. Parameter

Description

Default Value

report_inactive

If set to true, reports device as alive but inactive (e.g. no ports are open, but at least one was refused).

true

report_dead

If set to true, reports dead IP addresses (e.g., all ports are closed).

false

GenericTCP_waitForConnectMS Sets the number of milliseconds for the GenericTCP scanner to wait for a connection.

1000

BannerTCP_waitForConnectMS

Sets the number of milliseconds for the BannerTCP scanner to wait for a connection and banner. 1500

HTTP_waitForConnectMS

Sets the number of milliseconds for the HTTP scanner to wait for a connection.

500

HTTP_waitForResponseMS

Sets the number of milliseconds for the HTTP scanner to wait for a response.

500

NBT_waitForResponseMS

Sets the number of milliseconds for the NBT scanner to wait for a response.

500

NBT_alternativePort

Defines an alternative port number for the NBT scanner.

N/A

SNMP_taps

Sets the number of taps (requests) for the SNMP scanner to attempt.

2

SNMP_tapIntervalMS

Sets the number of milliseconds for the SNMP scanner to wait between taps.

1000

Shazzam Probe Parameters

47

SNMP_waitForResponseMS

Sets the number of milliseconds for the SNMP scanner to wait for a response after the last tap.

1000

SNMP_alternativePort

Defines the alternative port number for the SNMP scanner.

N/A

DNS_waitForResponseMS

Sets the number of milliseconds for the DNS scanner to wait for a response.

1000

DNS_alternativePort

Sets an alternative port number for the DNS scanner.

N/A

debug

Set to true to enable debug logging.

false

scanner_log

Set to true to enable scanner logging (this logging information appears in the Shazzam probe response).

false

Port Probes Overview Port probes are used in Discovery by the Shazzam probe to detect protocol activity on open ports on devices it encounters. When a port probe encounters a protocol in use, the Shazzam sensor checks the port probe record to determine which classification probe to launch. The common protocols SSH, WMI, and SNMP in the out-of-box system have priority numbers that control the order in which they are launched. The WMI probe is always launched first, and if it is successful on a device, no other port probes are launched for that device. If the WMI probe is not successful, then the SSH probe gathers information on the device. The SNMP probe is always the last to scan, after the other port probes have failed. This method allows Discovery to classify a device correctly if the device is running more than one protocol (e.g. SSH and SNMP).

Port Probe Form To access the Port Probe form, navigate to Discovery Definition > Port Probes. An out-of-box port probe record looks like this:

The Port Probe form provides the following fields:

Port Probes

48

Field

Input Value

Name

Simple name for the port probe that reflects its function (e.g. snmp).

Description

Definition of the acronym for the protocol. (e.g. ssh is Secure Shell Login).

Scanner

Shazzam techniques for exploring a port. Some of these are protocol specific, and others are generic. For example, a WMI port probe will use a Scanner value of Generic TCP, and the snmp port probe uses a value of SNMP.

Conditional

Runs this port probe if any one of the non-conditional probes return an open port. The conditional port probes in the out-of-box system attempt to resolve the names of Windows devices and DNS names. These ports probes take additional resources and are not used unless activity is detected on open ports.

CIs

Indicates whether this port probe is enabled or disabled for discovering "Configuration Items".

IPs

Indicates whether this port probe is enabled or disabled for discovering "IP addresses".

Active

Indicates whether this port probe is enabled or disabled.

Triggered by services

Indicates which services define the port usage. Use this setting to define non-standard port usage and pair the port number with the protocol.

Triggers probe

Indicates which probe is triggered by the results of this port probe. This is the name of the appropriate classify probe.

Use classification

Names the appropriate classification table, based on the protocol being explored.

Classification priority

Establishes the priority in which this port probes must be run. If the first port probe fails, then the next probe runs on the device, and so forth, until the correct data is returned. This allows for the proper classification of a device that has two running protocols, such as SSH and SNMP. The default priorities for the Discovery protocols are: • • •

1 - WMI 2 - SSH 3 - SNMP.

Database Catalogs

49

Database Catalogs Overview In ServiceNow, the Database Catalog lists all the catalog objects, or databases, discovered for an instance of a database. For example, the ServiceNow catalog view of a single instance of Microsoft SQL Server might contain several dozen catalogs, each of which contains SQL Server tables. In the base platform, ServiceNow enables administrators to populate catalog views of common database products such as Oracle, MySQL, and SQL Server, and provides a Discovery probe and sensor for creating Microsoft SQL Server catalog views and for updating those catalogs in the CMDB. Note: Different database manufacturers use the term catalog differently. For example, MySQL uses database to mean catalog.

Viewing Database Catalogs To view a database catalog, navigate to Configuration > Database Catalogs and select a database.

A list of all the catalogs in the database appears.

An example of a database catalog is the Microsoft SQL Server catalog on the sandb01 server, which is populated in the CMDB automatically by a default probe called Windows - Get SQL Information. Click the link in the Database Instance column to view the CI for the selected SQL Server database. The list of catalogs for that database is included in the MSFT SQL Catalogs related list.

Database Catalogs

Generating Catalogs Database catalogs can be imported into ServiceNow from a third-party discovery tool, entered into the platform manually, or discovered by ServiceNow Discovery. The Windows - Get SQL Information probe is configured to populate the MSSQL Database Catalog in the CMDB. To generate catalog data for other databases with Discovery, create probes and sensors for those databases. See Discovery Probes and Sensors for instructions. To use Discovery to generate database catalogs, install the Discovery Plugin.

50

Custom Probe - Text File

Custom Probe - Text File Overview This custom Discovery probe will help you if you need to read a text file from a Windows computer and populate a CI in the CMDB with the values from the file. In this example the user wanted to read files created by BGinfo. Note: When you have completed the probe and sensor, place the probe in the appropriate Windows classifier at Discovery Definition > CI Classification > Windows.

Creating a New Probe 1. Navigate to Discovery Definition > Probes, and then click New. 2. Complete the following fields:

3. 4. 5. 6.

• Name: Unique and descriptive name for the probe • Probe type: Select Probe. • Description: Describe the function of this probe. • Used by Discovery: Select this check box • ECC queue topic: This is name of the probe the MID server is to run. In this example, we use WMIRunner. • ECC queue name: In this example, we use the descriptive name WMI: BGInfo files. Right-click in the header bar and select Save from the context menu. Select the Probe Parameters tab in the Probe form, and then click New. Enter WMI_GetFiles.js as the Name of this parameter. Copy the script below into the Script field and edit as needed.

7. Click Submit. The completed probe form looks like this:

51

Custom Probe - Text File

// // Use ServiceNow WMIAPI to gather stats // var CMD_RETRIES = 3; var scanner = getScanner(); if (scanner) { var output = ""; for(var i = 0; i < CMD_RETRIES; i++) { output = scanner.winExec("%SystemRoot%\\system32\\cmd.exe /C type \\\"C:\\Information Systems\\BgInfo\\*.txt\\\""); if (output) break; } scanner.appendToRoot("output", output); }

Creating a Sensor 1. Navigate to Discovery Definition > Probes, and then click New. 2. Complete the following fields: • Name: Use the same name as the matching probe. In this example, we use Windows - Get BGInofo files. • Reacts to probe: The name of the probe created in the previous procedure: Windows - Get BGInofo files • Sensor type: Select the type of sensor to create - in this example Sensor. • Description: Describes the function of this sensor. • Script: Copy the script below into the Script field and edit as needed. • Sensor type: Determines how the answer from the probe is processed - in this example Javascript. 3. Click Submit. // // Sensor Script text

52

Custom Probe - Text File //

new DiscoverySensor({ data: {}, process: function(result) { this.parseOutput(result.output); this.update(this.data); }, parseOutput: function(output) { var currentFile; var files = {}; if (output.startsWith("