Another year has passed and with it there have been new and interesting experiences here at Einar & Partners. We have been involved in everything from evaluations to see how well organisations are fitted to implement Discovery to implementing discovery from scratch and doing overhauls of many years of old custom Discovery patterns.
My personal involvement has been, primarily, in the first two parts. What have we been able to learn as an organisation from these engagements?
It’s almost never the fault of your ServiceNow instance.
As obvious as this sounds, this is one of the “issues” we run into most often. You start a discovery project with the specifications laid out for your customer to be followed to the letter, and then for some reason you see the message “Adding target to blacklist. No valid credential found for type X” or something to that effect in your discovery log.
You tell the customer and their response is “there must be something wrong with the ServiceNow instance”.
And you start troubleshooting with the customer:
- “Have you opened the ports”
- “Is routing configured?”
- “Is traffic allowed through the firewall?”
- “Are the credentials actually working?”
In about 95% of the cases, one of these questions is the answer to why your Discovery is not working.
See example below of common ports that are used by Discovery:
Something that is often overlooked when it comes to ports however, is the fact that WMI doesn’t just use port 135. When communicating over WMI there is also a number of dynamic ports that are used. Ports 49152-65535 for both TCP and UDP.
Perhaps one of the more common issues to run into, is that communication isn’t allowed on these dynamic ports when using WMI. Luckily nowadays, not a lot of customers use WMI due to security concerns, but there are certain scenarios when and where it may be applicable to an implementation.
But I digress. There are of course exceptions to the rule that it not being an issue with ServiceNow, and we ran into one of those exceptions during the past year with a customer who was creating a new production environment to restart their CMDB from scratch. At the time they were using two production instances in parallel, which in turn lead to a whole host of issues when it came to plugin installations, compatibility of plugins etc. That was one of the very few times that we actually had to be in contact with ServiceNow for support.
Security is important, we understand that
Security aspects are of course of the utmost importance when it comes to Discovery. It is, depending on what you run Discovery on, a somewhat invasive procedure with potential high levels of access requirements. Naturally, we take the utmost care when we do our engagements to be as accommodating as possible to the customers security concerns, but at some point we need to draw the line as to how accommodating we can be, mostly when it comes to what is technically and practically feasible.
It happens that salespeople are a bit too good at selling and a bit too unfamiliar with the product they are selling. We ran into one of those scenarios in the past year as well. The implementation was Discovery and Service mapping. What was sold however was Agent Based Discovery, due to its higher level of security.
If you are familiar with Discovery, ACC-V and Service mapping, you can already see where this anecdote is going.
We start the project and get informed that the customer wants to implement Service mapping using the agent-based approach. At that point we must pull on the break and tell them that at the current stage of ACC-V, that’s not technically possible to do (as patterns aren’t supported). In other words, they can’t leverage Service Mapping with agent-based discovery.
Being aware of the limitations each option brings when it comes to Discovery is key (see previous infographic).
After investigations of the organisations infrastructure and security policies, we unfortunately concluded that their software was too old to enable Service Mapping and be compliant with their requirements. Ultimately, no solution was found that would allow for Service Mapping to be rolled out.
“Measure twice, cut once.”
A good saying from the world of carpentry is “measure twice, cut once” – meaning doing it right the first time.
As mentioned in one of the examples above, we have seen situations where organisations don’t have the maturity to use the Discovery product to its full extent. We have also seen plenty of organisations where licenses are bought and then they sit for years and years before they get used, wasting money and potential.
If you are interested in implementing Discovery within your organization, check with your account manager, check with a sales engineer, and preferably, consult with a third-party to see if your organization is actually fit to implement the solution you wish to implement. Taking on an independent third party can also help you in the right direction for the future.
But remember; it’s most likely not the ServiceNow instance if discovery stops working.
Author: Christoffer Virtanen, ITOM- & AIOps Consultant
