Service Mapping Mid Servers

tim_sewell · ‎03-10-2016

How does Service Mapping decide which Mid Server it will use for an end point?

I have 2 Mid Servers configured in different domains, 1 for our Prod domain and 1 for our Test domain. I created a new business service with an end point to a Web server in the Prod domain. I would assume that Service Mapping would recognize the domain and choose the correct Mid Server to discover with. It does not seem to be the case, as the discovery fails with a "Failed to communicate with the WMI collector service on localhost." message.

If I disable the Test domain Mid Server, and run the discovery again, it maps the Web server correctly. If I start up the Test domain Mid Server service, it fails again... This leads me to believe that Service Mapping is choosing the Test domain Mid Server by some property or setting. I have searched all of the documentation I can find on Service Mapping, but I cannot see where this setting may be. Other steps I have tried:

Removed ALL credential affinities and ran a regular ServiceNow Quick Discovery on the Web server, to establish affinity between it and the Prod domain Mid Server.
Created a Mid Server IP Range, including the IP of the Web server and assigned it to the Prod domain Mid Server.
I assigned the Prod domain Mid Server to be the default Mid Server for Orchestration activities

What am I missing?

jonathanjacobcp · ‎03-15-2016

Hi Tim,

See the following KB article on hi:

ServiceNow Customer Service System

Improving MID Server selection algorithm

Problem

Service Mapping creates discovery requests that contain the IP address of the entry point, the probe and the MID Server. Service Mapping then writes them in the ECC Queue table of CMDB (ecc_queue).

In Geneva patch 1-4, Service Mapping selects MID Servers for discovery requests using only IP ranges. If a MID Server does not have a defined IP range, Service Mapping treats it as suitable for any IP range and therefore can assign any discovery request to it. In a situation where there is a MID Server with the IP range matching the discovery request and a MID Server with no defined IP range, Service Mapping may select the MID Server with no defined IP range.

Symptoms

Service Mapping may not discover the CI from the entry point.

Imperfect algorithm for MID Server selection in Service Mapping.

Resolution

The algorithm of selecting MID Servers for discovery requests is improved in Service Mapping starting with Geneva Patch 5. We recommend that customers using earlier versions install a business rule that improves MID Server selection.

The business rule changes the algorithm to the following:

(Optional, needs to be configured) Service Mapping can assign discovery requests only to MID Servers configured to work with Service Mapping
Service Mapping uses only MID Servers with defined IP ranges
If there are any entry points with IP address that does not match any defined IP ranges in MID Servers, Service Mapping assigns the discovery request for this entry point to the default MID Server
If there is an entry point with no IP address (using hostname, such as http://www.google.com), Service Mapping assigns the discovery request for this entry point to the default MID Server

As a result, Service Mapping cannot randomly assign requests to MID Servers with no defined IP range.To install and configure this business rule, perform the following steps:

Install the business rule by importing the MIDBusinessRule.xml file attached to this KB article.
To use only MID Servers configured to work with Service Mapping:a. Navigate to the System Property table and click New.b. In the Name field, enter sa.service_mapping.use_capabilities.c. From the Type list, select true|false.d. In the Value field, enter true.e. Click Submit.
To select a MID Server as the default MID Server for Service Mapping:

a. Navigate to the System Property table and click New.

b. In the Name field, enter mid.server.sm_default.

c. From the Type list, select string.

d. In the Value field, enter the name of the MID Server to use as the default.

e. Click Submit.

For more information about business rules, see Business Rules.

View solution in original post

tim_sewell · ‎03-17-2016

Appreciate your reply Jonathan. We will look forward to applying Geneva Patch 5. Thanks!

Alicia13 · ‎07-25-2018

Can someone tell me how long Service Mapping has been around? I don't mean to bother you with an unrelated topic/response. I'm working on a position for a SNOW Configuration Management Analyst who is an "expert" at Service Mapping. I've been told by a couple of SNOW consultants that I likely won't find one because it hasn't been out long enough.. just wanted to see if that was the case. 🙂

THANK YOU SO MUCH!

tim_sewell · ‎07-25-2018

My 2 cents..

Service Mapping has only been around for a couple of years as a part of the ServiceNow suite. ServiceWatch was the product that ServiceNow acquired and rebranded as Service Mapping. That product had been around for a while longer, and you may be able to find some experts in ServiceWatch. Though, so much has changed in the integration of ServiceWatch into ServiceNow Service Mapping, that you would need to find someone who has been actively developing with it since the start.

I've been working with it since the acquisition, and now with the integration of Service Mapping patterns into the regular discovery process, I can say.. I'm continually learning how the product works.

Alicia13 · ‎07-25-2018

Tim, thank you so much. This has been incredibly helpful and informative. I do appreciate it! Any chance you're on the market? 🙂 I had to ask.

tim_sewell · ‎07-25-2018

Happily employed, sorry, but thank you