ServiceNow Discovery in Detail.
Documents gives you insight on
1. How to setup discovery
2. What are the different components of Discovery
3. What is MID Server
4. What credentials you need for Discovery
5. How can you load balance discovery
ServiceNow Discovery in Detail.
Documents gives you insight on
1. How to setup discovery
2. What are the different components of Discovery
3. What is MID Server
4. What credentials you need for Discovery
5. How can you load balance discovery
ServiceNow Discovery in Detail.
Documents gives you insight on
1. How to setup discovery
2. What are the different components of Discovery
3. What is MID Server
4. What credentials you need for Discovery
5. How can you load balance discovery
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
Discovery ServiceNow 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 2 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: 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. Thats 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 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 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. Discovery Made Easy 5 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. Discovery Made Easy 6 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. The port scan sees that the machine is listening on port 22, which means that this must be a UNIX or Linux machine. 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 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. Discovery Agentless Architecture 7 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) 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 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, 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. Setting up Discovery 11 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. Setting up Discovery 12 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. Setting up Discovery 13 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. Setting up Discovery 14 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. Port Scanning 2. Classification 3. Identification 4. Exploration 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. Auto Upgrade 2. Heartbeat 3. Queue Monitor 4. Queue Sender 5. Synchronizers Altiris LanDesk Microsoft SMS IBM Tivoli CCMDB JDBC Workers 1. Command Line 2. JDBC 3. File MID Server Plugin 16 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) MID Server Plugin 17 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 MID Server Requirements for Discovery 18 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: <source IP> to <any> <source IP> to <ServiceNow> any established <source IP> to <instance_name.service-now.com> 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. MID Server Requirements for Discovery 19 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] 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 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. MID Server Installation 21 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 <parameter name="url" value="https:/ / YOUR_INSTANCE. service-now. com" /> 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 <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE" /> 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. MID Server Installation 22 7. Edit the MID Server's credentials. a. Open the Windows Services console. b. Double-click on the ServiceNow <MID Server name> 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 <MID Server name> service and make sure that ServiceNow\<MID Server name>\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\<MID Server name>. 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\<MID Server name>\agent. 4. Using WordPad, edit the config.xml file in each MID Server \agent directory as follows: Modify <parameter name="url" value="https:/ / YOUR_INSTANCE. service-now. com" /> 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 <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE" /> 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\<MID Server name>\agent\conf wrapper.console.title=<MID Server name>: This is the title to use when running the MID Server as a console. wrapper.ntservice.name=<MID Server 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=<MID Server name>: 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=<New Custom 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. MID Server Installation 23 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 <MID Server name> 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\<MID Server name>\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/<mid server name> to create the installation directory. 2. Unzip the downloaded MID Server zip file, mid.<os>.zip into the /servicenow/<mid server name> directory. The resulting directory structure is /service-now/<mid server name>/agent. 3. Open the /agent directory (cd /service-now/<mid server name>/agent) and edit the config.xml file as follows: Modify the <parameter name="url" value="https://YOUR_INSTANCE.service-now.com" /> 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. 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. 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 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 25 Navigate to C:\Program Files\ServiceNow\<MID Server name>\agent and edit the config.xml file as follows, using Wordpad: Find <parameter name="mid.instance.username" value=""/> and enter your instance's administrator user name as the value. For example, you might enter <parameter name="mid.instance.username" value="admin"/> Find <parameter name="mid.instance.password" value=""/> and enter the configured password for this instance as the value. For example, you might enter <parameter name="mid.instance.password" value="NY12bqp1A"/>. Enter the display name that appears for this MID Server in your ServiceNow instance in the following line: <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE"/> 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 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 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 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 <user name> 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 Install name: Demo Server 08/30/11 15:22:24 (953) StartupSequencer Instance name: demosw 08/30/11 15:22:24 (953) StartupSequencer Node: 9b1a9ce90a0a3c1801834233f12ce49e 08/30/11 15:22:24 (953) StartupSequencer Build date: 08-28-2011_2100 08/30/11 15:22:24 (953) StartupSequencer Build tag: 08/30/11 15:22:24 (953) StartupSequencer Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b 08/30/11 15:22:24 (953) StartupSequencer 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 Install name: Demo Server 08/30/11 14:02:52 (062) StartupSequencer Instance name: demosw 08/30/11 14:02:52 (062) StartupSequencer Node: 9b1a9ce90a0a3c1801834233f12ce49e 08/30/11 14:02:52 (062) StartupSequencer Build date: 08-28-2011_2100 MID Server Installation 28 08/30/11 14:02:52 (062) StartupSequencer Build tag: 08/30/11 14:02:52 (062) StartupSequencer Instance ID: 8026b1fa0a0a3c180142bbe642c6e92b 08/30/11 14:02:52 (062) StartupSequencer 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 29 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. Deploying Multiple MID Servers 30 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). 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. Navigate to <MID Server name>\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=512 5. 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 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 Server version mid.pinned.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 SimpleDateFormat class, documented here [1] 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: <parameter name="MIDServerRefreshRate" value="<N>"/> 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 credentials for PowerShell mid.powershell.use_mssqlauth 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 35 PowerShell executable path mid.powershell.path 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 enable mid.show.queries 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 disable.remote.logging 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. Set the PATH environment paths for SSH commands mid.ssh.path_override 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 disable.status 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 history file generation for SSH mid.ssh.suppress_history 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 interactive authentication for SSH mid.ssh.use_keyboard_interactive 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 37 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. MID Server Configuration 38 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: <!-- MID Server Threads --> <parameter name="threads.max" value="25"/> 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\<MidServer(s)>\agent\jre\bin 2. Enter the following keytool command to import a certificate into the MID server's cacerts keystore: keytool -import -alias <certificate alias> -file "<path to certificate>" -keystore "<path to MID Server(s)>\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" MID Server Configuration 39 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. MID Server Configuration 40 3. In the Properties dialog box, click Unblock. 4. Repeat the procedure for each of the remaining files. References [1] http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ text/ SimpleDateFormat. html [2] https:/ / example.service-now. com [3] http:/ / install. service-now.com/ glide/ distribution/ builds/ mid/ [4] 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 41 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. Navigate to MID Server > Clusters. 2. Click New. 3. Name the cluster and select the cluster type: Failover or Load Balance. 4. Right click in the header bar and select Save from the context menu. 5. Click Edit in the Includes MID Servers Related List. 6. 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. MID Server Clusters 42 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. Controlling the MID Server Version 43 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. The list of system properties appears. 2. Click New. 3. Type mid.version.override in the Name field. 4. Enter a description, such as, Set an override value for the current MID Server version. 5. 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. MID Server Heartbeat 44 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. MID Server User Security 45 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. 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 Description Default Value shazzam_chunk_size The maximum number of IP addresses Shazzam will scan in parallel. This parameter primarily controls outbound port consumption. 100 regulator_max_packets The maximum number of packets allowed per regulator period. 1 regulator_period_ms The number of milliseconds per regulator period. 1 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 50 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. Custom Probe - Text File 51 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: 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. 3. Right-click in the header bar and select Save from the context menu. 4. Select the Probe Parameters tab in the Probe form, and then click New. 5. Enter WMI_GetFiles.js as the Name of this parameter. 6. Copy the script below into the Script field and edit as needed. 7. Click Submit. The completed probe form looks like this: Custom Probe - Text File 52 // // 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 Custom Probe - Text File 53 //
new DiscoverySensor({ data: {}, process: function(result) { this.parseOutput(result.output); this.update(this.data); },
parseOutput: function(output) { var currentFile; var files = {};
if (output.startsWith("<wmi")) { var bgout = new XMLHelper(output).toObject(); if (!bgout) return;
output = bgout.output; }
var lines = output.split(/\n/);
for(var i = 0; i < lines.length; i++) { var line = lines[i]; if (line.startsWith("C:\\Information Systems\\BgInfo\\")) { currentFile = line.substr(30); files[currentFile] = ""; } else if (currentFile) { var newLine = line.trim(); if (newLine) files[currentFile] += (files[currentFile]? "\n" : "") + newLine; } }
The completed form looks like this: Custom Probe - Text File 54 55 Device Classification Device Classifications Overview After Discovery detects active devices in your network using a port scan (Shazzam probe), Discovery attempts to classify the devices so that it can gather additional information. Discovery launches classify probes that query devices to find out such things as operating system and version information. For information, see Data Collected by Discovery. The following classify probes are included with the platform: UNIX - Classify: SSH commands for all UNIX operating systems SNMP - Classify: SNMP commands for all netgear devices, such as printers, routers, or UPS. Windows - Classify: WMI commands for all Windows machines How Device Classification Works When Discovery is initiated, the Shazzam probe is launched to detect open ports on devices in the network. The data returned is used by the Shazzam sensor to identify certain characteristics about these devices based on the activity known to exist on these ports. For example, UNIX-based operating systems communicate with the SSH protocol over port 22, and Windows communicates with the WMI protocol over port 135 or higher. Discovery makes certain assumptions about the devices, applications, and processes running on these ports and launches the appropriate classify probes to find out more. Classify sensors process the data returned from the probes and compare it with configured criteria for each class of device. At this point, classification varies, depending upon the type of scan selected and the version of ServiceNow being used. Process classification occurs during the exploration phase of Discovery, after device classification. For more information, see Process Classifications. Discoverable Windows Operating Systems The out-of-box Discovery system provides separate classifiers for the following Windows server versions: Windows NT Server Windows 2000 Server Windows 2003 Server Windows 2008 Server Windows Cluster VIP The Windows classifier supports the following Windows workstation operating systems: Windows XP Windows Vista Windows 7 Device Classifications 56 Classification Device classification occurs only when a Discovery Schedule is configured to discover Configuration items. This scan type enables Discovery Identifiers and is the only scan that can be used to update the CMDB. When Discovery has determined the device's class, it launches an identity probe - a multiprobe - that is configured to run one or more commands with a single authentication. The identity probe in the out-of-box system can be configured to ask the device for information such as its serial numbers (there can be more than one), name, and network identification. The results of this scan are processed by an identity sensor, which then passes the results to the Identifier. The Identifier then attempts to find a matching device in the CMDB. If the identifier finds a matching CI, the Identifier either updates that CI or does nothing. If the identifier cannot find a matching CI, it either creates a new CI or does nothing. If Discovery is configured to continue, the Identifier launches the exploration probes configured in the Classification record to gather additional information about the device. Exploration probes can be multiprobes or simple probes. This diagram shows the processing flow for classifying and probing devices with Identifiers configured. IP Scan Mode The IP Scan mode enables credential-less Discovery, which attempts to identify devices and software based on just the open ports and banners it finds. If the classification criteria are met for a device in the IP Scan mode, Discovery automatically updates the CI in the CMDB. After a device is properly classified, Discovery launches the exploration probes configured for that class of device and begins gathering detailed information about the CI. For example, in the default ServiceNow system, the Linux classification triggers eleven exploration probes that return information such as disk size, memory, and the number of current connections. The data from these probes returns at different times and is stored in the ECC Queue until processing is complete. This diagram shows the processing flow for classifying and probing devices with Discovery IP Scan (no Identifiers): Device Classifications 57 The Classification Form Select Discovery Definition > CI Classification in the navigation pane and select the desired classification. ServiceNow includes classifications in the base platform that discover most common operating systems, network devices, and processes. ServiceNow provides the following fields for creating new device classifications or edit existing ones. Field Input Value Name Name of the configuration item (CI) Active Enable or disable this classification. Order Configure the order (sequence) in which the platform run this classifier, Table Select the a table for this classification. For example, if this record classifies a Windows server, select the Windows Server [cmdb_ci_win_server] table. Match Criteria Select which criteria must match to classify this device - Any of the parameters or All of the parameters. On classification script This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. With the October2011 Preview 1 release, it is possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes. (JS), g_probe_parameters['node_port'] = 16001; // Classification Criteria These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters. Triggers probes These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the network. A completed CI classification form with exploration probes defined is shown here. For instruction on creating probes, see Creating a Probe. The probes defined here are launched when the device is properly classified, unless Discovery is configured to stop after classification. Device Classifications 58 Classification Criteria The classification criteria for a device classification includes a parameter, an operator, and a value. The available parameters are those returned by Discovery classify probes for each class of device found. The values configured for these parameters are the values that Discovery is looking for to establish a device's class. For available parameters for each default classification, see Discovery Classification Parameters. In this example from the base ServiceNow platform, the device to be classified has a name value that starts with Windows 2003. The On classification script field can be used to further customize the application record being created. The following objects are exposed for this purpose. Parameter Description isNode Indicates if this instance is a node. type Returns the classification windows. isVIP Indicates if this CI is a virtual machine, with a virtual IP address. ip_address Returns the IP address of the device being discovered. name Name of the Windows version, such as Windows 2003 Standard. Device Classifications 59 Reclassifying a Windows Workstation Machine as a Server By default, Discovery automatically classifies computers using certain Windows operating systems as workstations. (See Discoverable Windows Operating Systems for details.) However, some organizations might want specific computers in their network that are acting as servers to be classified by their function and not their operating system. Use the following variables, preceded by cidata., to construct a reclassification condition. For example, to reclassify based on a machine's IP address, use cidata.ip_address. name dsn_domain os_domain ip_address serial_number The following procedure reclassifies any Windows workstation operating system (Windows Vista, XP, or Windows 7) that is acting as a server. 1. Navigate to Discovery Definition > CI Classification > Windows. 2. Create a new classification record, such as Windows XP Server. 3. Select Windows Server [cmdb_ci_win_server] as the table. 4. Right-click in the header bar and select Save from the context menu. The Classification Criteria and Triggers Probes Related Lists appear. 5. Configure the following Classification Criteria: Name: Select a variable to use as the classification criteria from the list above. For example, to reclassify a machine by name, enter cidata.name. This works for servers that have a uniform naming convention, such as SRV001, SRV002, etc., regardless of operating system. Operator: Select an operator for the classification condition. In networks containing servers named with a specific convention, you might select starts with or contains. Value: Enter the value for the condition. In our example of a network with a server naming convention, this value would be the root of that convention, such as SRV. This condition will classify all computers as servers if their machine name is SRVXXX. 6. Select the Triggers Probe Related List and add the appropriate probes. a. Copy the list of probes from another Windows server classification, including the Condition scripts. b. Ensure that the Windows - Identity probe has a phase of Identification (the default is Exploration). The completed form looks like this: Device Classifications 60 Debugging Classifications To log debugging information about classifications, add the glide.discovery.debug.classification property and set the value to true. The resulting log entries list the name of each classifier that runs, along with all the names and values that are available to the criteria in the classifier. To add the property: 1. In the navigation filter, type sys_properties.list. The list of properties appears. 2. Click New. 3. Enter glide.discovery.debug.classification in the Name field. 4. Enter a description, such as Log debugging information about Discovery Classifications. 5. Select true/false as the property Type. 6. Type in a Value of true. 7. Click Submit. Process Classifications 61 Process Classifications Overview Process classification in Discovery tracks services, such as database servers, that play an important business role in your instance. Discovery classifies processes during the exploration phase, after the devices have been identified. Process classification, like device classification, uses classification criteria and can launch probes, but unlike device classification, creates child configuration items (CI) with Runs on::Runs relationships. For information on how Discovery creates and maintains dependent relationships between CI, including processes, see Application Dependency Mapping. The Classification Form Select Discovery Definition > CI Classification > Process in the navigation pane. ServiceNow includes classifications in the base platform that discover most common processes. ServiceNow provides the following unique fields for creating new classifications or edit existing ones. Field Input Value Table Select the a table for this classification. For example, if this record classifies a router, select the cmdb_ci_ip_router table. Relation type Select the CI relationship types for this classification. The relationship field is only available for Process and Scan Application classifications. The relationships that are most appropriate for Discovery are: Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the perspective of the host and the application. For example: My database application runs on server001::server001 runs my database application. Depends on::Used by: Defines the relationship of an application that communicates with another application. This relationship is expressed from the perspective of each application. For example: The Tomcat application depends on the MySQL database:: The MySQL database is used by Tomcat. Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes server001. Match criteria Select which criteria must match to classify this device - Any of the parameters or All of the parameters. On classification script This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. With the October2011 Preview 1 release, it is possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes. (JS), g_probe_parameters['node_port'] = 16001; // Classification Criteria These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters. Triggers probes These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the network. A completed process classification form with an exploration probe defined is shown below. For instruction on creating probes, see Creating a Probe. The probes defined here are launched when the device is properly classified, unless Discovery is configured to stop after classification. Process Classifications 62 Classification Criteria The classification criteria for a Discovery Classification includes a parameter, an operator, and a value. The available parameters are those returned by Discovery classify probes for each class of device found. The values configured for these parameters are the values that Discovery is looking for to establish a device's class. For available parameters for each out-of-box classification, see Discovery Classification Parameters. In this example from the out-of-box ServiceNow system, the process that is started with the command sqlservr.exe is classified as Microsoft SQL Server. The On classification script field can be used to further customize the application record being created. There are currently some objects that are exposed for this purpose. current: Points to a JavaScript object with its [property:value] pair to update the application record. (It is NOT an actual GlideRecord object of the application) g_sensor: Points to the running process sensor class. This object contains a deviceGR object, which points to the computer CI record on which the process resides. g_classification: Points to the process classifier record itself. name: Points to the process name. command: Points to the process command. parameters: Points to the process parameters. g_probe_parameters: A javascript object that will allow parameter passing to the triggered probes. By default, we create the name of the application in this format: <name of the process classifer>@<the name of the computer CI where the process resides> For example, for a MySQL server running on a computer called machineA, we create an application with the name, mysql@machineA. If this is not the desired name, we can customize it using exposed variables in the following script in the On classification script field: var computerName = g_sensor.deviceGR.name; var processClassiferName = g_classification.name; Process Classifications 63 current.name = processClassiferName + "999" + "@" + computerName; In this example, the name of the application record becomes mysql999@machineA. Another common technique is to use the name, command and parameter variables. For example, looking at an Eclipse process, we might have the following values in these variables: name => "eclipse" command => "/glide/eclipse/Eclipse.app/Contents/MacOS/eclipse" parameter => "-psn_0_1884620" For an Eclipse application running on a computer called machineA, we create an application with the name, eclipse@machineA. If this is not the desired name, we can customize it differently (in the On classification script field). In the following example, we append the parameter value as part of the name of the application we create. var computerName = g_sensor.deviceGR.name; var processClassiferName = g_classification.name; current.name = processClassiferName + parameters + "@" + computerName; In this example, the name of the application record will become eclipse-psn_0_1884620@machineA. Also, sometimes it's useful to pass certain values to the triggered probes in the process classification, we can achieve this by adding the name/value pair to the g_probe_parameters object. g_probe_parameters['processCommand'] = command; In the example above, if there is a probe triggered from the classification record, it automatically gets the parameter called "processCommand" with the value of the command variable attached to the probe. Debugging Classifications To log debugging information about classifications, add the glide.discovery.debug.classification property and set the value to true. The resulting log entries list the name of each classifier that runs, along with all the names and values that are available to the criteria in the classifier. To add the property: 1. In the navigation filter, type sys_properties.list. The list of properties appears. 2. Click New. 3. Enter glide.discovery.debug.classification in the Name field. 4. Enter a description, such as Log debugging information about Discovery Classifications. 5. Select true/false as the property Type. 6. Type in a Value of true. 7. Click Submit. Discovery Classification Parameters 64 Discovery Classification Parameters Overview Each type of Discovery classify probe (Windows, UNIX, SNMP, etc.) returns a unique set of parameters that contains classification information. Any of the supported parameters can be used as configurable criteria for classifying devices that Discovery finds. The tables in this page define the available parameters for each classification. Discovery also provides a way to classify devices it finds when no credentials are available. Discovery for IP addresses makes certain assumptions about devices and the applications running on those devices from the ports that it finds open. Classification parameters for this type of Discovery are generated differently from scans in which credentials are available. See Forming Parameters for IP Address Scanning for details. Creating Classification Criteria To add criteria to a Classification record, navigate to Discovery Definition > Classification > <type> and click New in the Classification Criteria Related List. Type in the appropriate parameter, select an operator, and enter a value to use for this classification. This form provides the usual operators, including these that may not be familiar: regex matches: Use this operator to create a regular expression [1] to conduct a complicated search on a string. in IPs: Find a single IP address in an IP address range, network or list. Possible formats are: 10.10.10.0 - 10.10.10.255; 10.10.10.0/24; or 10.10.10.0, 10.10.10.1, 10.10.10.2. The Discovery classify probe returns values for these parameters from the devices it finds and compares them with the values configured for this classification. The classify sensor then decides if the classification criteria for a device have been met. If the criteria match, the sensor looks at the classification record to determine what probes must be launched. The following record is for a Windows Server 2003 in the Windows classification. To add an additional classification criteria (parameter) to the list, click New and define the new parameter in the Classification Criterial form (inset). Click Submit to add the parameter to the list. Discovery Classification Parameters 65 UNIX Parameters The UNIX parameters define the characteristics of several types of computers, such as Linux, Solaris, and HP-UX, communicating with the SSH protocol. Parameter Description output The raw output of the classifier probe (uname -a). type Returns the classification UNIX. IP address Returns the IP address of the device being discovered. name Name of the operating system for this UNIX CI. For example, Linux or HP-UX. Windows Parameters Windows parameters identify Windows computers communicating with the WMI protocol. Discovery Classification Parameters 66 Parameter Description isNode Indicates if this instance is a node. type Returns the classification windows. isVIP Indicates if this CI is a virtual machine, with a virtual IP address. ip_address Returns the IP address of the device being discovered. name Name of the Windows version, such as Windows 2003 Standard. SNMP Parameters The SNMP parameters can define the characteristics of several types of devices, such as routers, switches, and printers. Parameter Description powering A value of true indicates that this device is an uninterruptible power supply (UPS). hosting A value of true indicates that this device can host programs. Hosts are general purpose computers such as servers. netware A value of true indicates that this device is running the Netware operating system. routing A value of true indicates that this device has network routing capabilities. ip_address Returns the IP address through which the device is being discovered. A device can have multiple IP addresses. sysdescr Required descriptive field on any SNMP device that can contain useful classification data, such as the operating system and its version. vlans A value of true indicates that this device can host a virtual local area network. hint_router A value of true indicates that Discovery has determined that this device is a router. This field only applies to devices that can be used as both a router and a switch. block_router_exploration If this parameter is true, Discovery will not launch exploration probes for routers it detects. This parameter is used for network Discovery only. switching A value of true indicates that this device has network switching capabilities. mfr_apc A value of true indicates that this device is an uninterruptible power supply (UPS) manufactured by American Power Conversion (APC). printing A value of true indicates that this device has printing capabilities. block_switch_exploration If this parameter is true, Discovery will not launch exploration probes for switches it detects. This parameter is used for network Discovery only. Process Parameters Process parameters identify processes such as those used by LDAP, Apache Server, and JBoss Server. Discovery Classification Parameters 67 Parameter Description parameter The parameters used to run the process. command The command used to run the process. output The complete output of the current line of the process probe. type Indicates the process type (e.g. unix or windows). PID The process ID generated by the operating system of a device to identify a running process. Generally, this parameter is not a practical classification criteria, because the value does not remain static, except in the case of processes running on an appliance that is never restarted. name Name of the process being discovered. In some cases, this parameter is not reliable, since several process might be given the same name. In Windows, for example several processes return scvhost.exe for this parameter. Classification for IP Address Scanning Classification is available for the IP Addresses Discovery type and returns information about CIs (Scan CI) and applications running on CIs (Scan Application). No credentials are required to scan for Windows or UNIX devices with this type of scan, but community string credentials are required for SNMP devices. By determining which ports are open on the devices that it scans, IP address classification can discover such things as the type of device (computer, UPS, etc.), operating system, running applications, and version numbers. Note: IP address classification attempts to classify devices when no credentials are available; however, Discovery will use credentials when they are available, even when IP address classification is configured. To use IP address classification, follow these steps: 1. Determine what ports to use for classification. Run a scan program such as Nmap on specific IP addresses to decide which ports reveal the desired information about a device or application. The scan can reveal several pieces of data that are useful for configuring classification parameters. An Nmap scan displays port numbers, their state (open or closed), their service names, and any version information it can find. From the port information returned in the example below, we can construct criteria to classify UNIX servers (port 22), MySQL (port 3306), and Apache Tomcat (port 16000). Discovery Classification Parameters 68 2. Add an IP Service and port probe. The out-of-box ServiceNow system supplies probes for some of the most common ports, but additional port probes will be needed for effective IP address scanning. a. Navigate to Discovery Definition > IP Services and click New. b. Create a new IP Service record using the port number and service from the Nmap scan. In this example, we associate the mysql service with port 3306 and add the CI (sanops02) on which the service runs to the Available on Related List. c. To use Basic Discovery, navigate to Discovery Definition > Functionality Definition and select the record for All. d. Add the new port probes to the list. This tells Discovery which port probes to run for IP address scans. Discovery Classification Parameters 69 e. Save the record and navigate to Discovery Definition > Port Probes and click New. f. Create a port probe using the new IP Service you just defined. 3. Create a new classification and add the parameter for IP address scanning. In this example, we have created an application classifier that will discover Apache Tomcat, based on the port information we received from the Nmap scan. See the following section for details about forming parameters for IP address scans. Forming Parameters for IP Address Scanning The syntax for creating parameters is derived from the fields returned by the Shazzam probe when conducting a Discovery for IP addresses. Parameters for CIs and applications are formed in the same way. The Shazzam probe creates an XML file containing the following fields: name port portprobe protocol result service Discovery Classification Parameters 70 Note: Optional fields that can be used to form parameters appear as child tags beneath the default fields. Example of these are the sysDescr and banner_text fields. Parameters are expressed in the form of <portprobe.service.field>. The value for field can come from any of the fields or child tags in the XML file. For example, the following parameters classify a device as a UNIX server and detect an installation of MySQL: ssh.ssh.result mysql.mysql.result These parameters were derived from the values in the following XML file generated by a Shazzam probe conducting an IP Scan. The result field returned a value of open for ports 22 and 3306 on the target device. The service field indicates the services that normally communicate over those ports. The sysDescr field can provide additional information about devices, depending upon the manufacturer. This XML file from the Shazzam probe reveals the following about port 161 on the device at IP 10.10.11.149: In the classification criteria, we can construct the following parameter with sysDescr that returns an Apple AirPort wireless router. snmp.snmp.sysDescr > contains > Apple AirPort Discovery Classification Parameters 71 References [1] http:/ / www. zytrax. com/ tech/ web/ regex.htm 72 Setting Up and Running Discovery Discovery Identifiers Overview When Discovery finds a device in your network, it makes an effort to determine if the device already exists in the CMDB. When Discovery is configured to use Identifiers, it launches special identity probes that accumulate identification data for each device and feed that data into the Identifiers, which determine the action that Discovery must take for each device. Identifiers accurately determine the identity of the device and prevent the creation of duplicate CIs. Enabling Identifiers Identifiers are used for all Discovery Schedules that are set up to discover Configuration items. Discoveries of this type compare devices found in the network with CIs in the CMDB and update the CMDB, when appropriate. The Configuration item scan is the only type of Discovery that touches the CMDB. 1. Select Configuration items as the type of Discovery to run in the Discovery Schedule. This setting tells Discovery to launch the appropriate identity probes after classification has determined the class and operating system of the device. 2. Configure the Identity probes and probe sequence 3. Configure Identifiers and result states. 4. Run Discovery. Discovery Identifiers 73 Creating Custom Identifiers and Identity Probes Note: This functionality requires a knowledge of Javascript. The default ServiceNow Identity probes and Identifiers are configured to work together to identify discovered devices in most networks. You are encouraged to use these records whenever possible. If you need different data to identify devices, create your own probe/sensor pairs and matching Identifiers to suit your particular situation. DO NOT modify, disable, or delete existing ServiceNow records. If you do so, they cannot be upgraded or recovered. The best practice is to use the existing records as templates for your own elements, and then replace the ServiceNow probes, sensors, and Identifiers with your custom elements in all modules where they are used (Classification records, probe and sensor records, and Identifiers). How Identifiers Work When Discovery has determined the device's class, it launches an identity probe - a multiprobe - that is configured to run one or more commands with a single authentication. The identity probe in the out-of-box system can be configured to ask the device for information such as its serial numbers (there can be more than one), name, and network identification. The results of this scan are processed by an identity sensor, which then passes the results to the Identifier. The Identifier then attempts to find a matching device in the CMDB. If the identifier finds a matching CI, the Identifier either updates that CI or does nothing. If the identifier cannot find a matching CI, it either creates a new CI or does nothing. If Discovery is configured to continue, the Identifier launches the exploration probes configured in the Classification record to gather additional information about the device. Exploration probes can be multiprobes or simple probes. This diagram shows the processing flow for classifying and probing devices with Identifiers configured. Discovery Identifiers 74 Configuring Identity Probes Identity probes are multiprobes. Multiprobes contain one or more simple probes configured to extract specific information from manageable devices. Identity probes return such information as device serial numbers (there can be several per device), the computer name, and network identification (MAC address). For example, the Linux - Identity multiprobe provided in the system, contains two simple SSH probes configured to return hardware and network information about the device. After the probe has discovered this information, it passes the data to a multisensor configured to process identity information. To configure identity probes: 1. Navigate to Discovery Definition > Probes. 2. Select Multiprobe in the Probe Type field. 3. In the Includes Probes Related List, click Edit to select simple probes to include in this multiprobe. 4. Click New to create a new simple probe. Note: A multiprobe cannot contain another multiprobe. Identity Probes Included with ServiceNow The following identity multiprobes are included with the out-of-box ServiceNow system. The corresponding multisensors have the same names. Discovery Identifiers 75 Multiprobe Includes these probes AIX - Identify AIX - Network: Determines network interfaces, IPs, and MACs AIX - Serial Number: Retrieves the AIX serial number HP-UX - Identify HP-UX - Hardware Serial Number: Retrieves HP-UX serial number HP-UX - Network: Retrieves HP-UX networking information Linux - Identify Linux - Hardware Information: Gets DMI (BIOS) information Linux - Network: Gets network information Mac OS X - Identify Mac OS X - Network: Gathers network information from Macintosh machines. Mac OS X - CPU/Memory: Gathers CPU/memory information from Macintosh machines. SNMP - Identify SNMP - Identity Info: Identifies a printer CI. Solaris - Identify Solaris - Network: Gets network information about Solaris devices Windows - Identify Windows - Network: Probes a Windows machine for network information Windows - OS/Hardware Information: Probes a Windows machine for WMI information Configuring Identity Sensors You must have a properly configured multisensor for each identity probe in your system. These multisensors pass the data returned by the identity probes to the Discovery Identifiers. The Identifiers then search the CMDB for matching CIs. When the identity of a device is resolved, the Identifiers pass the result state for the device to the multisensors, which react accordingly, either by launching exploration probes or stopping Discovery for that device. See Processing Flow for Discovery Identifiers for details on the interaction between multisensors and the Identifier. To configure a multisensor, navigate to Discovery Definition > Sensors and select an existing identity multisensor from the list. To avoid confusion, the multisensors provided in ServiceNow have the same names as their matching multiprobes. The Responds to Probes Related List shows the simple probes which pass their data to this multisensor. These are the same simple probes that appear in the Includes Probes list in the matching multiprobe record. Click on the Script link for each probe in the list to see the script that the multisensor runs to process the data from the probe. Discovery Identifiers 76 Device Classification When a classification probe runs, it returns the device class and operating system (if the device is a computer). Computer Printer Netgear UPS When you enable Identifiers, Discovery Classification determines what identity probe to launch. For example, if the device class returned is Computer, and the operating system is Linux, then the classification record launches the pre-configured Linux - Identity multiprobe. The out-of-box ServiceNow system has identity probes configured for each classification, in addition to exploration probes, that can be launched after the results are evaluated. To view all probes triggered by a classification, navigate to Discovery Definition > Classification. Computers are listed by operating system. Non-computer classes use SNMP probes. The identity probe is listed in the Triggers Probes Related List and is launched only when Identifiers are enabled. You can use the probes provided or click Edit to select different probes. Click New to create a custom probe. Discovery Identifiers 77 Configuring Identifiers When enabled, Identifiers collect information gathered by identity probes and use that data to search for matching CIs in the CMDB. Using the scripting power of the Identifier, you can control the order in which the identification criteria is parsed for comparison with the CMDB, and you can configure how Discovery should handle each matched or unmatched device. You create identifiers for each identity probe command that you run in your network. For example, if you query devices for network names, device serial numbers, and MAC addresses, then you must create matching identifiers that define how each piece of data should be evaluated. Processing Flow for Discovery Identifiers Identity probes and sensors are used to determine if the devices you discover in your network already exist in your CMDB. Multisensors used for this purpose must be configured to pass identification data to Identifiers. The Identifiers then determine how to proceed for each device discovered, based on the result states. The Identifiers pass the result state for a discovered device back to the identity sensors, which respond appropriately, either by launching additional exploratory probes to continue discovering the device or by taking no further action on the device. Discovery Identifiers 78 Identifier Form To create an Identifier record, navigate to Discovery Definition > CI Identification > Identifiers and click New. The Identifier form provides the following unique fields: Field Input Value Applies to Select the ServiceNow table of the device class for this Identifier. For example, if the class is Printer, then the table is cmdb_ci_printer. Order Configure the order in which the identification criteria are evaluated. An example might be serial number - 910, network name - 920, and computer name - 930. Script Create the conditions that determine what Discovery should do when the results are returned from a search of the CMDB for this Identifier. For example, you might want to stop Discovery if two or more CIs in the CMDB match this Identifier. Or you might want to evaluate additional Identifiers even after a match has been established with this Identifier. Use the scripting methods described below to tell Discovery how to respond. The completed Discovery Identifier form looks like this: Discovery Identifiers 79 Result States The following table shows how the possible Discovery Identifier result states are used to decide the outcome of an identity probe: Continue Discovery Create CI Exactly one device matched in CMDB Yes No Device not matched in CMDB Yes - if the device has matchable information available, such as IP address, MAC address, or class, and if there are no multiple matches. Yes - if the device has matchable information available, such as IP address, MAC address, or class, and if there are no multiple matches. Multiple devices matched in CMDB No No Discovery Identifiers 80 Evaluation Order For Custom Identifiers If you create new Identifiers, make sure you assign them a different Order value than that of the out-of-box Identifiers. Discovery runs the Identifiers in sequence from low order numbers to high. You can create identifiers to run before or after the out-of-box Identifiers, or mixed in with the out-of-box Identifiers. To prevent any Identifier from running, disable it by changing the Active flag to false. Out-of-Box Identifiers The following Identifiers are included in the out-of-box ServiceNow system. Identifier Description Details Serial Number Table & Class Name Identify CIs in the CMDB based on serial number(s) in the serial number table and sys_class_name. This identifier matches the discovered serial number against the serial_number in the Serial Number [cmdb_serial_number] table. If the discovered serial number matches a CI in the cmdb_serial_number table and the class name, then the CI is declared identified. Note that in the out-of-box system, Discovery populates the cmdb_serial_number table. Therefore, this identifier is important for Discovery to use to find the CIs it has discovered in the past (assuming these were valid serial numbers). Serial Number & Class Name Identify CIs in the CMDB based on the serial_number field and matching sys_class_name. This identifier matches the discovered serial numbers against the serial number field in the base CI record. If a discovered serial number and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. For example, a computer and a printer have the same serial number, but since their class name differs, Discovery will not identify them as the same CI. Typically, imported data has the serial number field completed, but no matching value in the cmdb_serial_number table. This identifier solves the issue of Discovery finding imported data in the CMDB. Name & Class Name Identify CIs in the CMDB based on name field and matching sys_class_name. This identifier matches the discovered name against the name field in the base CI record. If a discovered name and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. For example, a computer and a printer have the same name, but since their class name differs, Discovery will not identify them as the same CI. Network Identify CIs in the CMDB based on IPs and MAC Address(es) in the network adapter table. This identifier matches the discovered network adapters against those in the Network Adapter [cmdb_ci_network_adapter] table, using the IP address and MAC address. If all the discovered network adapters match a CI in the network adapter table, then the CI is declared identified. Discovery Identifiers 81 Network & Class Name Identify CIs in the CMDB based on the mac_address field and the ip_address field and matching sys_class_name. This identifier matches the discovered IP address and MAC address of the base CI against those in the base CI record. If a discovered IP address, MAC address and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. MAC Address & Class Name Identify CIs in the CMDB based on the mac_address field and matching sys_class_name. This identifier matches the discovered MAC address of the base CI against those in the base CI record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. IP Address & Class Name Identify CIs in the CMDB based on the ip_address field and the matching sys_class_name. This identifier matches the discovered IP address of the base CI against those in the base CI record. If a discovered IP address and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. MACAddress Identify CIs in the CMDB based on MAC Address(es) in the network adapter table. This identifier matches the discovered MAC address of the base CI against those in the base CI record. If a discovered MAC address and class type (sys_class_name) matches a CI, then that CI is declared identified. The matching class name requirement means that Discovery will not identify CIs that are not in the same class. Generic Serial Number Identify CIs in the CMDB based on serial_number field. This identifier matches the discovered serial number against the serial number field in the base CI record. If a discovered serial number matches a CI, then that CI is declared identified. Note here that the matching class name is NOT a requirement, which means that Discovery will identify CIs even if they are not in the same class. For example, a computer and a printer have the same serial number, but even though their class name differs, Discovery will still identify them as the same CI. Generic Network Identify CIs in the CMDB based on the mac_address field and the ip_address field. This identifier matches the discovered IP address and MAC address of the base CI against those in the base CI record. If a discovered IP address and MAC address matches a CI, then that CI is declared identified. The matching class name is NOT a requirement, which means that Discovery will identify CIs that are not in the same class. Generic Name Identify CIs in the CMDB based on name field. This identifier matches the discovered name against the name field in the base CI record. If a discovered name matches a CI, then that CI is declared identified. The matching class name is NOT a requirement, which means that Discovery will identify CIs that are not in the same class. Generic MAC Address Identify CIs in the CMDB based on MAC address field. This identifier matches the discovered MAC address of the base CI against those in the base CI record. If a discovered MAC address matches a CI, then that CI is declared identified. The matching class name is NOT a requirement, which means that Discovery will identify CIs that are not in the same class. Generic IP Address Identify CIs in the CMDB based on IP address field. This identifier matches the discovered IP address of the base CI against those in the base CI record. If a discovered IP address matches a CI, then that CI is declared identified. The matching class name is NOT a requirement, which means that Discovery will identify CIs that are not in the same class. Credentials 82 Credentials Overview Credentials, such as user names and passwords, or certificates, are required to gain access to a computer or network device for ServiceNow Discovery or to perform work on a computer using Runbook Automation. The platform stores these credentials in an encrypted field on the Credentials table, and once they are entered, they cannot be viewed. Versions at Berlin or later can use a feature called credential tagging to assign individual credentials to any activity in a runbook workflow or assign different credentials to each occurrence of the same activity type in a runbook workflow. Credential tagging also works with credential affinities. Credential Affinity It is not necessary to associate credentials with a device within Discovery. When Discovery or Runbook first attempts to access a device, they try all available credentials until they find the correct ones. After identifying the credentials for a device, Discovery and Runbook create an affinity between the credentials and the device using the Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Runbook activities attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device change, Discovery and Runbook try all available credentials again until they create a new affinity. Note: If Runbook and Discovery are installed, and if credential tagging is enabled, multiple affinities can exist. In this case, the platform looks up credentials for each affinity and inserts the credential for the affinity with the lowest order into the probe. Encryption/Decryption Credentials are encrypted automatically with a fixed instance key when they are submitted or updated in the Credentials [discovery_credentials] table. When credentials are requested by the MID Server, the platform decrypts the credentials using the following process: 1. The credentials are decrypted on the instance with the fixed key. 2. The credentials are re-encrypted on the instance with the fixed Web Service key. 3. The credentials are encrypted on the instance with SSL. 4. The credentials are decrypted on the MID Server with SSL. 5. The credentials are decrypted on the MID Server with the fixed Web Service key. Credentials 83 Note: The platform does not have separate encryption keys for multi-tenant instances. Discovery and Runbook Credentials The MID Server must have the proper credentials for the devices it expects to find. Windows MID Servers use the login credentials of the MID Server service on the host machine to discover Windows devices in the network. This login is configured when the MID Server is installed and must have domain or local administrator privileges. For Linux and UNIX machines and network devices, the MID Server uses the SSH and SNMP credentials configured in the ServiceNow instance in Discovery > Credentials. MID Servers used by Runbook must have access to the necessary credentials to execute commands on computers in the network as specified by the Workflow activities. Runbook can use the same SSH and SNMP credentials as Discovery, but has two additional credentials designed for specific Workflow activities: Windows (for PowerShell) and VMware. UNIX and Linux Credentials Discovery and Runbook explore UNIX and Linux devices by using commands executed over SSH, so they need SSH credentials. The user can be any user. Both applications must run commands on UNIX and Linux systems with root privileges. There are two general approaches to accomplishing this: Give root credentials. These are obviously the most powerful credentials, but may not be desirable from a security perspective. If Discovery or Runbook have the root credentials to any UNIX or Linux system, then no further configuration is required. Give other credentials for Discovery or Runbook, but grant the user in those credentials the right to execute certain commands with root privileges, using sudo [1] . This is a secure way to grant limited privileges. Discovery or Runbook use sudo on any probe that has the must_sudo parameter set to true (it defaults to false). However, each system must be configured to allow sudo to work. This is done by editing the /etc/sudoers file using the visudo command). Configuring sudo Commands to Grant Root Privileges Each command for which Discovery or Runbook requires root privileges is described below, along with how to configure the /etc/sudoers file to allow them. These examples assume that the user name in the credentials is Disco. Substitute the actual user name and ensure that the paths for the commands match the path on the systems. Note: Sudo commands do not work with private key credentials, because there is no password to supply to the sudo command. A solution is to add the NOPASSWD option to the sudo configuration. For example, you might enter: disco ALL=(root) NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig. UNIX/Linux commands requiring root privileges for Discovery and Runbook Credentials 84 Command Platform(s) Purpose /etc/sudoers line example Used By dmidecode All Linux Gathers several pieces of information about the hardware, including the serial number embedded within the motherboard. Disco ALL=(root) /sbin/dmidecode Discovery lsof All Linux and Mac versions Determines the relationship between processes and the connections being made to the system. Disco ALL=(root) /sbin/lsof Discovery vmware-cmd ESX Gathers vmware instances information Disco ALL=(root) /usr/bin/vmware-cmd Discovery adb HP-UX Gathers CPU speed and memory Disco ALL=(root) /usr/bin/adb Discovery chpasswd All Linux and UNIX versions Changes user passwords. Disco ALL=(root) /etc/chpasswd Runbook chage All Linux and UNIX versions Changes the number of days between password changes and the date of the last password change. Disco ALL=(root) /etc/chage Runbook oratab All Unix versions Grants read access to the oratab file for locating the Oracle Home and pfile. N/A Discovery Windows Credentials Windows credentials are used differently by Discovery and Runbook. Discovery Discovery explores Windows computers using Microsoft's secure remote architecture to run remote WMI queries and to access the administrative share. This access must use Microsoft components and must run in the context of a Windows user with the required privileges. Discovery accomplishes this by using a MID server installed as a Windows service with either Windows domain administrator privileges, or with local administrator privileges for the computers being discovered. This ensures that the MID Servers can query all Windows devices in an IP address range. Local security policies may vary. Runbook Runbook activities in the out-of-box system that run commands on Windows machines can use Windows PowerShell [4] credentials (from the ServiceNow Credentials table) or the domain administrator credentials of the MID Server service. If Runbook cannot find PowerShell credentials in the Credentials table (of the type Windows), Runbook uses the login credentials of the MID Server service. The advantage to using PowerShell is that one MID Server can execute Runbook activities across multiple domains, reducing the number of MID Servers required. Credentials 85 SNMP Credentials Discovery explores many kinds of devices (switches, routers, printers, etc.) using the SNMP protocol. Credentials for SNMP do not include a user name, just a password (the community string). The default read-only community string for many SNMP devices is public, and Discovery will try that automatically. Enter the appropriate SNMP credentials if they differ from the public community string. The default Runbook activity SNMP Query returns the OID of a device and requires SNMP credentials. VMware Credentials Discovery can explore VMware's vCenter running on a Windows machine. When Discovery detects the vCenter process running on the machine, Discovery automatically launches the VMware - vCenter probe. This probe logs into the vCenter instance with the credentials provided and uses the vCenter API to return information about ESX machines, virtual machines, and resource pools. Ensure that the credential Type selected is VMware. Runbook requires vCenter credentials for any work that it performs on vCenter, such as cloning a virtual machine. Note: Do not use VMware type credentials for Runbook activities that perform work on the individual virtual machines cloned by vCenter (for example, restarting a Linux VM). For these activities, the credential Type depends on the operating system of the virtual machine (either SSH or Windows). Credential Order When Runbook attempts to run a command on an SSH server (such as a Linux or UNIX machine), or when Discovery attempts to query an SNMP device (such as a printer, router, or UPS), the application tries the credentials in the Credentials table randomly, until it finds one that works. Credentials can be assigned an order value in the Credentials Form, which forces Discovery and Runbook to try all the credentials at their disposal in a certain sequence. Ordering credentials is useful in the following situations: The credentials table contains many credentials, with some used more frequently than others. For example, if the table contains 150 SSH credentials, and 5 of those are used to log into 90% of the devices, it is good practice to configure those five with low order numbers, which places them at the top of the execution list. Discovery and Runbook will work faster if they try these common credentials first. After the first successful connection, the system knows which credentials to use the next time for each device. The system has aggressive login security. For example, if the Solaris database servers in the network only allow three failed login attempts before they lock out the MID Server, configure those credentials with a high order value. Credentials 86 Other Considerations Sometimes computers or devices have additional security measures configured, and these measures may interfere with the MID Server's ability to run commands or queries on those systems. For example, a Linux server might be configured to allow only certain IP address to connect to it via SSH. Similarly, a network router might be configured to allow only certain IP address to query SNMP on it. To allow access in such cases, use one of the following methods: Update the configuration of those computers or devices to allow the desired MID Server to run commands or query them. For example, a network router may be configured to only allow the network management systems to query SNMP on it. In that case, add the MID Server as though it were another network management system. Install a MID Server on a computer that already has access to the computers or network devices with such restrictions. For example, to use Discovery within a DMZ (where communication from outside the DMZ will be severely restricted), install a MID Server on a computer that is already in the DMZ. Credentials Form The Discovery Credentials form provides the following fields: Field Input Value Name Unique and descriptive name for this credential. For example, you might call it SSH Atlanta. Type Select between SSH, SNMP, and VMware credentials. SSH: Credentials for all Linux and UNIX devices. SSH Private Key: Certificate-based identification for Linux and UNIX devices. SNMP: This credential is a community string. If you select this, ServiceNow automatically uses public first and then a community string. Windows: Credentials required for Windows machines accessed by Runbook activities. These credentials are used for running PowerShell commands on Windows machines. VMware: Credentials required by probes that access or run commands on vCenter. For more information, see Discovery for VMware vCenter and VMware Workflow Activities. MSSQL: Credentials used for discovering Microsoft SQL instances when using SQL authentication with PowerShell. Enable SQL authentication by setting the mid.powershell.use_mssqlauth parameter to true in the MID Server config.xml file. User name Enter a user name for this type of credential. Avoid leading or trailing spaces in user names. These spaces can prevent the VMware - vCenter probe from connecting to vCenter. Password Type the password to use. If you have selected SNMP type credentials, you type the community string here. Order The order (sequence) in which the platform tries this credential as it attempts to log onto devices. The smaller the number, the higher in the list this credential appears. Establish credential order when using large numbers of credentials or when security locks out users after three failed login attempts. If all the credentials have the same order number (or none), Discovery or Runbook tries the credentials in a random order. SSH passphrase Type a secure SSH passphrase. This field is available only for SSH Private Key credentials. SSH Private Key Enter a secure, private key that can be used instead of a password for SSH logins. This field is available only for SSH Private Key credentials. MID servers Select one or more MID Servers from the list of available MID Servers. The credentials configured in this record are available to the MID Servers in this list. This field is available only when you select Specific MID servers from the Applies to field. Applies to Select whether to apply these credentials to All MID servers in your network, or to one or more Specific MID servers. Specify the MID Servers that should use these credentials in the MID servers field. Active Enable or disable these credentials for use. A completed credentials form for an SSH credential could look like this, but local configurations can vary: Credentials 87 References [1] http:/ / www. sudo. ws/ sudo/ sudo. html Discovery Schedules Overview The Discovery Schedule form is the starting point for all Discovery activities. The schedule determines what is going to be discovered, when it will be discovered (the day and time), and how Discovery will be performed (the MID Servers to use). You use the Discovery Schedule module to: Configure device identification by IP address or other identifiers. Determine if credentials will be used in device probes. Name the MID Server to use for a particular type of Discovery. Create or disable a schedule that controls when Discovery runs in your network. Configure the use of multiple MID Servers for tasks such as load balancing. Run Discovery manually. Prerequisites Before you begin with Discovery, configure the following: MID Servers: Install and configure one or more MID Servers. Credentials: Provide the MID Servers with the login credentials they need to query the various devices in the network. Schedules: Create a schedule record that defines what actions Discovery must take to scan the devices and software in the network. Classifications: Make sure the device and process classifications provided in the base platform are sufficient. Create new classifications as needed for the devices, processes, and applications in the network. Discovery Schedules 88 Solaris Serial Number Probe An exploration probe and accompanying sensor, included in the baseline system, enable Discovery to detect the serial numbers of Solaris devices. This probe, called Solaris - Serial Number, requires the installation of a command line tool from Sun Microsystems called SNEEP. To download and install [1] this tool, log onto the Oracle website. After this tool is installed, the serial number probe runs automatically when Discovery detects a Solaris device. Schedule Form To access a list of Discovery Schedules, navigate to Discovery > Discovery Schedules. The scheduler form provides the following fields: Field Input Value Name Type a unique, descriptive name for your schedule. Discover Select one of the following types: Configuration items: Configuration item scans use Discovery Identifiers to match devices with CIs in the CMDB and update the CMDB appropriately. You can perform a simple Discovery by selecting a specific MID Server to scan for all protocols (SSH, WMI, and SNMP), or perform more advanced discoveries with Discovery Behaviors. When you select a behavior, the MID Server field is not available. IP addresses: Select this type of scan to discover devices without the use of credentials. IP address scans discover all the active IP addresses in the specified range and create device history records, but do not update the CMDB. IP address scans also show multiple IP addresses that are running on a single device. Devices are identified by class and, in some cases, by type, such as Windows computers and Cisco network gear. Networks: Use this selection to discover IP Networks (routers and switches). Results from this search are used to populate the IP Network table (cmdb_ci_ip_network) in Discovery > IP Networks with a list of IP network addresses and network masks. Network Discovery updates routers and layer 3 switches in the CMDB. Behavior Select a Behavior that you have configured for the MID Servers in your network. When you select a behavior, the MID Server field is no longer visible. Use a Behavior when a single schedule requires the use of multiple MID Servers to perform any of the following: Scans requiring multiple Windows credentials. A schedule that must execute two or more particular scan types (SNMP, SSH, or WMI) using more than one MID Server. Load balancing for large discoveries where a single MID Server would be inadequate. Scanning multiple domains This field is available only for Configuration items scans. MID Server Select the MID Server to use for this schedule. This field is available for Configuration items and Networks scan types. If you select a MID Server, you cannot select a behavior to run on the same Discovery. 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. Location Pick a location to assign to the CIs that are discovered by this schedule. If this field is blank, then no location is assigned. Max Run Time Set a limit to the amount of time Discovery can run on this schedule. When the configured time elapses, the remaining tasks for this Discovery are cancelled, even if the scan is not complete. Use this field to limit system load to a desirable time window. If no value is entered in this field, this schedule will run until complete. Active Select the check box (true) to enable this schedule. If you clear the check box, the schedule for this action is disabled, but you can still run Discovery manually from this form, using the configured values. Include alive Select this check box to include all devices that have at least one port that responds to the scan, but no open ports. Discovery knows that there is a device there, but doesn't known anything about it. If this check box is not checked, Discovery returns all active devices (those that have at least one open port). Log state changes Select this check box to create a log entry every time the state changes during a Discovery. View the Discovery states in the Completed activity and Current activity fields in the Discovery Devices list in the Status form. An example of a state change is when Discovery for a specific device goes from Active to Classifying. Discovery Schedules 89 Run Select when to run Discovery on this schedule: daily, weekly, etc. If you select Once, Discovery runs one time only, when you update the record. Day Select a day of the week on which to run Discovery on this schedule. This field appears when you select a Weekly or Monthly schedule. You can select a particular day of the week or any day of the month. Time Select the time of day this schedule should run. All times are local and use a 24 hour clock. Repeat Interval Select the number of days between scheduled Discovery runs. This selection is available when you choose Periodically in the Run field. Quick Ranges Define IP addresses and address ranges to scan by entering IP addresses in multiple formats (network, range, or list) in a single, comma-delimited string. For details, see Quick Ranges in this page. Discovery IP Ranges This related list defines the ranges of IP addresses to scan using this schedule. If you are using a simple CI scan (no behaviors), this is the way to define the IP addresses to discover. Discovery Range Sets Each range set in a schedule defines IP addresses that will be scanned using this schedule. All the range sets listed will be scanned by this schedule. Note: You can run a Discovery scan manually at any time using the settings in a schedule record by clicking Discover now under Related Links. This action does not affect the schedule. The schedule will run as configured, despite manual execution. A completed Discovery Schedule looks like this: Discovery Schedules 90 Configuring IP Addresses You can select the IP address you want to discover by using the following formats: IP Address List IP Address Range IP Network Use one or more of these methods in any combination to define your network or network segment for Discovery to query. Note: If you do not know the IP addresses in your network to scan, run Network Discovery first to determine your IP networks, and then convert the IP networks into IP address range sets. IP Address List Use IP address lists to add individual addresses for Discovery to query that are not included in any range or network specified. You have a choice of entering the IP address of the device or a host name (DNS name). If you configure a host name, it must be resolveable from the ServiceNow instance. IP Address Range You can define arbitrary ranges of IP addresses for Discovery to query. This is a good way to include selected segments of a network or subnet, but you must ensure that you include only the addresses of single, manageable devices in the network. Discovery has no way of knowing if the network or broadcast addresses are included in the range, and so must ping all the addresses in the range. If the network and broadcast addresses are included, then the results are inaccurate. For this reason, discoveries configured to detect IP networks are generally more accurate than those configured for IP address ranges. IP Network An IP network includes the range of available IP addresses in that network, including the network address (the lowest address in the range) and the broadcast address (the highest address in the range). An example of a class C network range is 192.168.0.0 to 192.168.0.255. In the Range Set form, this network can be entered using either of the following notations: 192.168.0.0/24 192.168.0.1/255.255.255.0 This lets Discovery know that it is scanning an IP network, and that it should not scan the highest and lowest numbers in the range. This prevents significant errors from being introduced into the Discovery data by the broadcast address, which returns all the devices in the network, and the network address, which can add an arbitrary number of redundant devices. Because of this built-in control, IP Networks are the best method of telling Discovery what ranges of IP addresses to query. Discovery Schedules 91 Quick Ranges Feature To create IP address ranges, networks, and lists quickly, click the Quick Ranges link under Related Links. This feature enables an administrator to define IP addresses to scan by entering all three formats in a single, comma-delimited string. For example, type 10.10.10.0/24,10.10.11.0-10.10.11.165,10.10.11.200,10.10.11.235 to scan addresses in a network, a range, and a list without having to create three separate records. Note: The Quick Range interface is for the entry of IP addresses only and cannot be used to edit IP addresses that have already been submitted. When the Quick Ranges definitions are submitted, the instance automatically displays each in the proper format. To make any changes to the IP address ranges, drill into these records. Discovery Schedules 92 Excluding IP Addresses Specific IP addresses in a range or network might need to be excluded from an established Discovery Schedule. This is necessary if a subnet contains critical-use devices that cannot be discovered due to a local policy that prevents interacting with those devices. An example of a device that might be excluded is one with an intentionally unorthodox configuration that causes an authentication issue each time it is discovered. 1. In the Discovery Schedule, click the link for the Type of IP address range that contains the address to exclude. For example, if we want to exclude 10.10.10.82, we select the IP Network for 10.10.10.0/24, the range of IP addresses that contains our target address. The Discovery IP Range form appears. 2. Click New in the Discovery Range Item Excludes Related List. 3. In the Discovery Range Item Exclude form, select a Type for the excluded IPs. For example, select IP Address List to exclude a single IP address or multiple IP addresses that are not sequential. Discovery Schedules 93 4. Right-click in the record's header bar and select Save from the pop-up menu. The Discovery Range Item IPs Related List appears. 5. Click New in this list. An entry form for the IP addresses or hostnames to exclude appears. 6. Enter a single IP address to exclude or multiple addresses separated by commas, and then click Submit. The excluded IP address appears in the Discovery Range Item IPs Related List at the bottom of the Discovery Range Item Exclude form for that IP address Type. 7. Click Update to save your excluded address and return to the Discovery Schedule. Discovery Schedules 94 References [1] https:/ / login. oracle. com/ mysso/ signon.jsp Network Discovery Note: If you already know the IP address ranges in your network, it is not necessary to run Network Discovery. This procedure is intended for organizations that do not have complete knowledge of the IP addresses available for Discovery in their networks. Overview Network Discovery discovers the internal IP networks within your organization. Discovery uses the information it gathers to update routers and Layer 3 switches in the CMDB. Network Discovery is performed by a single MID Server that begins its scan on a configurable list of starting (or seed) routers. Typically, the starting routers are the default routers used by all the MID Server host machines in the network, but can be any designated routers. The MID Server uses the router tables on the starting routers to discover other routers in the network. The MID Server then spreads out through the network, using router tables it finds to discover other routers, and so on, until all the routers and switches have been explored. After running Network Discovery, convert the IP networks it finds into IP address Range Sets that you use in Discovery Schedules to discover configuration items (CI). Note: As of the Aspen release, SNMP MIB uses a new synching method. This change should not negatively affect existing custom MIBs. Also, remote attachments are no longer used. Running Network Discovery Configure Network Discovery in a Discovery Schedule. 1. Navigate to Discovery > Discovery Schedules. 2. Click New and select Networks from the list in the Discover field. 3. Select a MID Server. This field is mandatory. 4. Complete the form, including the schedule. 5. Right-click in the header bar and select Save from the pop-up menu. The Related Links and Related Lists appear. 6. Click Network Discovery Private IPs in Related Links to view the list of default private IP networks in the Discovery IP Ranges Related List. The default IP networks in this list are available to every Network Discovery you conduct and are sufficient for most discoveries. 7. If your organization has additional private IP addresses, click New to add them. Network Discovery 95 8. Add starting routers to the schedule in the Discovery Range Sets list. a. Click the Network Discovery Auto Starting Routers link to populate the list with the starting router for each MID Server in your network. b. Click Edit to add or delete routers from the list. 9. Run Discovery manually, or through the scheduler. Converting IP Networks into Discovery Range Sets After you conduct the Network Discovery, you must convert the IP networks that were found to range sets for use in discovering other devices. 1. Navigate to Discovery > IP Networks. 2. Click New to add an IP network. The IP Networks form appears. 3. Ensure that the following field values are provided: State: Ready Discover: true Router: Select a router from the list. This field must not be empty. If your IP Networks were created through Network Discovery, then these fields will be populated automatically in the IP Networks Related List. However, if you entered the IP Networks manually, and you want to convert your IP Networks into range sets through the UI Action, you must edit these field accordingly. Network Discovery 96 4. Click Update to return to the list. 5. Click the Create Range Sets Related Link. This converts all the IP networks in the list to range sets. The Discovery Status page appears, displaying the progress of the conversion. Depending upon the number of IP networks you have, you will see the Started and Completed count increment until all the networks are converted. Network Discovery Properties The following properties control how Network Discovery works. The default values are correct for most discoveries. Navigate to Discovery Definitions > Properties to edit the properties. Property Description Default BGP Router Exploration Disable Controls whether Network Discovery exploration of routers running the BGP protocol is disabled. Normally such exploration IS disabled because of the huge size of BGP routing tables, and because generally such routers are only operating at the edge of large networks where further network discovery would be irrelevant. The only time this value should be set to "no" is in the unlikely case that your organization uses BGP routers as edge routers between relatively small networks (such as between buildings on a single campus). Yes Network Discovery 97 Maximum Netmask Size for Discoverable Networks (bits) The maximum number of bits in a regular netmask for networks that will be discovered by Network Discovery. By "regular netmask" we mean a netmask that can be expressed in binary as a string of ones followed by a string of zeroes (255.255.255.0 is regular, 255.255.255.64 is irregular). Regular networks are commonly expressed like this: 10.0.0.0/24, which means a network address of 10.0.0.0 with a netmask of 255.255.255.0. Larger bit numbers mean networks with smaller numbers of addresses in them. For example, the network 10.128.0.128/30 has four addresses in it: one network address (10.128.0.128), one broadcast address (10.128.0.131), and two usable addresses (10.128.0.129 and 10.128.0.130). Small networks like this are commonly configured in network gear to provide loopback addresses or networks used strictly by point-to-point connections. Since these sorts of networks generally don't need to be discovered by Network Discovery, it would be useful to filter them out. By setting this property to a value of 1 through 32, you can limit the sizes of regular networks that are discovered. Setting it to any other value will cause all networks to be discovered. Irregular networks are always discovered. The default value is 28, which means that regular networks with 8 or fewer addresses will not be discovered. 28 Network Router Selection Method This property controls the method used to decide (during Network Discovery) which router should be selected as the router to be associated with a given IP Network. The possible values are: "First Router" (the first router that discovers the network is associated), "Last Router" (the last router that discovers the network is associated), "Most Networks" (the router with the most attached networks is associated), and "Least Networks" (the router with the least attached networks is associated). Most Networks Physical Interface Types A comma-separated list of interface types that will be considered "physical" for the purposes of network discovery. In other words, if a router (or device capable of routing) has an interface of this type, the networks connected to that interface will be considered locally connected to that device. The default interface types include Ethernet, 802.11, and Token Ring types. Interface type numbers are defined in the SNMP MIB-2, specifically in OID 1.3.6.1.2.1.2.2.1.3. 6,117,9,71,209 Switch Interface Types List of interface types (comma-separated) that will be considered Interface type numbers are defined in the SNMP MIB-2, specifically in OID 1.3.6.1.2.1.2.2.1.3. Devices with any interface types that do not appear in this list will be classified as routers (if they have routing capability). A complete list of the interface type numbers may be found on the IANA web site, in the section "ifType definitions". 7,8,9,26,53,62,69,71,78,115,117,209 Stale Network Discovery Threshold (Days) The number of days before which discovered information about network gear is considered "stale". While performing network discovery, if a router (or other device capable of routing) has not been discovered, or if the discovered information is stale, then network discovery will launch probes to freshen the information. Otherwise, it will reuse the information that has already been discovered. If this number is negative, then any previously discovered information is always considered stale, and network discovery will always launch probes to freshen the information. -1 Network Discovery Debugging Enables extensive logging (for debugging purposes) of all Network Discovery activities on the instance. Normally this is only set to "yes" by developers. Yes Discovery Status 98 Discovery Status Overview The Discovery Status interface (Discovery > Status) displays all the details of a Discovery. Each record in the Status list represents the execution of a Discovery by a schedule and displays such high level information as the date of the Discovery, the mode, the number of probe messages sent to devices, and the number of sensor records that were processed. From this record, you can drill down into the following data: Probe and sensor records, including the instructions given to the probes and the information returned The relationships between the probes and sensors All log entries for the Discovery Specific information about devices discovered Use this data to troubleshoot the behavior of individual probes and sensors or even run those elements separately. Use the status controls to enter probe/sensor threads at any point for a specific Discovery, and then follow the process in either direction. Discovery Status Record By default, only 30 days of Discovery records are displayed in the status list at a time. The status record provides the following fields: Field Input Value Number Discovery record ID generated by your ServiceNow instance. Description How this Discovery was run. Typically, the description is Scheduled, but if you ran Discovery manually from a Schedule, the record would show Discover Now in the Description field. If the scan was performed by the Help the Help Desk application, this description is Help the help desk. Schedule The name of the Discovery schedule. State Indicates the state of this Discovery (Active, Completed, etc.) Started The number of probe messages sent to devices from the MID Server. Completed The number of sensor records that were processed. This number must match the number of probes launched. From Schedule Discover Shows the Discovery type. The possible types are: Configuration items, IP addresses, or Networks. Max Run Time Displays the maximum amount of time Discovery was permitted to run on this schedule. Include alive Indicates that this Discovery includes devices on which one port responded to the scan, but no ports are open. Such a device is considered to be alive. If this check box is not selected, only active devices with one or more open ports that Discovery can query are displayed. Log state changes Indicates that state changes were logged during this Discovery. Discovery states can be seen in the Last and Current fields in the Discovery Devices list in this form. A Discovery Status record looks like this: Discovery Status 99 Discovery Timelines A Discovery Timeline generates a graphical display of the ECC Queue for a Discovery, including information about each probe and sensor running. To display a timeline, click the Show Discovery Timeline Related Link on any Discovery Status form. No additional configuration is required. Use Discovery Timelines to display the following: The flow of probes and sensors through a Discovery The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing and processing Tooltips containing additional data about a probe or sensor Records from the ECC Queue Discovery Status 100 Discovery Log The Discovery Log displays all the activity for this Discovery, including such things as classification failures, CMDB updates, and authentication failures. From this list, click a link in the CMDB CI column to drill into the record for that CI or click the link in the Created column to view an individual log record. To view the log records for a particular device, click the IP adddress link in the Device column. This action opens the Discovery Devices record. Log Information The Discovery Log provides the following information: Field Input Value Created Timestamp of the Discovery activity. Each timestamp defines the approximate time of the activity. Several Discovery events may occur in random order within a second. Level Classifies the activity into one of the following levels for general sorting: Error Information Warning Message Informative message detailing the outcome of the activity or the Discovery progress. Look here for the result of a classify probe or for authentication failure. Source Names the particular activity, such as the Shazzam probe or a UNIX classify probe. CMDB CI Names a device for which a matching CI was found in the CMDB. Click this link to drill down into the CI record for the device. Sensor Names the sensor that processed the results of a specific probe that was run. This field also indicates if the probe was a MultiProbe. Click this link to view the sensor record, including the package that was processed. Device Lists the IP address of the CI discovered. All devices identified by IP address appear in the log, even if they refused all invitations to communicate. Any port activity from a device places it into the log, even if all subsequent efforts to identify it fail. Click the IP address of the device to view the events associated with discovering that device. Discovery Status 101 Filtering the Log Sort the log by different values to create your view of Discovery activities. Use the breadcrumbs above the header bar to return to a previous view. To filter the list quickly by a specific target value, right-click in any column and select Show Matching or Filter Out. For example, show only the Warning level activities, and then select the specific type of failure to display from the Message field, such as SSH Authentication or connection failure. Devices Select the Devices Related List to view a summary for all the devices scanned. During a Discovery, the list tracks current and completed activity and displays an incremental scan counter. When Discovery is finished for a device, the final disposition is displayed in the Completed activity column. Successful Discoveries that result in updated or created CIs are highlighted in green. To view the log entries for errors (such as connection failure) on a specific device, click the Details link in the Issues column. Click on the IP address of a device in this list for details about that device. The log results for that device are displayed in the list at the bottom of the form. Discovery Status 102 If there were issues, or if Discovery failed to complete, click the Details link to view the log records for the issue. The failure of any probe is considered an issue, even if the device was eventually classified properly and updated in the CMDB. The following information is displayed in this form: Field Input Value Source The IP address of the device discovered. Completed activity Indicates the outcome of Discovery for this device or the last completed activity for a Discovery in progress, such as Identified CI. Successful outcomes are indicated in green. Current activity The current scanning activity for this device for a Discovery in progress, such as Updating CI. CMDB CI The name of this device as it appears in the CMDB. Started The number of device-specific probes run. This number does not include the universal probes, Shazzam and Ping, that run initially. Completed The number of sensor records created from the device-specific probes that were run. Scan status Shows the final scan count of a completed Discovery or an incremental scan counter for a Discovery in progress (e.g. Scan 17 of 19). Issues Displays the number of issues encountered during Discovery of this device. Select the Discovery Log Related List to view these issues. Fields which can be added by personalizing the form: DNS Names Displays DNS names for each discovered device. This field was added for the October 2011 Preview 1 release. Discovery Status 103 IP Address Scan Data When Discovery scans for IP addresses only (without credentials or identifiers), no updates are made to the CMDB. All IP addresses discovered appear on this list, including multiple IPs on the same device. The results of IP address scans include slightly different information than the results of a CI scan. Since there is no CMDB activity associated with the IP address scan, the Completed activity column displays only the classification status. Possible statuses are: Classified Unclassified Alive, not classified For Classified devices, Discovery might identify the type of device in the Current activity column. For example, Network Gear might be classified as Cisco Network Gear, and a Computer might be classified as a Windows Computer. ECC Queue The External Communication Channel (ECC) Queue lets you see all probe and sensor records for a particular device for a particular Discovery. You can drill down in the ECC Queue from the beginning to the end of the Discovery, or drop into the sequence of probes and sensors at any point. To open the ECC Queue, open a Discovery Status record, and then select ECC Queue from the Related Links. You can sort the list by the timestamp or select any probe or sensor record that interests you. You can see what activity launched the probe or answered the sensor's commands and track the processing order for a Discovery in either direction. To determine whether a record is for a probe or a sensor, look at the value in the Queue column. Sensor records are in the input queue, and probe records are in the output queue. This view of the ECC Queue is the best way to see the Shazzam and Ping probes without extensive drilling. Ping probes can be chunked up to reduce the delay in returning results. The chunking of Ping probes is controlled by a property in Discovery Definition > Properties called Max ping chunk size. This property is described as the maximum number of IPs that will be pinged in one "chunk" of work. If a Discovery range has more than this number of IPs in it, it will be automatically broken up into chunks no larger than this parameter's value. Discovery Status 104 Probe and Sensor Activity The ECC Queue provides you with a connected flow of probe and sensor activity. The position of records in the list is dependent on your sorting criteria and might not represent the processing order of the Discovery. Activity is recorded (Created date) when the probe is launched or the sensor records the response in the instance. On a busy system, sensor input might be queued in the instance and delayed from being recorded. Sensors can launch multiple probes that require different intervals to respond. A probe record displays the instructions it was given when it was launched, and the sensor record shows the probe instructions and the results of the probe. All this information is checked into the instance. To track the processing sequence, use the following methods: To track the flow of probes and sensors deeper into the Discovery (toward completion), drill down using the Queue Related List at the bottom of the ECC Queue record. This list displays the next activity in the Discovery, by either a probe or a sensor. If the Queue list is empty, then that branch of the Discovery is complete. Multiple entries means that the sensor in the current record launched multiple probes. To track backwards toward the beginning of the Discovery, drill down using the Related Field icon in the Response to field. This action opens the ECC Queue record for the activity that spawned the current probe or sensor record. ECC Queue Fields An ECC Queue record provides the following fields: Field Input Value Agent The name of the MID Server that initiated the probe. Topic Type of probe or sensor that was active (SSH, WMI, or SNMP). Name Identifying name of the probe or sensor. For SSH probes, this is the probe's message. For all others, the name is an identifying string generated by the instance. Source The IP address of the Discovered device. The Shazzam and Ping probes do not have a source IP associated with them. These probes are not directed toward a single device, but exist to scan all devices in the specified network range. Response to Displays the name of the probe or sensor in the Discovery sequence whose activity triggered this probe or sensor. A single sensor can launch several probes, but a sensor can only respond to a single probe. Queue Designates whether the record is for a probe or a sensor. Sensors are in the input queue, and probes are in the output queue. State Shows where the probe or sensor is in the process of completing its task (e.g. processed or processing) Processed Times that this probe or sensor's task was finished. Created Time that this probe or sensor was launched/activated. Sequence Internal ID for the execution sequence for this probe or sensor. Payload Contents of the probe's instructions or the response that the sensor reports to the instance. Click the XML button to display the code in an XML view. An ECC Queue record for Discovery looks like this: Discovery Status 105 Viewing CMDB Records As you drill down through the probes and sensors that are part of a Discovery, you can view the CMDB record for the device (CI) that was probed, using either of the following methods: Right-click a probe or sensor in the ECC Queue record list and select Go to CMDB item. In a ECC Queue record, click the Go to CMDB item Related Link. Troubleshooting If you are suspicious of the results of a Discovery (credential failure, for example), you can run individual probes directly. To run a probe from the ECC Queue list, right-click the probe and select Run Again from the pop-up menu. To run a probe directly from an ECC Queue record, click the Run Again UI action in Related Links. Discovery Timelines 106 Discovery Timelines Overview A Discovery Timeline generates a graphical display of the ECC Queue for a Discovery, including information about each probe and sensor running. To display a timeline, click the Show Discovery Timeline Related Link on any Discovery Status form. No additional configuration is required. Use Discovery Timelines to display the following: The flow of probes and sensors through a Discovery The duration of each probe and sensor that ran during a Discovery and the proportion of time required for queuing and processing Tooltips containing additional data about a probe or sensor Records from the ECC Queue Using Timelines View timelines for an entire Discovery or for individual devices in a Discovery. In the out-of-box system, the maximum size Discovery that can be displayed in a timeline is 300 entries in the ECC Queue (150 probes and 150 sensors). To display larger discoveries, change the default setting in the glide.discovery.timeline.max.entries property. Probe and sensor timelines are available automatically when Discovery starts. Partial timelines for any device or for the entire Discovery can be viewed during the scanning process. View the progress of the Discovery by refreshing the browser. 1. Navigate to Discovery > Status. 2. Select a Discovery from the record list. 3. Click the Show Discovery Timeline Related Link. Discovery Timelines 107 The timeline for the entire Discovery appears, unless the size threshold is exceeded. If the timeline is too large to display, an error message appears. 4. Clear the warning, and then select the Devices Related List. 5. Click the IP address of a device. 6. In the Device record, click the Show Discovery Timeline Related Link. The Discovery timeline for that device appears. 7. Use the pink slider at the bottom of the timeline to change the perspective. a. Move the slider from right to left to view all the tasks on a long timeline. b. Adjust the end points of the slider to change the magnification. A narrow slider zooms in on the spans and provides a more detailed view of complex timelines. A wide slider pulls the view out and makes more of the timeline visible on the screen. 8. Use the selector range at the top of the screen to adjust the visible time frame. To limit the timeline to the length of the Discovery, click Max. The time scale adjusts automatically to the length of the Discovery. The available time scale range is from one day to 1 year. Discovery Timelines 108 Tooltips Discovery timelines display probe and sensor performance data and CI information in tooltips. Hover the cursor over a span to view this data. Probes are displayed by black spans. The queue time for a probe is shown as a silver bar within the span, and the processing time is represented by the remaining space. Sensor spans are red, and the queue time is shown as a green bar. Selected spans of any type display in yellow. ECC Queue Double-click on a span to open the ECC Queue record for that probe or sensor. 109 Discovery Behavior Discovery Behavior Overview A Discovery Behavior determines what probes Shazzam launches and from which MID Servers these probes are launched. Unlike a scan in which a single MID Server that performs all protocol scans on a designated IP address range, network, or list, a behavior can assign different tasks to multiple MID Servers on the same IP address segment or on different network segments. Behaviors are available in Discovery Schedules for discoveries in which configuration items (CI) are updated in the CMDB. Behaviors can be used in the following scenarios: Load balancing: A behavior enables load balancing in systems that use multiple MID Servers deployed across one or more domains. Multiple protocols in multiple domains: Configure one MID Server to scan for all protocols on one domain and another MID Server to perform a WMI scan on a second domain. Access Control Lists (ACL): Discovery can scan SNMP devices protected by an ACL if the MID Server host machine is granted access by that ACL. Use a behavior to configure a MID Server to scan devices protected by an ACL. Devices running two protocols: Some devices might have two protocols running at the same time. Examples of this are the SSH and SNMP protocols running concurrently on one device (most common). A behavior can control which of the two protocols is explored for certain devices. The behavior then prevents the other protocol from being explored. Creating a Behavior To create a behavior, navigate to Discovery Definition > Behavior' and click New. The Behavior form provides the following unique fields: Field Input Value Name Type a unique name that describes the use for this behavior, such as Two Domains or Load Balance. Discovery Functionality Select the MID Servers to use for this behavior, the desired execution phase, and the pre-configured functionality for each MID Server (protocols to scan). The completed Discovery Behavior form looks like this: Discovery Behavior 110 Discovery Functionality Discovery Functionality defines what each MID Server in this behavior must do, specifically which protocols to detect. This form provides the following unique fields: Field Input Value Phase A phase is an arbitrary integer used to group one or more functionalities together. All the functionalities within a phase are executed together, and all phases are executed in numerical order. All functionalities in a behavior can have the same phase. The Shazzam probe runs once for each phase in a behavior, which makes fewer phases desirable. Run multiple phases for behaviors only when devices in the network are running multiple protocols (e.g. SSH and SNMP). In this example, set one phase for the SSH scan and another phase for the SNMP scan. Functionality Select a pre-configured functionality that defines the protocol or list of protocols that each MID Server will scan. Access the Functionality Definition records through the Functionality link in the Discovery Behavior form or by navigating to Discovery Definitions > Functionality Definition. MID Servers Select one or more MID Servers to perform this functionality for the following Discovery types: IP Scan CI Scan Discovery automatically balances the load when multiple MID Servers are selected. Functionality Criteria Define criteria here for Windows MID Servers. See the following section for details. Functionality Criteria Functionality Criteria are required for Windows MID Servers only, and only when the behavior controls Discovery across multiple domains. When the instance launches the Shazzam probe for a Discovery in which a behavior defines multiple MID Servers to scan multiple domains, the Functionality Criteria determine which MID Server will process the results of the probe. The form provides the following unique fields: Field Input Value Name The name in the criteria is the variable that passes the following information: mid_server: MID Server that processes the results from the Shazzam probe. win_domain: Windows domain of the target device. Value Enter the actual name of the MID Server (mid_server) or domain (win_domain) to pass to Discovery for this criteria. This field can also have a value of mid_domain, which defines the Windows domain of the MID Server that is processing the Shazzam results. The completed criteria form looks like this: Discovery Behavior - Load Balancing 111 Discovery Behavior - Load Balancing Overview ServiceNow behaviors enable load balancing when multiple MID Servers are configured to scan the same protocol. For example, an organization has fifty remote locations, varying in size from 10 devices to several hundred devices. All the satellite offices are part of the same Windows domain, which is administered from a central location. There are three MID Servers installed at this central location: two to scan all the Windows devices and one to scan the remaining devices. Because some of the remote offices are in different time zones, different schedules must be created to run Discovery at off-peak hours in each time zone. The same behavior can be used for each schedule, and the behavior will load-balance the two Windows MID Servers automatically. Step 1: Create the Behavior Record Create a new Discovery Behavior record, and name it something descriptive, such as LoadBalanced. Right-click in the header bar and select Save from the pop-up menu. This action saves the record and creates the Discovery Functionality Related List in the form. Step 2: Define the Windows Functionality 1. Click New in the the Discovery Functionality Related List. 2. Create a new record using the fields described here. 3. Right-click in the header bar and select Save from the pop-up menu. Field Input Value Phase Type a phase number of 1 in this field. Functionality Select Windows only (WMI) from the list. This functionality defines the protocol that will be scanned. Because we selected to scan WMI, we must select Windows MID Servers for this functionality. MID Servers We select the two MID Servers that we want to share the load for the WMI probes. By entering multiple MID Servers in this field, we tell Discovery to balance the load between these servers automatically. If we were to create separate functionality for each server, load balancing would not occur. Active Make sure this check box is selected to enable this behavior. Match criteria Leave the default criteria of Any. Discovery Behavior - Load Balancing 112 Step 3: Create Functionality Criteria All Windows functionality requires criteria to identify the Windows domain and define any special behavior for the MID Servers named. To create Functionality Criteria, click New in the Related List and enter the following values: Field Input Value Name We enter win_domain to name the Windows domain that Discovery will scan with the MID Servers we have defined. Operator Select equals as the operator in this criteria. Value This is the name of the Windows domain that these MID Servers will scan for devices. Active Be sure to enable the criteria by selecting this check box (true). The completed criteria appear in the Discovery Functionality form for the Windows MID Servers. Step 4: Define the Functionality for the Remaining Scans Create a second record to scan for all the remaining protocols (SSH, SNMP, etc), using the following settings: Field Input Value Phase Type a phase number of 1 in this field. This phase will be executed at the same time as the WMI scans and with the same Shazzam probe. We use the same phase number for efficiency and because we know that none of the devices in the target IP ranges are running multiple protocols (e.g. SSH and SNMP). If any devices were running multiple protocols, we would want to specify a second or even a third phase to discover the correct protocol first for each device. Functionality Select All except windows (no WMI) from the list. This functionality causes the MID Server to scan all remaining protocols after Discovery has run the WMI scans. MID Servers Name the MID Server that will scan for all other devices. If we want to use automatic load balancing, we can add an additional MID Server to this field. The completed Discovery Behavior form looks like this. It is not necessary to create Functionality Criteria for this MID Server. Discovery Behavior - Load Balancing 113 Step 5: Create the Schedules Create a Discovery Schedule record for each different time zone, and name the behavior we just created. See Discovery Schedules for details. 1. Navigate to Discovery > Discovery Schedules and click New in the record list. 2. Select a Discover type of Configuration items. This action displays the Behavior field. 3. Click the magnifier icon and select the behavior to use. In our example, we select LoadBalanced. 4. Select the appropriate time to run Discovery for this location. 5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location. 6. Save the record. 7. Create additional schedules for each time zone or region in the network and select the same behavior. Discovery Behavior - Multiple Domains 114 Discovery Behavior - Multiple Domains Overview ServiceNow Behaviors enable the efficient Discovery of SSH and SNMP devices and WMI devices running on multiple Windows domains, using multiple MID Servers. For example, an organization has two Windows domains in its network and a variety of UNIX computers and SNMP devices. The challenge is to discover all the devices efficiently, without duplicating effort. Each domain contains a Windows MID Server which is used to scan the IP addresses from the two domains specified in the Discovery Schedule, as well as the SSH and SNMP devices. We need a Behavior that divides the work appropriately to avoid scanning anything twice. In this example, we assume that both domains are in the same geographical location, and that a single schedule is sufficient. Note: The preferred method for running Discovery over multiple Windows domains is to use PowerShell, which allows a single MID Server to authenticate on machines on different domains using credentials stored on the instance. Step 1: Enable NetBios Enable WINS/NetBIOS/port 137 on the MID Server machine so it can authenticate on other machines in the domain. Step 2: Create the Behavior Record Create a new Discovery Behavior record and give it a descriptive name. Right-click in the header bar and select Save from the pop-up menu. This action saves the record and creates the Discovery Functionality Related List in the form. To complete this behavior (as shown here) we must create functionalities. For the functionalities that scan for the WMI protocol, we must define criteria that specify the Windows domain being scanned and the MID Server responsible. Discovery Behavior - Multiple Domains 115 Step 3: Define the Functionalities We will create three functionalities for this Behavior: one MID Server to scan Domain A for Windows devices only; a second functionality for the same MID Server to scan for all SSH and SNMP devices; and a third functionality that names a second MID Server to scan Domain B for Windows devices. The rationale for this is as follows: A Windows MID Server can only discover Windows machines on the Windows domain to which it is joined. This is entirely due to the way Windows authentication works. For this reason, we need a WMI functionality for each domain. A Windows MID Server, provided with the correct credentials, can discover SSH and SNMP devices anywhere; however, we cannot combine WMI, SSH, and SNMP functionalities across Windows domains. This is because the functionality criteria for the WMI scans locks in the Discovery to one specific domain. For this reason, SSH and SNMP discoveries require a separate functionality. We want to scan each machine only once. Click New in the the Discovery Functionality Related List to add functionalities. Functionality 1: WMI Scanning on Domain A We configure a MID Server to scan for the WMI protocol on Domain A. WMI scans authenticate on Windows machines using the domain credentials of the Windows MID Server machine. Windows MID Servers cannot scan for the WMI protocol outside their own domains. Create the first functionality using the following values: Field Input Value Phase Type a phase number of 1 in this field. All functionalities in this example use the same phase number, which launches a single Shazzam probe for all the functionalities in that phase. A single phase, when feasible, is the most efficient use of the Shazzam probe. Functionality Select Windows, DNS, and WINS from the list. This functionality defines the WMI protocol that will be scanned and resolves the domain. Because we selected to scan for WMI, we must select a Windows MID Server for this functionality. MID Servers We select a Windows MID Server from Domain A - in this case sandb01-358. Active Make sure this check box is selected to enable this behavior. Match criteria Change the criteria to All. Create Functionality Criteria All Windows functionality requires criteria to identify the domain and the MID Server. In our example, we will create two criteria for this functionality. To create Functionality Criteria, click New in the Related List and enter the following values for the MID Server doing the WMI scanning on Domain A: Discovery Behavior - Multiple Domains 116 Field Input Value Name Create the following criteria: Enter mid_server to name the MID Server that will execute the WMI scans on Domain A. Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined. Operator Select equals as the operator in this criteria. Value For the mid_server value, enter the name of the MID Server that will scan Domain A for Windows devices. For the win_domain value, enter the name of Domain A that this MID Server will scan for Windows devices. Active Be sure to enable the criteria by selecting this check box (true). The completed criteria appear in the Discovery Functionality form for this behavior. Functionality 2: SSH and SNMP In our network, we want to scan for UNIX computers and netgear, but we don't want to classify these devices twice. One of our MID Servers will be configured to classify SSH and SNMP using a different functionality than it does for WMI scans. We do not need to create criteria for non-WMI functionality. Create the second functionality using the following values: Field Input Value Phase Type a phase number of 1 in this field. All functionalities in this example use the same phase number, which launches a single Shazzam probe for all the functionalities in that phase. A single phase, when feasible, is the most efficient use of the Shazzam probe. Functionality Select All except Windows (no WMI) from the list. This functionality will scan SSH and SNMP protocols only. MID Servers We select the MID Server from Domain A - in this case sandb01-358. Active Make sure this check box is selected to enable this behavior. Match criteria Leave the default criteria of Any. Criteria are not used for non-WMI functionalities. Discovery Behavior - Multiple Domains 117 Functionality 3: WMI Scanning on Domain B All that remains is to create a functionality for the WMI scans on Domain B. Because of the Windows authentication mechanism, we must configure a Windows MID Server to scan Domain B that is a member of that domain. Create the third functionality using the following values: Field Input Value Phase Type a phase number of 1 in this field. All functionalities in this example use the same phase number, which launches a single Shazzam probe for all the functionalities in that phase. A single phase, when feasible, is the most efficient use of the Shazzam probe. Functionality Select Windows, DNS, and WINS from the list. This functionality defines the WMI protocol that will be scanned and resolves the domain. Because we selected to scan for WMI, we must select a Windows MID Server for this functionality. MID Servers We select a Windows MID Server from Domain B - in this case disco-win2003. Active Make sure this check box is selected to enable this behavior. Match criteria Change the criteria to All. Create Functionality Criteria All Windows functionality requires criteria to identify the Windows domain and the MID Server. In our example, we will create two criteria for this functionality. To create Functionality Criteria, click New in the Related List and enter the following values for the MID Server doing the WMI scanning on Domain B: Field Input Value Name Create the following criteria: Enter mid_server to name the MID Server that will execute the WMI scans on Domain B. Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined. Operator Select equals as the operator in this criteria. Value For the mid_server value, enter the name of the MID Server that will scan Domain B for Windows devices. For the win_domain value, enter the name of Domain B that this MID Server will scan for Windows devices. Active Be sure to enable the criteria by selecting this check box (true). The completed criteria appear in the Discovery Functionality form for this behavior. Discovery Behavior - Multiple Domains 118 Step 4: Create the Schedule Create a Discovery Schedule record and name the behavior we just created. See Discovery Schedules for details. 1. Navigate to Discovery > Discovery Schedules and click New in the record list. 2. Select a Discover mode of Configuration items. This action displays the Behavior field. 3. Click the magnifier icon and select the behavior to use. In our example, we select Southwest-SNMP. 4. Select the appropriate time to run Discovery for this location. 5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this location. 6. Save the record. 7. Create an additional schedule if more than one time zone is involved. Discovery Behavior - Access Control Lists (ACL) 119 Discovery Behavior - Access Control Lists (ACL) Overview A specific type of Access Control List (ACL) on an SNMP device can prevent Discovery from identifying that device. This list defines host machines by IP addresses that are permitted to run agents on SNMP devices. In this example, we want to classify, identify, and update all the devices in an IP range, including the SNMP devices protected by an ACL. To do this, we must install a MID Server with access to the protected SNMP devices and then create a Behavior that allows us to scan for all protocols without missing any devices or doing any extra work. Note: See the instructions for earlier versions of ServiceNow, in Legacy:Discovery Behavior for ACLs Step 1: Install a MID Server on a Host Permitted by the ACL To scan the SNMP devices in a network protected by an ACL, a MID Server must be installed on a host machine specified by IP address in the ACL as having access to the SNMP devices. Because this MID Server is scanning SNMP devices only, it can be installed on any supported operating system. The other MID Server, configured to discover WMI and SSH, can be installed on any Windows host that has visibility to the specified IP ranges. Install additional MID Servers if you intend to configure either functionality to load balance. Step 2: Create the Behavior Record Create a new Discovery Behavior record, and name it something descriptive, such as Southwest-SNMP. Right-click in the header bar and select Save from the pop-up menu. This action saves the record and creates the Discovery Functionality Related List in the form. To complete this behavior (as shown below) we must create functionalities using the MID Servers we installed for that purpose. For the functionality that scans for the WMI protocol, we must define criteria that specify the Windows domain and MID Server being used. Because this Discovery is being performed on one Windows domain, we can configure a functionality for WMI and SSH (All except SNMP) using the same MID Server. Discovery Behavior - Access Control Lists (ACL) 120 Step 3: Define the Functionalities For this behavior, we create two functionalities, one for SNMP on the MID Server installed on the host specified in the ACL and another for WMI and SSH on a second MID Server. Click New in the the Discovery Functionality Related List to add functionalities. Functionality 1: SNMP Protocol We configure the MID Server installed on the privileged host machine to scan for the SNMP protocol only. Create the first functionality using the following values: Field Input Value Phase Type a phase number of 1 in this field. Both functionalities in this example use the same phase number, which launches a single Shazzam probe for all the functionalities in that phase. A single phase, when feasible, is the most efficient use of the Shazzam probe. Functionality Select SNMP only from the list. This functionality defines the protocol that will be scanned. MID Servers We select a MID Server (sansol02_Solaris) installed on a Solaris host that is granted access to the SNMP devices by the ACL. You can select multiple MID Servers if you want Discovery to load balance this functionality automatically. Active Make sure this check box is selected to enable this behavior. Match criteria Leave the default criteria of Any. Criteria are not used for SNMP functionalities. Functionality 2: WMI and SSH Protocols In the second functionality, Discovery will scan our domain for WMI and SSH protocols. Because WMI is one of the protocols, the MID Server for this functionality must be installed on a Windows machine and must have criteria. Create the second functionality using the following values: Field Input Value Phase Type a phase number of 1 in this field. All functionalities in this example use the same phase number, which launches a single Shazzam probe for all protocol scans. A single phase, when feasible, is the most efficient use of the Shazzam probe. Functionality Select All except SNMP from the list. This functionality defines the protocols for which scanning will occur. Because WMI is one of the protocols selected, we must use a Windows MID Server for this functionality. MID Servers We select a Windows MID Server from our domain. In this case we select disco-win2003. You can select multiple MID Servers if you want Discovery to load balance this functionality automatically. Active Make sure this check box is selected to enable this behavior. Match criteria Change the criteria to All. Discovery Behavior - Access Control Lists (ACL) 121 Create Functionality Criteria Functionalities that scan for WMI require criteria to identify the domain and the MID Server. In our example, we will create two criterias for this functionality. To create Functionality Criteria, click New in the Related List and enter the following values for the MID Server doing the WMI scanning on our domain: Field Input Value Name Create the following criteria: Enter mid_server to name the MID Server that will execute the WMI scans. Enter win_domain to name the Windows domain that Discovery will scan with the MID Server defined. Operator Select equals as the operator in this criteria. Value For the mid_server value, enter the name of the MID Server that will scan our domain for Windows devices. For the win_domain value, enter the name of our Windows domain. Active Be sure to enable the criteria by selecting this check box (true). The completed criteria appear as follows in the Discovery Functionality form for this behavior. Step 4: Create the Schedule Create a Discovery Schedule record and name the behavior we just created. See Discovery Schedules for details. 1. Navigate to Discovery > Discovery Schedules and click New in the record list. 2. Select a Discover mode of Configuration items. This action displays the Behavior field. 3. Click the magnifier icon and select the behavior to use. In our example, we select Southwest-SNMP. 4. Select the appropriate time to run Discovery for this location. 5. Click Quick Ranges and define the IP address ranges, networks, or lists to scan for this domain. 6. Save the record. Discovery Behavior - Access Control Lists (ACL) 122 123 FAQ Discovery FAQ General Topics What technologies are used for Discovery? Discovery is deployed in an agentless framework and uses Internet Protocols to probe the network. SNMP - machine specific information SSH - Linux and UNIX logins for in depth scans WMI - Windows discovery Powershell - Windows discovery DNS/WINS IP Resolution VMware API - VMware/ESX discovery What are credentials, and what kind do you need? Credentials are generally a user/password used to authorize use of a system. For discovery purposes, the following types of credentials are required: user / password or preshared key - for UNIX and Linux systems domain authorization - authorizing WMI for Windows systems community strings - for SNMP What will be created with no credentials, no login, no SNMP? Nothing can be created without these elements. However, if Discovery finds an IP address that is partially responsive, Discovery logs the device for additional exploration. What will you find in UNIX Discovery? Very detailed and deep information about the OS, the hardware, network, disk, and application configurations. See Data Collected by Discovery for details. What detail will you get with Windows WMI? Very detailed and deep information about the OS, the hardware, network, disk, and application configurations. Discovery FAQ 124 Can you discover multi-core processors on UNIX and Windows? Yes, we detect the number of cores for UNIX, Linux, Windows environments. Can you discover Web / Application Servers without specific credentials? Yes. We can discover the presence of a Web Server through a running process classifier. The Web Server will be identified by vendor and make (Apache, Tomcat, BEA WebLogic, IBM Websphere, JBoss, Microsoft IIS, etc.) and the database connections used. What will you discover about Web Servers with specific credentials? The applications installed and the database connections used. Can you identify patches and packages? Yes. Packages and patches are identified for Solaris, Linux, and Windows. How does application mapping work? By finding the relationships between different running processes, such as Web Servers, application servers, and databases. In a typical scenario, Discovery determines that an application starting at an Apache HTTP server may contact one or more application servers that are running particular J2EE applications that connect to one or more databases. The output of the mapping is a dependency map of the discovered pieces which is easily viewed graphically using our Business Service Visualizer. Can you import Discovery data? Yes. For example, you may want to import a list of IP addresses in host file format to start the discovery process on a set of known machines. The system is very agile at importing, exporting, and synchronizing (federating) data. Does your Discovery run agentless or require an agent on every machine? Agentless is the simple answer. Do you discover Solaris Zones? Yes. Using standard Sun Utility Tools for Management of Solaris Containers. Do you discover Virtual Machines? Yes. Using management instrumentation provided by VMware, including the vCenter API on Windows hosts. Discovery FAQ 125 Which commands are used by Discovery on UNIX and Linux? In general, we use simple commands like ps, df, sh, uname, etc. All the commands can be seen in the Probes section of the Discovery application. Which WMI queries are performed? The WMI queries are in the database through the Probe Parameter for the WMIProbe. Many parameters are obtained from the Win32_ComputerSystem object, among others. What access level do you need to run discovery on Linux / UNIX? For most items, non-root. For application dependency mapping, sudo, or limited root privilege. What kind of built-in reporting capabilities do you provide? The system has an easy to use, yet powerful and comprehensive reporting package. The reporting is very interactive, with drill downs, grouping, sorting, filtering, and aggregation all under the end users control. We supply a number of reports to help get insight to the discovered CMDB. How can you see the file path that Windows uses to uninstall software? Discovery detects and displays the paths that Windows uses to uninstall software with the Add or Remove Programs utility. To see uninstallation paths, open a Windows Server configuration item (CI) record. All available paths are shown in the Uninstall string column in the Software Installed Related List. Software License Management / Compliance How can you help with license management for application servers such as Websphere and WebLogic? Discovery will tell you how many instances of the application servers are running, what applications are installed (PKGAdd, RPM or MSI installer). How can you help with license management for databases such as Oracle, SQL Server, Sybase, others? Discovery can show the databases / table spaces installed and track the IP address that connect to the database engine to try and help with CAL type licensing. See Software License Management for details on software licensing. Can Discovery help with license management of Microsoft desktop applications? Yes. After discovering installed software (Operating System and applications) entries are recorded in the CMDB and also the Microsoft License section of the product's Asset Management application. The licensing also includes special identifications required by vendors (OEM versus Retail for Microsoft), counting for Symantec and Adobe, etc. Discovery FAQ 126 MID Server (Monitoring, Integration, Discovery) What is this MID Server? It is a small Java process that runs the probes for the discovery. Do you provide an appliance or do I need my own hardware for the MID server? You use your standard hardware (including virtual machines). There is no need to introduce a foreign appliance with it's requisite security / backup / DR issues. How does Discovery scale in an environment with tens or even hundreds of thousands of devices? Multiple MID servers deployed in different network segments and/or geographically will provide virtually unlimited scalability. MID servers are capable of handling multiple thousands of devices each. What OS does the MID server require? UNIX, Linux, or Windows. What are the resource requirements (network and CPU) during the discovery? Resource consumption is remarkably low, see MID Server Requirements for details. How are the MID servers administered? All administration (with the exception of the installation) is handled centrally from your instance. Configuration of IP ranges, credentials, schedules for discovery are all in a web-based UI. Security How are the credentials secured? They are stored in the database using 3DES encryption. Once entered, the system has no way of ever displaying them again. How are the credentials transported to the MID server? Using HTTPS (SSL) to transport all data encrypted. Once at the MID server, the standard encryption capabilities of SSH and WMI are used. Firewall, TCP Planning Information What ports are used for Discovery on UNIX and Linux? Connection is made using the standard SSH port 22. What port numbers are used in Windows Discovery? Discovery detects activity on port 135 on Windows machines, and then 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. Discovery FAQ 127 Customization and Integration Can we customize the Discovery commands, and on what level can we customize them? Yes. The entire set of Discovery commands is centrally administered in the database and can freely be altered, added to, or removed. Can the Data Model (database definition) be extended? Yes. Fields, tables, and relationship descriptions can all be customized. There are no limitations. Can you integrate with other CMDB technologies such as Atrium or AssetCenter? Yes. This is something we do very well. Through web services, bi-directional integration can be created. We also have standard integrations to many other popular systems such as IBM CCMDB, HP OpenView, HP / Mercury MAM, IBM Tivoli, Microsoft SMS, LanDesk, Oracle Financials, Altiris. Is it possible to have specific Discovery configurations for a group of computers? Yes. Can we specify which ports are scanned / probed? Yes. The PortProbe definition permits a parameter "ports" to limit scope. As an example, you could specify ports = 22,80,135. Can we use an alternate SSH tool? Yes. It is possible to write probes in languages such as PERL, JavaScript, or BASH that use any tool you choose. Can Discovery commands be run independently (without sensor reaction)? Only in Runbook. Define a Probe with either no Sensor or a special sensor that does not schedule further Probes. Is it possible to automate the discovery tasks with 3rd party tools? Yes. There are two possibilities: Use web services to schedule IP ranges to be discovered. Use special Probes and Sensors (written in PERL and JavaScript for example). 128 Reference Discovery Bandwidth Functionality described here requires the Discovery plugin. Overview The graph is in Bytes per second. It had a capture filter of (MIDservicenow01 or MIDservicenow02). The Black line is the traffic to the Bluecoat, i.e ServiceNow. The Red line represents New York. The Green line represents L.A. The traffic appears to be as follows - idle scanning for a site: typically not more than 320Kb/second (about 20 to 40KB/sec max), spiking very briefly to 1.6Mb/sec. Bluecoat traffic for these servers looks to be 480Kb/sec. Discovery Resource Utilization 129 Discovery Resource Utilization Windows Typical Windows transactions will generate on the average of 1.5 to 5 Mb of traffic for each client successfully discovered. This number is dependant on the computer being discovered with Desktops being on the low end to fully loaded servers providing multiple applications and services to other hosts on the other. UNIX - SSH Typical SSH network traffic sizes are around 6k (kilobytes) plus commands being executed Initial TCP connection handshake (~300 bytes) SSH initialization, key exchange and authentication (~5k) SSH commands/output from commands (Data is compressed) SSH/TCP connection teardown (~300 bytes) For example, If executing dmidecode and it's output is 12k of data, the total network transfer would be ~18k. Lets run through a scenario. Host is RedHat Linux ES3 with a 2.4.21-53.EL kernel. SSH commands used for Discovery: /bin/uname (80 bytes) /proc/meminfo (780 bytes) /proc/cpuinfo (420 bytes) /bin/ps (8k) /usr/sbin/dmidecode (12k) /sbin/ifconfig (860 bytes) /usr/sbin/lsof (18k) Command Output total: 40k SSH Communication total: 42k (7 commands * 6k traffic size) Total: 82k To get the base information from a Linux host, it uses about 82k of traffic per Discovery of the host. Sample Bandwidth Graph This graph shows the bandwidth consumption of a typical Discovery by operating system. Application Dependency Mapping 130 Application Dependency Mapping Overview Application Dependency Mapping determines which machines are communicating with one another, and on which port, and determines which processes are running on these machines. You can use the data from running processes to determine which machines to drill into for more application-specific configuration data. Discovery maps this data automatically into upstream and downstream relationships, using the following types: Runs on/Runs Depends on/Used by Hosted on/Hosts Virtualized by/Virtualizes Contains/Contained by IP Connection/IP Connection Note: For information on how Discovery classifies processes and establishes relationship types, see Process Classifications. Accessing Dependency Maps 1. Navigate to Configuration and select a CI class (Servers, Database Servers, Database Instances, etc.). 2. Select a specific CI from the list. 3. In the CI record, select the map icon in the Related Items header bar. 4. In the dependency map that appears, right-click on the arrow connectors between CIs to display the relationship type. Upstream and Downstream Relationships In Upstream and Downstream relationships anything that happens downstream can have an adverse affect on upstream configuration items. In our example relationship, if the virtual server sannnm-01 crashes, the database instances and the Web Server upstream are adversely affected. Likewise, if the Web Server fails, the Web Site hosted on it goes down. The CI record for the virtualized Windows server sannnm-01 with its upstream and downstream relationships is shown below. The downstream relationships show that this server is virtualized by VMware running on a Windows server named sandb01. Our upstream relationships show a MySQL instance, a SQL instance, and a Web Server running on sannnm-01. Farther upstream, a Web site is hosted on the Web Server. Application Dependency Mapping 131 Deleting CIs When CIs are deleted from the CMDB, upstream CIs with relationship types of Hosted on and Runs on are also deleted. This cascade delete feature is intended to remove applications from the CMDB that have a one-to-one relationship with the adjacent downstream CI. In our example, VMware runs on the sandb01 server in a one-to-one relationship and is deleted when the host machine is deleted. However, the sannnm-01 server is virtualized on the VMware CI in a potential one-to-many relationship and is not deleted when sandb01 is deleted. If the virtual server sannnm-01 is deleted, then so are the upstream CIs that have a one-to-one relationship with the server. In our example, the MySQL instance, the Web Server and the SQL instance are all deleted, as is the Web site hosted by the Web Server. Application Dependency Mapping 132 Application Dependencies This screenshot shows the Application Dependencies between three different JBoss Application Servers and the local Apache Web site. In this example, the three JBoss application servers on three different physical machines have a TCP connection to the local Apache application on www.online1.com. Additionally, there are 5 Apache Web servers using the local JBoss Application. Adding CI Relationships Discovery automatically maps the dependencies between CIs that it finds in the network and assigns the appropriate type to each relationship. ServiceNow configuration enables administrators to add dependencies manually and to define the appropriate relationship type between new configuration items based on lists of suggested relationships. The best practice when adding application dependencies to a configuration item is to avoid the use of the Runs on/Runs and Hosted on/Hosts types. When a configuration item is deleted, any upstream CIs with a relationship type of Runs on or Hosted on is deleted as well. In some cases, manually added CIs might have other important dependencies that are adversely affected by the cascade deletion triggered by these two relationship types. To add a dependency, 1. In a CI record, click the + icon in the Related Items toolbar. 2. Select the appropriate relationship type from the list at the top of the page. Application Dependency Mapping 133 3. Create and run an appropriate filter to make the desired CI visible in the list of available CIs. 4. Move the CI from the list of available CIs to the dependent list. 5. Save the relationship. Example An example of the importance of selecting the proper relationship type is when the Business Service dependency, PeopleSoft CRM, is added to the sannnm-01 virtual server in the following diagram. If PeopleSoft CRM is added with a relationship type of Depends on, it is protected from the cascade delete triggered by the deletion of the Windows server sannnm-01. This is important because PeopleSoft CRM has dependencies to other servers and must not be deleted. VMware Component Relationships 134 VMware Component Relationships Overview ServiceNow supports the use of virtual machines generated by the VMware application, installed on Windows, Linux, or ESX Servers. The ServiceNow Discovery product can extract information from VMware configuration items (CI), including their relationships. Discovery is configured to work with the Runbook Automation VMware Support Plugin, which enables the automatic cloning of virtual machines by an ESX Server managed by vCenter. For information about data collected by Discovery on vCenter, see Discovery for VMware vCenter. VMware Architecture ServiceNow supports two basic types of VMware deployment using the VMware application: VMware installed on an ESX Server, managed by vCenter. VMware installed on a Windows or Linux host machine, not managed by vCenter. ServiceNow Discovery can extract information from all the components in a VMware system, including vCenter. Discovery creates records in the CMDB for vCenter, the host machine and all the virtual machines running on that server. Discovery finds the stored templates and maps all the relationships between components. In networks that use Runbook Automation to create and manage virtual servers, Discovery populates records automatically and detects changes in the network. Without Discovery, all the records for Runbook Automation VMware Support must be created and updated manually, including the relationships between VMware components. vCenter Cloning The vCenter management console can control multiple ESX Server machines, each of which is capable of hosting multiple virtual servers cloned from stored templates. The relationships between VMware components for this type of installation are shown in the following diagram: VMware Component Relationships 135 Relationships The components in a system managed by vCenter have the following relationships: VCenter: Manages one or more ESX Servers ESX Server: Managed by vCenter Gets resources from the Resource Pool Has registered VMware instances Virtualizes virtual machines. Resource Pool: Defines resources for the ESX Server. See Resource Pools for more information. VM Instances (including images and templates): Registers on the ESX Server Instantiates individual virtual machines. Virtual machines: Instantiated by VM instances (images and templates) Virtualized by ESX Server Establishing Relationships Using Discovery ServiceNow Discovery identifies appropriate relationships for new virtual machines or updates the relationships for previously discovered virtual machines. 1. The UNIX classify probe identifies the ESX Server. 2. Discovery assumes that the VMware application is running on the ESX Server and creates/updates the application CI in the CMDB. 3. Discovery launches an SSH Probe that discovers all images on the ESX Server, including the unique IDs (UID). 4. Discovery then compares the master list of UIDs retrieved from the ESX Server with the UIDs of previously discovered virtual machines in the CMDB and looks for a match. 5. If a match is found, Discovery updates the many-to-many relationship between the VMware components. VMware Component Relationships 136 VMware Running on a Host Machine In the basic VMware system, the VMware application runs on a Windows or Linux host machine. This system can clone instances from templates, but cannot be automated. The relationships between VMware components for this type of installation are shown in the following diagram: Relationships The components in a VMware system installed on a Windows or Linux host have the following relationships: Windows or Linux Server: Runs the VMware application VMware application: Runs on a Windows or Linux host machine Has registered VM instances Virtualizes virtual machines. VM Instances (including images and templates): Registers on the VMware application Instantiates individual virtual machines. Virtual machines: Instantiated by VM instances Virtualized by VMware application Establishing Relationships Using Discovery ServiceNow Discovery identifies appropriate relationships for new virtual machines or updates the relationships for previously discovered virtual machines. 1. The UNIX classify probe (or Windows classify probe) determines the operating system of the host machine. 2. Discovery finds the VMware application running on the host machine and creates/updates the application CI in the CMDB. 3. Discovery launches an SSH Probe that discovers all images on the host machine, including the unique IDs (UID). 4. Discovery then compares the master list of UIDs from the host machine with the UIDs of previously discovered virtual machines in the CMDB and looks for a match. 5. If a match is found, Discovery updates the many-to-many relationship between the VMware components. Article Sources and Contributors 137 Article Sources and Contributors Getting Started Source: http://wiki.servicenow.com/index.php?oldid=127508 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Pat.Casey, Steve.wood, Swood, Valor, Vhearne Discovery Made Easy Source: http://wiki.servicenow.com/index.php?oldid=127505 Contributors: Bow, CapaJC, G.yedwab, Guy.yedwab, Ishrath.razvi, Jerrod.bennett, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush, Vhearne Discovery Agentless Architecture Source: http://wiki.servicenow.com/index.php?oldid=100677 Contributors: Bow, CapaJC, Chuck.tomasi, Dan.greenbaum, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Rob.woodbyrne, Steve.wood, Swood, Vhearne Setting up Discovery Source: http://wiki.servicenow.com/index.php?oldid=130199 Contributors: CapaJC, Cheryl.dolan, Emily.partridge, Joseph.messerschmidt, Steve.wood, Swood MID Server Plugin Source: http://wiki.servicenow.com/index.php?oldid=89866 Contributors: Aburruss, Bow, CapaJC, Christen.mitchell, Chuck.tomasi, Dan.sherwin, David Loo, Doogiesd, G.yedwab, Guy.yedwab, Jeremiah.hall, John.andersen, John.roberts, Joseph.messerschmidt, Mark.odonnell, Neola, Rob.woodbyrne, Steve.wood, Swood, Tom.dilatush, Vhearne MID Server Requirements for Discovery Source: http://wiki.servicenow.com/index.php?oldid=67960 Contributors: Bow, CapaJC, David Loo, Doogiesd, Gadi.yedwab, Guy.yedwab, Joseph.messerschmidt, Rob.woodbyrne, Steve.wood, Swood, Valor, Vaughn.romero, Vhearne MID Server Installation Source: http://wiki.servicenow.com/index.php?oldid=92534 Contributors: Steve.wood, Swood Deploying Multiple MID Servers Source: http://wiki.servicenow.com/index.php?oldid=100485 Contributors: Chuck.tomasi, Joseph.messerschmidt, Steve.wood, Swood MID Server Configuration Source: http://wiki.servicenow.com/index.php?oldid=134387 Contributors: Aleck.lin, Bow, Emily.partridge, Guy.yedwab, Jim.holthaus, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush, Vaughn.romero, Vhearne, Voytek.blonski MID Server Clusters Source: http://wiki.servicenow.com/index.php?oldid=135017 Contributors: Joseph.messerschmidt, Steve.wood, Swood Controlling the MID Server Version Source: http://wiki.servicenow.com/index.php?oldid=135800 Contributors: Emily.partridge, Joseph.messerschmidt, Steve.wood, Swood MID Server Heartbeat Source: http://wiki.servicenow.com/index.php?oldid=103817 Contributors: Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush MID Server User Security Source: http://wiki.servicenow.com/index.php?oldid=103753 Contributors: Cheryl.dolan, Joseph.messerschmidt, Neola, Steve.wood, Swood Shazzam Probe Parameters Source: http://wiki.servicenow.com/index.php?oldid=134399 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Steve.wood, Swood, Tom.dilatush Port Probes Source: http://wiki.servicenow.com/index.php?oldid=122653 Contributors: Aleck.lin, Ishrath.razvi, Joseph.messerschmidt, Steve.wood, Swood Database Catalogs Source: http://wiki.servicenow.com/index.php?oldid=101685 Contributors: G.yedwab, Joseph.messerschmidt, Rachel.sienko, Steve.wood, Swood Custom Probe - Text File Source: http://wiki.servicenow.com/index.php?oldid=101893 Contributors: CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Neola, Rachel.sienko, Steve.wood, Swood Device Classifications Source: http://wiki.servicenow.com/index.php?oldid=102047 Contributors: Aleck.lin, G.yedwab, Joseph.messerschmidt, Steve.wood, Swood Process Classifications Source: http://wiki.servicenow.com/index.php?oldid=105158 Contributors: Aleck.lin, Joseph.messerschmidt, Steve.wood Discovery Classification Parameters Source: http://wiki.servicenow.com/index.php?oldid=100607 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush Discovery Identifiers Source: http://wiki.servicenow.com/index.php?oldid=100679 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush Credentials Source: http://wiki.servicenow.com/index.php?oldid=133843 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Doogiesd, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Tom.dilatush, Vhearne, Voytek.blonski Discovery Schedules Source: http://wiki.servicenow.com/index.php?oldid=111451 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Voytek.blonski Network Discovery Source: http://wiki.servicenow.com/index.php?oldid=102065 Contributors: Aleck.lin, Chuck.tomasi, G.yedwab, Joseph.messerschmidt, Steve.wood, Suzannes, Swood Discovery Status Source: http://wiki.servicenow.com/index.php?oldid=113561 Contributors: Cheryl.dolan, G.yedwab, Joseph.messerschmidt, Steve.wood, Swood, Voytek.blonski Discovery Timelines Source: http://wiki.servicenow.com/index.php?oldid=122654 Contributors: Joseph.messerschmidt, Steve.wood, Swood, Wallymarx Discovery Behavior Source: http://wiki.servicenow.com/index.php?oldid=120680 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Rachel.sienko, Russ.sarbora, Steve.wood, Swood Discovery Behavior - Load Balancing Source: http://wiki.servicenow.com/index.php?oldid=120682 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steve.wood, Swood Discovery Behavior - Multiple Domains Source: http://wiki.servicenow.com/index.php?oldid=120684 Contributors: G.yedwab, Joseph.messerschmidt, Steve.wood, Swood Discovery Behavior - Access Control Lists (ACL) Source: http://wiki.servicenow.com/index.php?oldid=120686 Contributors: G.yedwab, Ishrath.razvi, Joseph.messerschmidt, Steve.wood, Swood Discovery FAQ Source: http://wiki.servicenow.com/index.php?oldid=122794 Contributors: Aleck.lin, Bow, CapaJC, Cheryl.dolan, Dan.greenbaum, Doogiesd, Fred.luddy, Guy.yedwab, Joseph.messerschmidt, Rob.phillips, Steve.wood, Swood, Tom.dilatush, Vhearne Discovery Bandwidth Source: http://wiki.servicenow.com/index.php?oldid=100167 Contributors: Dan.sherwin, G.yedwab, Guy.yedwab, John.roberts, Joseph.messerschmidt, Swood, Vhearne Discovery Resource Utilization Source: http://wiki.servicenow.com/index.php?oldid=103761 Contributors: Bow, CapaJC, Doogiesd, G.yedwab, Guy.yedwab, Steve.wood, Swood, Tom.dilatush, Vhearne Application Dependency Mapping Source: http://wiki.servicenow.com/index.php?oldid=120665 Contributors: Dan.sherwin, Eprokopow@enernoc.com, G.yedwab, Guy.yedwab, Joseph.messerschmidt, Rob.phillips, Rob.woodbyrne, Steve.wood, Swood, Vhearne VMware Component Relationships Source: http://wiki.servicenow.com/index.php?oldid=120722 Contributors: Aleck.lin, Joseph.messerschmidt, Steve.wood, Swood Image Sources, Licenses and Contributors 138 Image Sources, Licenses and Contributors Image:Tick.png Source: http://wiki.servicenow.com/index.php?title=File:Tick.png License: unknown Contributors: Mark.odonnell Image:Discovery class.jpg Source: http://wiki.servicenow.com/index.php?title=File:Discovery_class.jpg License: unknown Contributors: Bow Image:MID_Server_Probe_Simple_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Probe_Simple_Diagram.png License: unknown Contributors: Steve.wood Image:Discovery_Communications_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Communications_Diagram.png License: unknown Contributors: Steve.wood Image:Warning.gif Source: http://wiki.servicenow.com/index.php?title=File:Warning.gif License: unknown Contributors: CapaJC Image:Discovery_Data_Collection_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Data_Collection_Diagram.png License: unknown Contributors: Steve.wood Image:Discovery_Oracle_Instance.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Oracle_Instance.png License: unknown Contributors: Steve.wood Image:Discovery_Oracle_Listener.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Oracle_Listener.png License: unknown Contributors: Steve.wood Image:Discovery_Process_Ports.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Process_Ports.png License: unknown Contributors: Steve.wood Image:Discovery ECC Queue View.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ECC_Queue_View.gif License: unknown Contributors: Swood Image:Discovery_Log2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.png License: unknown Contributors: Swood Image:JAR_File_Sync.png Source: http://wiki.servicenow.com/index.php?title=File:JAR_File_Sync.png License: unknown Contributors: Steve.wood Image:Mid server app.jpg Source: http://wiki.servicenow.com/index.php?title=File:Mid_server_app.jpg License: unknown Contributors: David Loo, Steve.wood Image:MID_Server_Download.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Download.png License: unknown Contributors: Steve.wood, Swood Image:Caution-diamond.png Source: http://wiki.servicenow.com/index.php?title=File:Caution-diamond.png License: unknown Contributors: John.roberts Image:MID config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_config.png License: unknown Contributors: Swood, Tom.dilatush Image:MID config xml.png Source: http://wiki.servicenow.com/index.php?title=File:MID_config_xml.png License: unknown Contributors: Tom.dilatush Image:MID_Server_Roles.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Roles.png License: unknown Contributors: Swood Image:MID_Server_Unblock_Config.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Unblock_Config.png License: unknown Contributors: Steve.wood Image:MID_Server_Clusters_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Clusters_Diagram.png License: unknown Contributors: Swood Image:MID_Server_Cluster1.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Cluster1.png License: unknown Contributors: Swood Image:MID_Server_Monitor_Interval.png Source: http://wiki.servicenow.com/index.php?title=File:MID_Server_Monitor_Interval.png License: unknown Contributors: Swood Image:Discovery Port Probe2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe2.png License: unknown Contributors: Swood Image:Database Catalog Menu.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Menu.gif License: unknown Contributors: Swood Image:Database Catalog2.png Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog2.png License: unknown Contributors: Steve.wood Image:Database Catalogs1.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalogs1.gif License: unknown Contributors: Swood Image:Database Catalog Form.gif Source: http://wiki.servicenow.com/index.php?title=File:Database_Catalog_Form.gif License: unknown Contributors: Swood Image:Probe_Parameters.png Source: http://wiki.servicenow.com/index.php?title=File:Probe_Parameters.png License: unknown Contributors: Steve.wood Image:Newprobe.png Source: http://wiki.servicenow.com/index.php?title=File:Newprobe.png License: unknown Contributors: Doogiesd, Steve.wood Image:Newsensor.png Source: http://wiki.servicenow.com/index.php?title=File:Newsensor.png License: unknown Contributors: Doogiesd, Steve.wood Image:Discovery Identifiers Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Diagram.gif License: unknown Contributors: Swood Image:Discovery Classification Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Diagram.gif License: unknown Contributors: Swood Image:Discovery Classification Win Server.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Win_Server.png License: unknown Contributors: Steve.wood Image:Discovery Classification Criteria2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria2.png License: unknown Contributors: Steve.wood Image:Reclassify_XP1.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP1.png License: unknown Contributors: Swood Image:Reclassify_XP2.png Source: http://wiki.servicenow.com/index.php?title=File:Reclassify_XP2.png License: unknown Contributors: Swood Image:Discovery Classification Process.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Process.gif License: unknown Contributors: Swood Image:Discovery Classification Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Criteria.gif License: unknown Contributors: Swood Image:Discovery Classifier Criteria New2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classifier_Criteria_New2.gif License: unknown Contributors: Swood Image:Discovery Nmap Scan.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Nmap_Scan.gif License: unknown Contributors: Swood Image:Discovery IP Service.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_IP_Service.gif License: unknown Contributors: Swood Image:Discovery Functionality Def.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Def.gif License: unknown Contributors: Swood Image:Discovery Port Probe.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Port_Probe.gif License: unknown Contributors: Swood Image:Discovery Application Classifier.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Application_Classifier.gif License: unknown Contributors: Swood Image:Discovery XML Parameters.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters.gif License: unknown Contributors: Swood Image:Discovery XML Parameters2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_XML_Parameters2.gif License: unknown Contributors: Swood Image:Discovery Classification Parameter.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Parameter.gif License: unknown Contributors: Swood Image:Discovery Mode CI Item.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Mode_CI_Item.png License: unknown Contributors: Swood Image:Discovery Multiprobe Select.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multiprobe_Select.gif License: unknown Contributors: Swood Image:Discovery Multisensor and Script.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Multisensor_and_Script.gif License: unknown Contributors: Swood Image:Discovery Classification Identity Probe.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Classification_Identity_Probe.png License: unknown Contributors: Swood Image:Discovery Identifiers2 Diagram.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers2_Diagram.gif License: unknown Contributors: Swood Image:Discovery Identifiers Form.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Form.png License: unknown Contributors: Swood Image:Discovery Identifiers Order.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Identifiers_Order.png License: unknown Contributors: Swood Image:Credentials_Affinity_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:Credentials_Affinity_Diagram.png License: unknown Contributors: Steve.wood Image:Discovery Credentials.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Credentials.png License: unknown Contributors: Steve.wood Image:Discovery Schedule2.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Schedule2.png License: unknown Contributors: Steve.wood, Swood Image:Discovery Quick Ranges1.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges1.gif License: unknown Contributors: Steve.wood, Swood Image:Discovery Quick Ranges2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Quick_Ranges2.gif License: unknown Contributors: Swood Image:Exclude IP Address.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address.png License: unknown Contributors: Swood Image:Exclude IP Address3.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address3.png License: unknown Contributors: Swood Image:Exclude IP Address2.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address2.png License: unknown Contributors: Swood Image:Exclude IP Address4.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address4.png License: unknown Contributors: Swood Image:Exclude IP Address5.png Source: http://wiki.servicenow.com/index.php?title=File:Exclude_IP_Address5.png License: unknown Contributors: Swood Image Sources, Licenses and Contributors 139 Image:Private_IP_Addresses.png Source: http://wiki.servicenow.com/index.php?title=File:Private_IP_Addresses.png License: unknown Contributors: Swood Image:Network_Discovery_Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Network_Discovery_Schedule.png License: unknown Contributors: Swood Image:IP_Network_Form.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_Form.png License: unknown Contributors: Swood Image:IP_Network_List.png Source: http://wiki.servicenow.com/index.php?title=File:IP_Network_List.png License: unknown Contributors: Swood Image:Discovery_Status.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status.png License: unknown Contributors: Steve.wood, Swood Image:Discovery Log2.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log2.gif License: unknown Contributors: Swood Image:Discovery Log3.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Log3.gif License: unknown Contributors: Swood Image:Discovery Device List.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device_List.png License: unknown Contributors: Swood Image:Discovery Device.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Device.png License: unknown Contributors: Swood Image:Discovery Details.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Details.png License: unknown Contributors: Swood Image:Discovery_Status_IPs.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Status_IPs.png License: unknown Contributors: Swood Image:Discovery ECC Queue.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_ECC_Queue.gif License: unknown Contributors: Swood Image:Discovery_Timeline_Related_Link.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Related_Link.png License: unknown Contributors: Swood Image:Discovery Timeline.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline.png License: unknown Contributors: Swood Image:Discovery_Timeline_Shazzam_Sensor.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_Shazzam_Sensor.png License: unknown Contributors: Swood Image:Discovery_Timeline_ECC_Queue.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Timeline_ECC_Queue.png License: unknown Contributors: Swood Image:Discovery Behavior.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Behavior.png License: unknown Contributors: Steve.wood, Swood Image:Discovery Functionality Criteria.gif Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Functionality_Criteria.gif License: unknown Contributors: Swood Image:Behavior LoadBalance1.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance1.png License: unknown Contributors: Swood Image:Behavior LoadBalance2.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance2.png License: unknown Contributors: Swood Image:Behavior LoadBalance3.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance3.png License: unknown Contributors: Swood Image:Behavior LoadBalance4.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance4.png License: unknown Contributors: Swood Image:Behavior LoadBalance5.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LoadBalance5.png License: unknown Contributors: Swood Image:Behavior LocalDomain_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New.png License: unknown Contributors: Swood Image:Behavior LocalDomain2_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain2_New.png License: unknown Contributors: Swood Image:Behavior LocalDomain3_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain3_New.png License: unknown Contributors: Swood Image:Behavior LocalDomain5_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain5_New.png License: unknown Contributors: Swood Image:Behavior LocalDomain New Schedule.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_LocalDomain_New_Schedule.png License: unknown Contributors: Swood Image:Behavior ACL_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_New.png License: unknown Contributors: Swood Image:Behavior ACL1_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL1_New.png License: unknown Contributors: Swood Image:Behavior ACL2_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL2_New.png License: unknown Contributors: Swood Image:Behavior ACL3_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL3_New.png License: unknown Contributors: Swood Image:Behavior ACL Schedule_New.png Source: http://wiki.servicenow.com/index.php?title=File:Behavior_ACL_Schedule_New.png License: unknown Contributors: Swood Image:Plugin.gif Source: http://wiki.servicenow.com/index.php?title=File:Plugin.gif License: unknown Contributors: CapaJC Image:Traffic2.JPG Source: http://wiki.servicenow.com/index.php?title=File:Traffic2.JPG License: unknown Contributors: Dan.sherwin Image:Discovery_Bandwidth_Graph.png Source: http://wiki.servicenow.com/index.php?title=File:Discovery_Bandwidth_Graph.png License: unknown Contributors: Steve.wood Image:Application_Dependency_Map_Icon.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map_Icon.png License: unknown Contributors: Swood Image:Application_Dependency_Map.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map.png License: unknown Contributors: Swood Image:UpstreamDownstream_Relationships.png Source: http://wiki.servicenow.com/index.php?title=File:UpstreamDownstream_Relationships.png License: unknown Contributors: Swood Image:Application Dependency Map2.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map2.png License: unknown Contributors: Swood Image:Application_Dependency_Map4.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map4.png License: unknown Contributors: Swood Image:Jboss2 apache.jpg Source: http://wiki.servicenow.com/index.php?title=File:Jboss2_apache.jpg License: unknown Contributors: Dan.sherwin Image:Application_Dependency_Add_Icon.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Add_Icon.png License: unknown Contributors: Swood Image:Define_Relationship.png Source: http://wiki.servicenow.com/index.php?title=File:Define_Relationship.png License: unknown Contributors: Swood Image:Application_Dependency_Map3.png Source: http://wiki.servicenow.com/index.php?title=File:Application_Dependency_Map3.png License: unknown Contributors: Swood Image:VMWare_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_VCenter_Diagram.png License: unknown Contributors: Swood Image:VMWare_No_VCenter_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:VMWare_No_VCenter_Diagram.png License: unknown Contributors: Swood