Discovery Vs. SCCM Integration with ServiceNow

michaelmorgan
Giga Contributor

Hi,

I'm quite new to the Asset Management and CMDB side of ServiceNow as my business does not use this currently, but I'm interested in floating the idea of doing this.

I was wondering if someone on here who has possibly used both Discovery and SCCM Integration with SN could let me know the advantages of either importing SCCM data into the ServiceNow CMDB or using Discovery?

I'm under the impression Discovery would enable ServiceNow to use more advanced techniques of service mapping for each CI?

Any responses will be greatly appreciated!

1 ACCEPTED SOLUTION

prabhash_snow
Mega Expert

Hi Michael,



First of all lets understand what are the various use cases of SCCM and DISCOVERY



SCCM : it is used to import data for END USER DEVICES (desktop, laptop, VDI etc) into CMDB      



DISCOVERY : Agent less mechanism to import INFRASTRUCTURE CI data (servers, LB, Routers etc) data into CMDB



In SCCM integration we pull the data directly from the SCCM DB through a plugin. That MSSQL DB contains information about all the Devices present in the Client's environment, whereas in Servicenow Discovery we get the data from a infrastructure CI (WIN, UNIX, NW) by using probes and sensors.



So yes, Discovery gets you more attribute as compared to SCCM. Also, understanding discovery process flow and concepts is a must for Service Mapping and Orchestration (In case you are planning to explore more).


View solution in original post

8 REPLIES 8

prabhash_snow
Mega Expert

Hi Michael,



First of all lets understand what are the various use cases of SCCM and DISCOVERY



SCCM : it is used to import data for END USER DEVICES (desktop, laptop, VDI etc) into CMDB      



DISCOVERY : Agent less mechanism to import INFRASTRUCTURE CI data (servers, LB, Routers etc) data into CMDB



In SCCM integration we pull the data directly from the SCCM DB through a plugin. That MSSQL DB contains information about all the Devices present in the Client's environment, whereas in Servicenow Discovery we get the data from a infrastructure CI (WIN, UNIX, NW) by using probes and sensors.



So yes, Discovery gets you more attribute as compared to SCCM. Also, understanding discovery process flow and concepts is a must for Service Mapping and Orchestration (In case you are planning to explore more).


Also, understanding discovery process flow and concepts is a must for Service Mapping and Orchestration (In case you are planning to explore more).


Would you mind elaborating on this?   We're just getting to Discovery and want to get it right out of the gate.   Thanks!


vtspatsfan,



This would be a good place to start learning about the discovery process flow.



Probes & sensors collect data about a host and insert it into the CMDB. Patterns also collect data, but using a different scripting language.   Discovery occurs in 4 phases: scanning, classifying, identifying & exploring. Essentially, the process starts by simply seeing if an IP address responds on any open ports. The ports found open determine what probes are sent next. The remaining 2 phases just dig deeper and deeper into the system to learn more about it.   If the probes & sensors return data, the CMDB is updated (or a new CI is created, if the device has not been discovered before).



If you are in an environment that is serious about security or contains multiple security zones (or domains), discovery can be a challenge.   You need to have credentials for each type of host your want to discover (Windows, Linux, HP-UX, VMware, SNMP, etc.).   Your SNMP devices may have to be configured to allow the MID server(s) to query them. Your server credentials may need to be added to specific groups on the host to allow the right privileges for discovery to work properly.   Firewall rules may need to be configured to allow your MID server(s) to talk to your hosts. If you're on a Windows network, you're going to need a credential with domain admin rights to discover your domain controllers.   These are just examples, but a fair amount of planning needs to be done before you start.



Once you begin discovering, the hard part really starts -- figuring out why discovery is failing.   There are many reasons discovery won't successfully identify a device and it takes some time to figure out what the discovery logs are actually trying to tell you.   Prabhash was spot on with the comment about understanding the process flow. Knowing which stage of the process is creating the error messages will help you hone in on whether it's a communication issue (Shazzam), a credential issue (probe/pattern) or something else entirely (like WMI queries failing because of a Windows DCOM service issue).   It can be frustrating at times, but figuring out what's happening will give you a lot of satisfaction!



The Community is a great place to get help. And don't forget your local ServiceNow Sales Engineer.   Ours has been great and often spent time with us to work out obstacles we encountered.   They've also helped us escalate issues in HI and to the product team.



Good luck and have fun!



John


John, this is an excellent summary thank you.   We've just executed our first scan on a subset of systems and as you say, there was a lot of prior planning to enable it (FW changes, ACLs, SNMP strings, local FW agent changes, Windows credentials, etc).   And now...   loads of errors to sift through (the fun part?).



Discovery is a piece of a much more comprehensive effort which is the creation/care/feeding of the CMDB.   Now to get our arms around that.