Discovery Fundamentals Training: Lab FAQs
Introduction:
Welcome to the ServiceNow Discovery Fundamentals class.
What we have compiled below is a list of pointers, hints and gotchas that we have helped students with, when we support them with the Labs for Discovery Fundamentals, over the numerous Discovery Fundamentals Sessions we have delivered for ServiceNow.
Labs for Discovery Fundamentals require about 50% of the time in the class and are key to ensure students understand how ServiceNow Discovery works.
This article is intended for current students of Discovery Fundamentals to help them preempt any foreseen issues that they may face during their Discovery Fundamentals labs, resulting in a deeper understanding of the concepts.
We have also included Lab walk-thrus (without audio) to help folks who may be stuck with specific labs or even as a means for existing students to review the labs, once the Discovery Fundamentals class is over.
We constantly update this article, based on learnings from every new Discovery Fundamentals class we teach.
Additional updates are made to this article to accommodate content and syllabus updates by ServiceNow to the Discovery Fundamentals class.
We welcome other Discovery Fundamentals trainers from ServiceNow and other ServiceNow Authorized Training Partners to leverage this article when they deliver their own Discovery Fundamentals training and provide feedback to us, so we can update this article and collectively deliver the best experience for our students!
Help! I am stuck with the Lab!
If you are stuck…
Trace back a couple steps. You may be going a little too fast and may have missed a step prior to your current step.
Read a couple steps forward. Very often the solution is right there in the eBook. This is very applicable, especially in scenarios where the labs are designed to fail. The error that you are stuck on is there by design and the solution is detailed in the steps that follow!
Look at the article below! We may already have a solution for you based on others facing the same issue.
Look at the Lab walk-thru YouTube links provided below! An end-to-end walk-thru of the lab can provide significant insights to help understand why you are doing the lab.
We urge you to take the time to do some self-troubleshooting of the lab steps, if things don’t work the first time around. Unlike when we were ‘real’ students, this class is not as much about completion of the labs as it is about really understanding the context and the concepts each lab is trying to deliver. We prefer you take the time at your pace to understand each step vs rushing to complete the labs without understanding why things are working the way they are.
If you are still stuck…
Provide the Page Number and the Lab Step in Zoom
Example: Page ### and Step 5.2.C.2
Provide as much context as possible, so we can help troubleshoot the problem
Discovery Fundamentals Training: Lab FAQs
Remember:
Information contextual to the class, like Instance Registration URL, Private IP Addresses, etc. is available via Zoom.
Save all the instance links, host and credential information received while reserving the instance. You may need it again.
If left navigation ceases to work, simply remove and re-add to the favorites.
Shout out to all folks experienced with IP Addresses… the subnets we use for the lab are 198.51. NOT 192.51.
If you come across "Authentication failed" in discovery message on a specified IP Address go back to Credentials to verify Username/Password from eBook for the specified device. Be careful for typos and invisible trailing blanks. Verify credentials using Related Link "Test Credential" on Credential form. Follow this practice even while creating new credentials.
For discovery message error: “198.51..xxx.xxx is not a reachable host (no response to target ports scanned by MID)” look for typo in IP Address referencing the eBook. However, in the ‘real world’ it may mean the device is not accessible due to firewall rules/routes or ports blocked or network connectivity. Additionally for network devices, missing credentials or incorrectly configured ACLs (on the network device - even if the SNMP port is open) may also cause this error.
Discovery Fundamentals requires access to a remote Windows Server (in addition to the ServiceNow Instance). You will need to RDP (Remote Desktop) to that Windows Server.
To RDP on Windows, see the one minute walkthrough at: https://youtu.be/T0ZzHjLtk2s
To RDP on Mac, download the client via the Mac App Store
Lab 1:
Lab walk-thru on YouTube:
Lab 1.1.B, Lab 1.1.C:
Lab Pointers:
1.1.A.4:
The default layout is 3 columns with equal width.
Lab 2:
Lab walk-thru on YouTube:
Lab 2.1:
Lab 2.2:
Lab Pointers:
NOTE:
This lab (i.e. the installation of the MID Servers) MUST be done via RDP on your MID Server Host. The MID Server installation files are already downloaded for you on your MID Server Host.
DO NOT download and install the MID Server on your local workstation, else the labs that follow will NOT work.
2.1.A:
To connect to the RDP Window Server Host (i.e. your MID Server Host), use the Public IP Address, Username and Password from the Instance Reservation Page.
If you can not connect to the Host via RDP
Make sure you have an RDP Client installed on your computer.
Confirm that you are using the Public IP Address of the MID Server Host, not the Private IP Address. Private IP Addresses start with 198.51 for the labs.
If you are on your work network (including via VPN) or using a device provided to you by work, it may block RDP connections. Try the same connection directly via your home network or personal device.
Make sure you don’t have previous credentials stored on your RDP Client, which would result in authentication failure.
2.1.A.4:
Go ahead and delete the error logs (if any) for empty reports.
2.1.C.4:
Remember that the Instance URL starts with ‘https://’
Remember that the Instance URL ends with ‘lab’
Avoid the trailing ‘/’ while copying the URL
2.1.C.5:
If ‘Test your connection’ fails and you get an error message ‘Connection failure: Error occurred during test connection’
Check for typos, especially leading and trailing spaces in the Username and Password fields
Recheck step 2.1.B.8
2.1.D.7:
Validation of the MID Server may take up to five minutes. Be patient.
2.2:
Remember, all the three MID Servers must be installed, validated and running as this is required for subsequent labs.
2.2.A:
Use the same MID Server Username and Password for the three MID Servers
Lab 3:
Lab walk-thru on YouTube:
Lab 3.1.A, Lab 3.2.B, Lab 3.2.C:
Lab Pointers:
3.1.A.6:
The Internal IP Address of your MID Server Host is visible on the Desktop (top right) of your MID Server Host. Use this above IP Address for discovery.
3.1.D.6:
Remember to use the value of ‘Configuration Item’ and NOT ‘IP Address’ for the ‘Discovery’ Attribute on the ‘Discovery Schedules’ Form.
3.1.D.9:
The ‘Make Ranges’ button is at the bottom of the ‘Quick Ranges’ pop-up, which is triggered when you click the ‘Quick Ranges’ Related Link.
3.1.Challenge 1:
Use the Internal IP Address of the Instructor’s MID Server Host.
If you are using the IP address of another Student, remember to use their Internal IP Address (which starts with 198.51)
3.1.E.10:
The password is the same password used during the RDP to the MID Server Host from the instance reservation page.
3.1.E.12:
If it takes too long to ‘Restart’ the Windows Service, simply ‘Stop’ it and ‘Start’ it back again.
For the error ‘Service did not start due to Logon failure error’, check for typos and trailing blanks in Username and Password for the Windows Service.
3.1.Challenge 2:
Ignore the following errors in the logs as there are a result of the failure of the Exploration (ADM) Probe as this probe uses PowerShell which requires credentials to be configured in the Credential Table in ServiceNow. (These are configured in the next lab)
Exception calling “.ctor" with "2" argument(s):
Lab 4:
Lab walk-thru on YouTube:
Module 4: Credential-less Discovery: [by ServiceNow]
Lab 4.1.A, Lab 4.1.B, Lab 4.1.C, Lab 4.1.D, Lab 4.1.E:
Lab 4.2.A, Lab 4.2.C [USE 198.51.188.74 instead of 198.51.234.24]:
Lab 4.2.D [USE 198.51.188.74 instead of 198.51.234.24]:
Lab 4.3 [USE 198.51.188.74 instead of 198.51.234.24]:
Lab 4.4:
Lab Pointers:
NOTE: ‘Test Credential’ Related Link on the Credential Form is a very useful to validate your entered password before running the Discovery Schedule.
4.1.B.6:
Related Link ‘Test Credential’ is an important take-away as it allows you to validate the credentials before running discovery.
4.1.B.7:
If ‘Test Credential’ fails, then
Revalidate the Device IP Address and Credentials from the eBook.
Ensure there are not any training spaces accidentally included in the Username or Password fields.
4.1.C:
There are two OOB Schedules (to discovery Services) in the Lab Instance that are scheduled to run daily. You can ignore these OOB Schedules and the Discovery Status corresponding to these OOB Schedules.
4.1.C.3:
An alternative way to create / add new discovery schedules is by navigating to
Discovery > Discovery Schedules > New [as shown in Lab walk-thru YouTube video]
4.1.C.11:
If Credentials were tested successfully, but discovery still fails, then
Reconfirm the accuracy of the IP Address defined in the Range Items of the Discovery Schedule.
Given multiple students are discovering the target Device at the same time, it is possible that the target Device is busy, so retry discovery in a few minutes.
4.2.C.4:
If you get error ‘Cannot connect to that port’, check if the Credential created is of type SSH.
See Note for validating credential.
4.2.C: Challenge 1: (Required)
Ignore the error “Host hosted on cloud environment has been detected, but no matched cloud object found.” in the discovery log as this error is due to the Virtual Machine Instance not discovered before discovering the Virtual Host. Virtual Machine Instances on AWS are discovered via Cloud Discovery.
4.2.D:
There is a problem with the SSH Private Key for IP address 198.51.188.74. You can use IP 198.51.234.24 to test the SSH Private Key or skip it. Remember to activate the Linux Server Discovery Credentials so they can be used later in the labs.
4.3.B.3:
Don’t forget to add the (private) IP address of your Windows Server (starting with 198.51…) before you run the ‘WMI Only Discovery’ schedule. You can add this via the ‘Quick ranges’ UI Action under ‘Related Links’.
Failure to do so will result in the Discovery Schedule to get cancelled as there are no IP Addresses associated with it.
4.4.C:
Remember to create an SNMP Credential with community string ‘public2’. Note that SNMP v2 Credentials only require Password (i.e. community string), no Username.
4.4.D.6:
For ‘Behaviors’ to run correctly, ensure that ‘Functionality Definition’ are also configured.
4.4.F.2:
Adding the ‘Classification priority’ to the List View allows us to easily change the values in the subsequent steps.
4.4.F.3:
You can keep the priority snmp = 1 | wmi = 2 | ssh = 3 for the rest of the labs. The classification priority doesn’t impact the labs that follow.
However, in your ServiceNow Instance at work, we recommend to retain the default Classification Priority.
Lab 5:
Lab walk-thru on YouTube:
Lab 5.1:
Lab 5.2 [USE 198.51.188.74 instead of 198.51.234.24]:
Lab 5.3:
Lab Pointers:
5.1.B.4:
To get ‘Additional Actions’, click on the three small horizontal lines on the Form.
5.1 Challenge 1 (Required):
Remember, it’s the ‘Discovery Status’ Form, not the ‘Discovery Schedule’ Form that has the ‘ECC Queue’ Related List.
A ‘Discovery Status’ is created when you run a ‘Discovery Schedule’.
5.2.D.10:
‘Write down your time’ in the screenshot refers to the time you see on your instance, NOT the time from the screenshot in your eBook. This time will be used in the next following steps.
5.2 Challenge 1 (Optional):
After completing this challenge, remember to re-slide the ‘Unix Servers & Computers’ from ‘disabled’ to ‘enabled’ so that Unix Discovery can take place in the labs that follow.
5.3.A.1:
Remember to create an SNMP Credential with Password (i.e. the community string) as ‘public3’.
Note that SNMP v2 Credentials only require Password (i.e. community string), no Username.
5.3.A.3:
For a network device, missing credential and/or missing ACLs on the device gives the error “198.51.101.101 is not a reachable host (no response to target ports scanned by MID)” even if SNMP port is open.
5.3.D.3:
Remember to read the Note in the eBook.
5.3 Challenge 1 (Required):
Remember to change the ‘Serial Number’ value on both the Form and the Related List as detailed in the eBook. Only then will you see two separate CIs vs the same one being updated.
Navigate to Network Gear via: Configuration > Network > Network Gear
If you don’t get the expected result, please check step 5.3.D.
DO NOT have both the IP Addresses included in the same Schedule.
Lab 6:
Lab walk-thru on YouTube:
Lab 6.1:
Lab 6.2:
Lab 6.3 [USE 198.51.188.74 instead of 198.51.234.24]:
Lab Pointers:
6.1 Challenge 1:
If you get the error ‘Error: Failed to set option to port [8080]. Cannot bind to port’, it means multiple Mongoose instances are running on the MID Server Host. Kill all Mongoose instances using Task Managed and run ONE new Mongoose instance, following the steps in the eBook. Instructions to run Task Manager are in the note below the screenshot.
6.1.D:
Filter condition for ‘rundll32.exe’ demonstrates that different filter conditions can be used in Process Classifiers.
The ‘Order’ for Process Classification plays a diminished role, since the Process Classifier is executed once the classification criterion is met.
6.1 Challenge 2:
After running discovery, go to the ‘Status’ and open the discovered device by clicking the hyperlink under the ‘CMDB CI’ column under the ‘Devices’ Tab. This will open the CI Form, from where you can navigate to the Dependency View Map.
6.3.B.10:
Remember to deactivate the SSH Process Handler to see the expected results in the steps that follow.
Lab 7:
Lab walk-thru on YouTube:
Lab 7.1:
Lab Pointers:
7.1.C.6:
'Asset tab' should be read as 'Asset tag'.
7.1.E.1:
Open Your Windows Server Record and delete it. Check Asset Tag is ‘ABC123’ before clicking ‘Delete’.
7.1.E.6:
Open Model Category record from the Asset Form by selecting the link icon and clicking Open Record.
Lab 8:
Lab walk-thru on YouTube:
Lab 8.1:
Lab 8.2:
Lab 8.3:
Lab 8.4:
Lab Pointers:
NOTE:
Do NOT forget to Save and Publish the patterns after making updates
Do NOT cancel the steps processing in Debug Mode. Debug steps processing should run completely and ‘Debug Mode’ button should be green, confirming you are in Debug Mode
Do NOT delete OOB patterns
Name of any ‘Discovery Pattern’ can be changed just by by changing it in Pattern form. (Though it has no effect on discovery it is not recommended to change of OOB Pattern).
When you delete any extension section from a pattern it will not allow you to created a new extension section with the same name unless you go to 'Discovery Patterns' and delete the pattern (shared library) with the name same as the extension section you deleted. (Every extension section is an independent shared library pattern created whenever you add an extension section in the pattern)
To troubleshoot the failed Patterns, go to discovery log and click on ‘To Check Pattern Log Press Here’, which takes you to "Horizontal Discovery Log". In there if you further explore the RED items and the ‘Check Processing Success’ you will get more information on the reasons for pattern failure.
8.1.A.6:
Restarting the MID Server may take up to three minutes, so be patient.
8.1.C.25:
The text ‘Add Variable: (add 2 new variables)’ means replacing:
_Table_Name_ with cmdb_ci_win_server and adding u_bios_date below itRefer to the ‘Variables’ section on the screenshot of the next step.
8.1.C.26:
If you get error ‘Error: Failed to parse content due to the following error: INVALID_REGEX length: 2’, then check the your RegEx Syntax. Refer or see the ‘Variables’ section of the screenshot.
8.1.D.4:
If you see the error in Pattern Log of failed pattern "Discovery status is FAILURE, Discovery using patterns failed due to lack of existence of the main CI type in the results", it generally means there is a typo in CI table name or the attribute defined in pattern steps.
Recheck your pattern steps for typos.
8.2:
There may be a possible error in OOB Pattern. It has no impact to the lab and can be ignored.
The answers to Challenge 1 and Challenge 2 for this lab are given on the pages that follow after the respective challenges are presented. Simply click over to the next respective pages for the step-by-step solution.
8.2.B.18:
If you don’t get the expected output as shown in the screenshot, check for typos in the ‘Variables’ Section on the Form.
8.2.C.8:
Ignore the error "There is no Veritas Cluster process running on this server ......"
8.2.C.10:
The pattern so far is configured to capture the value of “u_run_level” but not assigned to the field in the CMDB as yet. In this result line "setAttribute(runlevel_info,[])", the variable <u_run_level> is a temporary variable in temporary table <runlevel_info> in the Pattern only. In the ‘real world’ you can adjust your table variable to <cmdb_ci_linux_server> instead of the temporary table variable <runlevel_info> to get the field populated in the CMDB after this step.
These labs are designed to show you usage of various other operations used in Patterns and hence another operation is demonstrated in the lab challenges to populate the CMDB field ‘Run Level’.
8.2 Challenge 1:
Note that this challenge only captures the value for ‘Time Zone’ but does not populate the CMDB field ‘Time Zone’. Reference the text in Challenge 2, which implies the completion of Challenge 2 to see the value updated in the CMDB via the ‘Transform Table’ Operation.
8.2 Challenge 1: Answer
MID is running on Windows Server hosted on the AWS Cloud in the Eastern Time Zone. The “Time Zone” is discovered and populated as either “EST” (Standard Time) or “EDT” (Daylight Time) depending on the time of the year.
8.3.B:
Remember to create an SNMP Credential with community string ‘public4’. Note that SNMP v2 Credentials only require Password (i.e. community string), no Username.
8.4.A:
There is a reference to Lab 9.1, which should actually be a reference to Lab 8.3.
8.4.A.15:
‘Comments’ here refers to 8.4.A.7 (and not the Comments field in the CMDB in ServiceNow). This lab only collect information in the temporary variables created in the pattern, but doesn’t still populate the CMDB. CMDB population happens in the labs that follow.
8.4.D.19:
Whenever SNMP Query' is used in patterns to discover additional attributes of network device then 'sysname' is always captured as 'name' even if not mentioned in pattern variables.
This explain the different names discovered in first (8.3.D.19) and second discovery (8.3.D.19) for the same firewall hardware device.
Lab 9:
Lab walk-thru on YouTube:
Lab 9.1:
Lab 9.2:
Lab 9.3:
Lab 9.4.B:
Lab 9.4.C: [by ServiceNow]
Lab Pointers:
NOTE:
Do NOT forget to Save and Publish the patterns after making updates
Do NOT cancel Debug Mode when developing the patterns
Do NOT delete OOB patterns
Name of any ‘Discovery Pattern’ can be changed just by by changing it in Pattern form. (Though it has no effect on discovery it is not recommended to change of OOB Pattern).
When you delete any extension section from a pattern it will not allow you to created a new extension section with the same name unless you go to 'Discovery Patterns' and delete the pattern (shared library) with the name same as the extension section you deleted. (Every extension section is an independent shared library pattern created whenever you add an extension section in the pattern)
To troubleshoot the failed Patterns, go to discovery log and click on ‘To Check Pattern Log Press Here’, which takes you to the ‘Horizontal Discovery Log’. In there if you further explore ‘Check Processing Success’ of the red items it indicate / hint the reasons for pattern failure.
9.1.C.5:
If the ‘Application’ Related List is empty then run discovery schedule ‘My Windows Server Discovery’ and check ‘Application’ list.
If ‘Application’ list is empty even after above step, then it appears that you have restarted the Windows Server and hence the Mongoose application is not running. In that case navigate to ‘C:\TrainingResources\’ and double-click on ‘Mongoose-free-5.5.exe’ to start the Mongoose Server and run discovery schedule ‘My Windows Server Discovery’ again.
9.1.D.7:
For any error message after "Connect" validate Host IP (Your Windows Server IP) and PID, see “Lab Pointers: Note: 6” for Lab 9 by scrolling above)
9.1.F.11:
The ‘correct name’ implies the name of the Mongoose Web Server, not the Windows Host it’s running on. It is visible in the section where you see the CI Relationships.
9.2.C.10:
To see the results in the screenshot, reconfirm that you are in ‘Debug Mode’.
9.2.D.4:
Recheck your configuration to make sure Target Table is ‘$cmdb_ci_web_server’ for the correct and expected result.
9.4:
First create a new Discovery Pattern for the Mid Server and add it to the trigger list of the MID Server Process Classifier. (refer to similar steps for the Mongoose Pattern)
Then continue as per the ‘B. Possible Solution 1’ and ‘C .Possible Solution 2’, detailed on next pages in the eBook.
Lab 10:
Lab walk-thru on YouTube:
Lab 10.1:
Lab 10.2:
Lab 10.3:
Lab 10.4:
Lab Pointers:
10.1:
You may face an issue with loading slushbuckets. This is a platform issue, not a discovery issue.
10.2:
You may face an issue with loading slushbuckets. This is a platform issue, not a discovery issue.
10.2.A.7:
The ‘N/A’ link fails to open. You can use this link instead:
https://[REPLACE WITH YOUR INSANCE PREFIX].lab.service-now.com/nav_to.do?uri=%2F$pa_dashboard.do%3Fsysparm_dashboard%3D0fd2d590eb102200f6f44d3df106fe1d%26sysparm_table%3Dcmdb_ci%26sysparm_ignore_default_filter%3Dtrue%26sysparm_homepage_filters%3D%2522%257B%2527interactiveFilterId%2527:%255B%257B%2527table%2527:%2527cmdb_health_scorecard%2527,%2527filter%2527:%2527class%253Dcmdb_ci%2527%257D,%257B%2527table%2527:%2527cmdb_health_result%2527,%2527filter%2527:%2527class_nameINSTANCEOFcmdb_ci%2527%257D%255D%257D%2522
Discovery Extras
Additional Resources by ServiceNow: https://tinyurl.com/discovery-extras
Topics Include:
File-based Discovery
Kubernetes
Service Mapping Discovery
Credential-less Discovery
Amazon Web Services Discovery
VMWare Discovery
Storage Discovery
Google Cloud Platform
