servicenow discovery in detail

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

DiscoveryServiceNow

1Introduction

Getting Started

OverviewDiscovery uses conventional techniques and technology to extract information from computers and other devices. Ituses 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 andthen 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 todetermine 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, andso on.For each type of device, Discovery uses different kinds of probes to extract more information about the computer ordevice, 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 InformationThe information that Discovery gathers about devices can be used to update the Configuration ManagementDatabase (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 takecertain actions when device matches are made or not made. There are three possible result states that Discoveryrecognizes: 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 2

Discovery ArchitectureServiceNow is normally hosted in ServiceNow's data center, and it does not have the ability to access the enterprise'snetwork but Discovery needs access to do its job. Many enterprises have multiple networks, often separated byslow 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 hascomputers 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 iscontrollable). The MID server's job during Discovery is simply to execute probes and return the results back to theServiceNow instance for processing; it does not retain any information. In effect, a MID server is a remote extensionof the ServiceNow instance, on an enterprise network.MID servers communicate with the ServiceNow instance they are associated with by a simple model: they query theinstance for probes to run, and they post the results of probes they've completed back to the instance. There, the datacollected by the probes is processed by sensors, which decide how to proceed. The MID server starts allcommunications, using SOAP on HTTPS which means that all communications are secure, and allcommunications 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 ordevice to be discovered. The MID server uses several techniques to probe devices without using agents. Forexample, 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 SystemsDiscovery 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 DeskHelp 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 byrunning a script on that computer. Discovery does many things that Help the Help Desk can not do. Here's acomparison of the two:

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

OverviewWhat 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 andhave been around for years. In fact, some are over 10 years old. (e.g., SSH - Secure Shell on UNIX).

The Census AgentDiscovery is like the United States Census - the government headcount that sends census agents to your door togather information about your household - such as how many people live there and whether you have been tocollege. The census agents report their findings back to the government, who puts all the data into a database. Thatsexactly 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 youraddress, but when he arrives, he needs some kind of identification or badge, so that you will talk to him. In theInternet world, this identification is known as credentials. Access to computers is normally granted to you if youhave 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 doesnt 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 4

device is online and communicating with other devices, it usually does this using a protocol called TCP/IP (or justTCP for short). TCP uses ports to establish a connection and communicate. For example, Web sites usually run onport 80. When you type in www.google.com, you're connecting to that address via port 80. Using this example, if wescan a device's ports and determine that it is listening on port 80, we can assume that it's running a Web server/Website. 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 deviceis listening on port 22, the odds are pretty good that it's a UNIX or Linux machine. We use the same approach forWindows, which listens on port 135.Once we've determined the operating system, we can talk the talk and communicate with the device using its ownnative language.For UNIX we use SSH (Secure Shell), and for Windows we use WMI(Windows Management Instrumentation). For other devices likeNetgear (routers and switches) and printers, we use SNMP. So now weknow what kind of operating system the device has, and we know whatlanguage to speak. Now we need to ask it some questions. The censusagent would probably ask questions like How many kids do youhave?" or "How much money do you make? The MID Server needs toask questions like What version of Windows are you running?", "Howmuch RAM do you have?", and "How fast are you? The MID Serverask these questions with probes. When a MID Server runs a probe, it'sbasically asking a question. Asking the question is only half of the work, however. The other half is writing it downor translating it into terms that ServiceNow can understand. We do this by using sensors. The sensor is the part of theprocess that analyzes and records the data. The probe's job is simply to ask the questions and pass the informationalong to the sensor, which properly translates the response.

Probing the NeighborhoodLet'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 sensorwould work out of the census office. The MID Server is out in the network (neighborhood) using probes (censusagents) 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 moreinformation and makes the MID Server run more probes. For example, if the MID Server tells the sensor the deviceis running a Web server, then the sensor is going to tell the MID Server to go back to that IP address and run a probeto ask the device what Websites it hosts.The following diagram demonstrates the conversation between the MID Server and the sensor.


Hopefully, you have a basic understanding of Discovery by now. To recap, we'll go over the fundamentals ofDiscovery, 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 SecretsThe 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 Discoveryis enabled. You also have a MID Server somewhere in your network that you think is communicating with yourinstance. We'll do a Discovery on a single device.

MID Server Preparation1. 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.


Discovery HappensOnce 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.

The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linuxmachine.

3. The MID Server advises the instance of what it has discovered.4. The sensor creates the Get Operating System probe and delivers it when the MID Server checks in for jobs again.5. The MID server probes the Linux machine to determine its operating system.6. When the machine replies Linux, the MID Server passes this information to the sensor.7. 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.8. 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 dowith this information? Chances are, you already know about many of the devices that Discovery finds in yournetwork. Most of the computers, routers, printers, and so forth that you have in your Configuration ManagementDatabase (CMDB) will show up every time you run Discovery. Then there are those devices that you don't knowabout yet - devices recently added to the network perhaps - that are not in your CMDB. Well, it makes sense that youshould add those new devices to your database, and it also makes sense to update existing devices, particularly ifsomeone has installed new memory, new software, or added a disk drive. Discovery can do these thingsautomatically.Discovery can launch probes that return identity data from the devices it finds. Discovery then feeds that informationinto a handy tool called an Identifier that searches the CMDB for a matching device. If the Identifier determines thatServiceNow already has a record of the device, the Identifier can tell Discovery to launch more probes and updatethe existing record. If the Identifier cannot find a matching device in the database, it can tell Discovery to continueexploring and then create a new record in the database. If you don't want these automatic updates for any reason, youcan 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'velearned that we can use the information returned to update our Configuration Management Database automatically.

Discovery Agentless Architecture 7

Discovery Agentless Architecture

OverviewThis page describes the architecture for ServiceNow's Agentless Discovery. The two important parts we will coverare Communications and Data Collection and Processing. Communication is how your ServiceNow instance talksto the MID Servers and how the MID Servers talk to your devices. Data Collection and Processing is how we scanyour 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 installedon the local internal network (intranet). All communications between the MID Server and the ServiceNow instanceis done via SOAP over HTTPS (Secure HTTP - blue lines). Since we use the highly secure and common protocolHTTPS, the MID Server can connect to the instance directly without having to open any additional ports on thefirewall. 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)

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 hearthe term "Probes and Sensors" you can think of "Data Collection and Processing". The purple lines represent theMID Server probing for information. The MID Server then passes the results of each probe to the ServiceNowinstance via SOAP/HTTPS (green lines). Sensors (red box) within the ServiceNow instance process the informationgathered and update the CMDB.

9Discovery Tasks

Setting up Discovery

OverviewDiscovery can run on a regular, configurable schedule or can be launched manually. Whenever a Discovery runs, itruns over a specified IP address range which tells the Discovery process which specific devices to investigate. Toretrieve useful information, Discovery needs credentials (usually a user name and password pair) for devices withina particular range so that Discovery can connect to and run various probes on the devices it finds. Discoverycompares the devices it finds with configuration items (CI) in the CMDB and updates any matching devices. IfDiscovery 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 inwhich 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 OracleInstance form (Configuration > Database Instances > Oracle) with the discovered instance name.

Oracle listener

Setting up Discovery 10

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, triggeredprobes.

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 uninstallsoftware detected on Windows operating systems.

Ports added to process applications: Discovery now uses the process identifier (PID) of any application classifiedas a process to discover the listening ports used by that process. With this release the TCP port field in theprocess form is automatically populated with one or more ports. In previous versions, this field was populatedmanually.


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

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

Aspen Patch 3The localhost MID Server, which was used as the default MID Server in Discovery Schedules, was removed fromthe platform. The localhost MID Server originally was intended for demonstration purposes and was not intended tobe 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 notscan anything outside of these ranges.

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

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


Task 4: Ensure MID Server ConnectivityOpen the instance and navigate to Discovery > MID Servers. If the new MID Servers are configured properly, theywill appear in the list of MID Servers. If a MID Server does not appear as a choice in the instance, perform thefollowing 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 InstanceSet 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 logonconfigured for the MID Server service on the Windows server host. Credentials for UNIX, vCenter, and SNMP mustbe configured on the instance. Discovery will automatically figure out which credentials work for a particularcomputer or device.

Task 6: Define Discovery Schedules and Run DiscoveryThe 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 manyschedules as necessary, using different types of discoveries, and configure them to run at any time. Let Discoveryrun on its configured schedule or manually execute Discovery at any time. These schedules can be set up in a varietyof 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 IPnetworks. Once discovered, you can convert these networks into IP address range sets that you use in a DiscoverySchedule.

Note: For advanced discoveries, such as those requiring load balancing or scanning across multiple domains, use DiscoveryBehaviors.

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


Discovery LogUse the Discovery Log form for a quick look at how the probes are doing. To display the Discovery Log, selectDiscovery Log in the Related List of a Status record. The log record allows users to drill down into other recordsfrom 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

CMDBCI

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 thisDiscovery.


TroubleshootingNavigate to Discovery > Status and examine the status record for the current Discovery. From this record, use thelinks 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 againstwhat was expected. These results can help explain suspicious errors, such as why no software was detectedrunning 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 ProceduresTroubleshoot a Discovery using the procedures outlined in the following stages:1. Port Scanning2. Classification3. Identification4. Exploration

15

MID Server

MID Server Plugin

OverviewThe Management, Instrumentation, and Discovery (MID) Server is a Java server that runs as a Windows service orUNIX daemon. The MID Server facilitates communication and movement of data between the ServiceNow platformand external applications, data sources, and services. For specific requirements for using the MID Server withDiscovery, see MID Server Requirements for Discovery. The MID Server is installed automatically for newinstances.

Enhancements

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

Functional ArchitectureThe MID Server is a Java process that oversees 2 main functional groups of sub-processes, namely Monitors andWorkers. 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 anon-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 aWorker.Monitors1. Auto Upgrade2. Heartbeat3. Queue Monitor4. Queue Sender5. Synchronizers

Altiris LanDesk Microsoft SMS IBM Tivoli CCMDB JDBC

Workers1. Command Line2. JDBC3. File

MID Server Plugin 16

4. Probes HTTP WMI SNMP SSH

JAR File SynchronizationIn 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 theinstance: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 RequirementsThe 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.0The 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)

MID Server Plugin 17

ApplicationsThe 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

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

System RequirementsThe 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.0The 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 RequirementsThe 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

MID Server Requirements for Discovery 18

preventing external TCP connections from that host. Contact network security personnel for the proxy information toadd to the config.xml file, or request that the Firewall be configured to allow access using one of the followingsyntaxes: to to any established to 443

Internal RequirementsThe three methods used for discovering various devices on a network are SSH, WMI and SNMP. SSH is used foraccessing UNIX-like machines. Discovery logs into a machine with SSH and runs commands within an encryptedsession to gather system information. Runbook Automation logs in to UNIX and Linux machines using SSH toperform Workflow activities. WMI is used by Discovery for Windows based machines and is used for querying theremote WMI protocol on targets for gathering of Windows information. Runbook Automation uses PowerShell torun 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 - UNIXFor UNIX-like machines, Discovery and Runbook use SSH [1] to access target machines. SSH is a network protocolthat allows data to be exchanged using a secure channel between two networked devices. SSH communicates on port22 within an encrypted datastream and requires a login to access the targets using two available methods ofauthentication: a user name and password combination and a user name and shared private key. Specify SSHauthentication information and type in the Credentials module. If multiple credentials are entered, the platform triesone after the other until a successful connection is established or all are ultimately denied. To provide for applicationrelationships a limited number of SUDO commands must be available to be run. Additional details to theserequirements can be found in UNIX/Linux commands requiring root privileges for Discovery.

WMI - WindowsFor Windows machines, Discovery uses the Windows Management Instrumentation (WMI) [2] interface to querydevices. Due to Microsoft security restrictions for WMI, the MID Server application executing the WMI queriesmust 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 ObjectModel (DCOM) port configured for WMI on Windows machines. This can be any port [3]. Ensure that the MIDServer application host machine has access to the targets on all ports due to the unique nature of the WMIrequirements.

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

MID Server Requirements for Discovery 19

SNMP - NetworkFor network devices, a SNMP scan [5] is used to get device specific MIBs and OIDs. SNMP is a common protocolused 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 anout-of-box community string of public which Discovery (by default) uses when querying a target. Define additionalcommunity strings in the Credentials module which are tried in succession, along with public, until a successfulquery returns. In addition to the credentials, the platform also requires the ability to make port 161 SNMP requestsfrom the MID Server to the target. If Access Control Lists (ACLs) are in place to control the IP addresses that canmake 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.

WBEMWeb-Based Enterprise Management (WBEM [6]) defines a particular implementation of the CommonInformation 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 SSLencryption and uses CIM user name/password credentials. ServiceNow Discovery launches a WBEM port probe todetect activity on the target ports and to append gathered data to a classification probe that explores CIM Servers.

References[1] http:/ / en. wikipedia. org/ wiki/ Secure_Shell[2] http:/ / en. wikipedia. org/ wiki/ Windows_Management_Instrumentation[3] http:/ / support. microsoft. com/ kb/ 832017[4] http:/ / support. microsoft. com/ kb/ 968929[5] http:/ / en. wikipedia. org/ wiki/ SNMP[6] http:/ / en. wikipedia. org/ wiki/ Web-Based_Enterprise_Management[7] http:/ / en. wikipedia. org/ wiki/ Common_Information_Model_(computing)

MID Server Installation 20

MID Server Installation

DeploymentThe MID Server must be able to communicate with the machines it is configured to probe. There are several reasonswhy a probe may fail, even though the MID Server can ping the target device. Ensure that the machine on which theMID 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 theDMZ, 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 youfrom configuring new machines that can connect to the targets, then the MID Server must be installed on anexisting 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 MIDServers for details.

InstallationAfter the MID Server plugin is enabled on your instance, you will see the MID Server application in the ApplicationNavigator. If you have enabled Discovery, Runbook Automation, or any integration that requires the use of theMID 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 downloadthe MID Server for the operating system you are targeting in the form that appears.


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

Installing a Single MID Server on a Machine1. 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 theURL to your instance.

Enter the user credentials if basic authentication is enabled (default behavior) in themid.instance.username/password parameters.

Modify and enter thename of your MID Server.

Enter connection information for any proxy server used and be sure to remove the comment tags from theproxy configuration information.NOTE: If this MID Server is installed on a machine that contains other MID Servers, edit the wrapper.conffile 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 UserAccount Control (UAC) setting.

4. In the command prompt, navigate to \agent in the directory you created for the MID Server files. Forexample, the path might be C:\ServiceNow\MID Server1\agent.5. Run start.bat.


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 isinstalled, 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 MachineYou 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 orMIDServer_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 URLto your instance.

Enter the user credentials if basic authentication is enabled (default behavior) in themid.instance.username/password parameters.

Modify and enter thename of your MID Server.

Enter connection information for any proxy server used and be sure to remove the comment tags from theproxy 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 anddescribe your services correctly before you complete the next step.


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 UserAccount Control (UAC) setting.

4. In the command prompt, navigate to \agent in the directory you created for the MID Server files. Forexample, 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 isinstalled, 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/Linux1. 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 enterthe URL to your instance.

Enter user credentials if basic authentication is enabled (on by default) in themid.instance.username/password parameters

Enter connection information for any proxy server used and be sure to remove the comment tags from theproxy 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.


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

UninstallingThe MID Server runs as a stand-alone service and can be removed easily to accommodate such tasks as redeployingthe MID Server to another host machine, or changing the unique name of a MID Server when deploying multipleMID Servers.1. Stop the running MID Server service.2. Open a command window (Start > Run > cmd).3. Go to the \agent\bin folder in the MID Server installation folder.4. Double-click the uninstall.bat file.

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

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

Upgrade Error MessagesThe 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 MIDserver buildstamp

Instance is offline or there is a major version mismatch between the MID Server and the instance. Thismessage 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 AuthenticationTo enforce basic authentication on each request from the service via SOAP messages, you may set the propertyglide.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 requirethe Authorization header during a request.Supplying basic authentication information, whether or not it is required, has the added advantage that the datacreated or updated as a result of the Web Service invocation is done on behalf of the user supplied in the basicauthentication credentials. As an example, when creating an Incident record, the journal fields will have the user idof 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 theWeb Service properties. Enabling the Enforce strict security property will cause the usage of roles associated with the user ID toenforce access control on the tables the MID server is accessing, this is not usual.


Navigate to C:\Program Files\ServiceNow\\agent and edit the config.xml file as follows, usingWordpad: 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 ServerTo ensure uninterrupted service from the Windows-based MID Server, monitor the application host for thefollowing: 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 andalert 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 ErrorsThe MID Server agent log displays detailed information about errors encountered when connecting to theServiceNow instance. This log is created automatically in the \logs directory in the \agent installation directory. Thelog provides detailed information about the instance and the MID Server each time the MID Server is started. Usethis data to ensure that the instance and MID Server versions are compatible and that the MID Server is configuredto contact the correct instance. The log record also indicates if basic authentication and strict security are enabled onthe instance.This feature is available with the Aspen release.

Connection FailureA number of possible network issues can prevent connection, including a blocking firewall, an improperlyconfigured proxy server, or a DNS issue. The wording of the message can vary, depending on the cause of thefailure.

Note: If you configured the MID Server config.xml file to use a proxy server, ensure that the comment tags were removed fromaround 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


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

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

Authentication FailureThe user name and/or password configured in the MID Server config.xml file is incorrect or the user is incorrectlyconfigured 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:21 (031) StartupSequencer Successfully connected to instance:

08/30/11 15:16:21 (031) StartupSequencer Install name: Demo Server

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

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

08/30/11 15:16:21 (031) StartupSequencer Build date: 08-28-2011_2100

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

08/30/11 15:16:21 (031) StartupSequencer Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b

08/30/11 15:16:21 (031) StartupSequencer 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


Missing RolesIf the configured user is missing any roles, the message names the roles. The configured MID Server user must havethe 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: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 IssuesIf 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 theMID 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: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 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



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

Deploying Multiple MID Servers 29

Deploying Multiple MID Servers

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

IntegrationsFactors determining the number of MID Servers your network will require to support external applications thatintegrate 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.

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

Load balancingIn some cases, a single MID Server can handle all the transactions that occur between an instance and an externalintegration. However, in a high volume environment, it might be necessary to deploy multiple MID Servers as loadbalancers 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 requireseparate MID Servers in a busy network: File exports Running scripts JDBC data sources Reading files

High availability modelAvoid installing MID Servers for critical integrations on a machine that might experience any type of planned outageor an outage caused by overloaded processes. If necessary for reliability, consider deploying these types of MIDServers to dedicated machines for high reliability.

Warning: Do not integrate with an external application on a MID Server provisioned for ServiceNow Discovery or RunbookAutomation.

Deploying Multiple MID Servers 30

DiscoveryWhen 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 eachLAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WANconnections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPNconnections that take advantage of fast Internet connections. If the bandwidth of your WAN connections iscomparable to that of your Internet connection, then there is no performance impact in running MID Serverprobes across WAN connections.

DMZ: Your network policy might require you to install one or more MID Servers in your DMZ to probe thedevices 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 gatherinformation about thousands of configuration items quickly.

Security: If your security policy controls access to network devices (e.g. switches and routers) with an accesscontrol lists (ACL), it might be necessary to install one or more MID Servers on a machine in the network that isalready on the ACL.

Probe types: If you are conducting probes of different operating systems, your network policy might require aseparate MID Server for each type of probe (e.g., one MID server for Windows WMI probes and another for SSHprobes on UNIX)

Runbook AutomationWhen determining if multiple MID Servers are necessary to executes Runbook activities, consider the followingfactors: 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 eachLAN to probe devices locally, rather than deploying MID Servers that must probe devices across slow WANconnections. An alternative to this type of deployment is to install MID Servers that probe other LANs via VPNconnections that take advantage of fast Internet connections. If the bandwidth of the WAN connections iscomparable to that of the Internet connection, then there is no performance impact in running MID Server probesacross WAN connections.

DMZ: Network policy might require the installation of one or more MID Servers in the DMZ to probe thedevices 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 benecessary 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 separateMID Server for each type of probe (e.g., one MID server for Windows PowerShell and another for SSH probes onUNIX).

MID Server Configuration 31

MID Server Configuration

OverviewYou must complete all the steps in MID Server Installation before attempting any of the configuration stepsexplained 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 SizeIn 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 MIDServer to work harder, allocate more resources to it. Or perhaps the MID Server is located in a small branch officewith very few devices, and runs in an environment where memory allocation is shared between a print server, mailserver, or Web proxy server. In this situation, the MID Server memory allocation might have to be reduced. MIDServer memory is set to 512MB by default and is configurable in the \agent\conf\wrapper.conf file in the MIDServer installation directory.To edit the memory allocation:1. Navigate to \agent\conf and open the wrapper.conf file in a text editor.2. Locate the following lines in the file:3. # Maximum Java Heap Size (in MB)4. wrapper.java.maxmemory=5125. Edit the memory allocation.6. Save the file.7. 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

Credentialsprovider

mid.credentials.provider

Debugloggingenable

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

Debuglogging 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.


Debug modeenable

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 usefulwhen troubleshooting a problem. Be aware that setting this parameter to true willcause intensive logging on the MID server, potentially using considerable disk space.

Disablemonitorchecking

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

Enableautomaticinclusion ofSNMP publiccommunitystring

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

EnablePowerShellfor Discovery

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

Environmentvariable forSSHcommands

mid.ssh.set_path Optional, true/false, default true. Sets the PATH environment variable for SSHcommands.

Executelong-runningcommandsagainstlocalhost

mid.ssh.local Optional, true/false, default false. If set to true, executes commands for the MIDServer host machine (localhost) via SSH rather than from a console. This allowslong-running commands to execute properly.

Fixed MIDServer version

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

Instance dateformat

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

Instancepassword

mid.instance.password orglide.glidesoap.password

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

Instanceproxy enable

mid.instance.use_proxy ormid.proxy.use_proxy

Optional, true/false, default false. If your MID server must go through a web proxyto access the ServiceNow instance, set this parameter to true to instruct the MIDserver 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.

Instanceproxy host

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

Instanceproxypassword

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

Instanceproxy port

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

Instanceproxy username

mid.proxy.username Optional, string. If the MID Server must go through a web proxy to access theServiceNow instance, and the proxy requires a user name, set this parameter to definethat user name.


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

Instance username

mid.instance.username orglide.glidesoap.username

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

MID Serverauto-upgradeenable

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

MID Serverconnectioncache

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

MID ServerECC queryinterval

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

MID ServerID

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

MID Serverimmediateresponseenable

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

MID ServerJMX enable

mid.jmx.enabled Optional, true/false, default false. If set to true, this parameter enables a JMX serveron the MID server, exposing some management information to JMX consoles. This isan experimental feature, not officially released yet. Also, implementing JMX requiresadditional (and fairly complicated) configuration of the Java runtime environment.Setting this parameter to true is only recommended for those with detailed knowledgeof the Java security architecture, a specific need for JMX, and a strong desire to takeunreasonable risks with production software.


MID Servermaxtransmissionqueue size

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

MID Servermaximumnumber ofprobe threads

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

MID Servername

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

MID Serverpoll time

mid.poll.time Optional, integer, default 15. Allows you to override the default MID Server pollinginterval (in seconds).

MID Serverrefresh rate

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

MID ServerSSHconnectionper host

mid.ssh_connections_per_host Optional, integer, default 3. Controls the number of concurrent probes the MIDServer can run against a given host. Lowering the number of concurrent connectionscan slow Discovery.

MSSQLcredentials forPowerShell

mid.powershell.use_mssqlauth Optional, true/false, default false. This parameter determines whether PowerShellshould use Windows integrated security or SQL authentication when attempting tolog into the MSSQL instance. PowerShell uses Windows integrated security bydefault.

Port probepacketinterval

mid.shazzam.regulator.interval_ms Optional, integer, default 1. Sets the interval, in milliseconds, in which Shazzamcan launch packets. This parameter works with themid.shazzam.regulator.packets_per_interval parameter to set the number ofpackets allowed in this interval. By default, Shazzam launches one packet eachmillisecond.

Port probepacketslaunched perregulatorinterval

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

PowerShellcredentials

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


PowerShellexecutablepath

mid.powershell.path Optional, string URL. This parameter enables an administrator to point to a specificPowerShell 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 containingthe PowerShell executable, and powershell.exe is appended automatically to theURL. This parameter might be necessary, for example, when 32 bit and 64 bitPowerShells are active on the same MID Server, and it becomes necessary to launchthe correct PowerShell for the context. Note that 64-bit Windows employs file systemredirection and the MID server runs as a 32-bit application. If trying to specify a pathin %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 loggingenable

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

Remoteloggingdisable

disable.remote.logging Optional, true/false, default false. If this parameter is set to true, the MID serverwill 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 thisparameter will cut that to zero.

Set the PATHenvironmentpaths for SSHcommands

mid.ssh.path_override Optional, string. Configure an alternate SSH command path with this parameter tooverride the possible default paths (/usr/sbin: /usr/bin: /bin: /sbin). This MID Serverparameter is overridden if an alternate SSH command path is configured in a probeparameter.

Shazzamchunk size

mid.shazzam.chunk_size Optional, integer, default 100. The maximum number of IP addresses that Shazzamscans in parallel. This parameter primarily controls outbound port consumption.

SSHconnectionerror retry

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

SSH removecommandoverride

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

Status sendingdisable

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

Suppresshistory filegeneration forSSH

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

Timeout inms for SSHsocket open

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

Upgradebranch

glide.mid.autoupgrade.branch ormid.upgrade.branch

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


Upgradeproxy enable

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

Upgradeproxy host

glide.mid.autoupgrade.proxy_host orglide.glidesoap.proxy_host

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

Upgradeproxy port

glide.mid.autoupgrade.proxy_port orglide.glidesoap.proxy_port

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

Upgradeproxy user

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

Upgradeproxypassword

glide.mid.autoupgrade.proxy_password Optional, string. If your MID server must go through a web proxy to access theupgrade 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 itsupgrades from. Normally you should not set this parameter.

Use keyboardinteractiveauthenticationfor SSH

mid.ssh.use_keyboard_interactive Optional, true/false, default false. Uses the keyboard interactive authenticationmode in SSH daemons for MID Servers on which it is activated.

Managing Configuration from the ServiceNow InstanceYou 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'sconfiguration 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 tothe MID server's configuration file do not take place immediately, but rather the next time the MID server isrestarted. The MID server page has a convenient link to use to restart the MID server at any time.


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

Editing the config.xml FileThe MID Server's configuration is controlled by an XML file called config.xml. This file is located in the agentdirectory, immediately under the directory in which the MID Server was installed. Edit this file directly to make anyconfiguration changes. Many configuration changes (those that do not disrupt communication between the MIDServer 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 notdisplay colors and variable fonts. The structure of the config.xml file is simply an outer parameters tag and a seriesof inner parameter tags. Each parameter tag has name and value attributes. The name attribute contains the name ofeach parameter, and the value attribute contains the value of the parameter. To change the value of a parameter, editthe 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. Usethese 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 sectionsthat you configure.


Configuring Thread UseBy 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 threadswithout issues. If the MID Server needs more speed, and the host is powerful enough (or lightly loaded with otherprograms), raise the thread setting. The thread limit depends very much on the hardware and the operating system ofthe host. You might have to experiment to find the optimal value for your situati

servicenow discovery in detail

Documents

snmp querieswhat discovery

discovery needs access

discovery employs identifiers

discovered device

device matches

type of device

kind of device

snmp queries web servers