We would like to avoid discovering end user devices (laptops / desktops) from ServiceNow Discovery as we have SCCM for pulling in information for these devices. Any suggestions?

[Sanya2]

We would like to avoid discovering end user devices (laptops / desktops) from ServiceNow Discovery as we have SCCM for pulling in information for these devices, 

Do you have any best practices around this? Any tips & tricks? Suggestions?

Thx,
Sanya

[DaveHertel]

Hi -- some common options for this scenario:

1.  If end-user devices on dedicated subnets (i.e. subnets not mixed with IT infrastructure, servers, etc.) then avoid adding IP subnets to Discovery scope.  Allow these devices to come into CMDB via SCCM feed, w/o overlapping w/disco source.  If your subnets are mixed use -- i.e. some end user stuff and some infrastructure, this is harder/impossible to implement.  But if network subnets are cleanly allocated in this way, this is by far the easiest approach to differentiate Disco scope from SCCM scope.

2. Use IRE (identification reconciliation engine) to prioritize what data sources can update what classes/fields.  i.e. set priority for Discovery for stuff like server class, while perhaps SCCM data source can update computers/workstations.  While SCCM is lesser priority for updating CI's in CMDB that Disco is the main system of record (SOR)

3. lastly (definitely NOT preferred... but possible) use biz rules/script/automation to reject inbound feeds based on criteria you set.   i.e. reject CI update for X class from Y source.

Hope this helps?

[Sanya2]

Thanks for the options Dave. They are helpful.

In our scenario, #1 is ruled out as we have many mixed use segments 😞

As regards #2, SCCM pulls data into cmdb_ci_pc_hardware class (derived from computer class) and Discovery ends up identifying end user devices and pushing them to cmdb_ci_computer class thereby creating duplicates. 

Is there anyway we can run a script before discovery creates a CI to check and see if it is an end user device? Which data attribute would that be?

Thx,
Sanya

[DaveHertel · Accepted solution]

Hi -- well, in your case I'd look at the pattern (assuming you have migrated to patterns) to adjust as needed.  Consider making changes to the EXTENSION section of the pattern so your changes can avoid, if possible, alterning the OOB ID section of the pattern.  Extension section is intended for customers to make their own medications.   The patterns are basically a set of instructions/script that you can use per your custom business needs.

As for the data attribute for the end user device - you'll have to determine what logic makes sense for your case.  Whatever data element(s) uniquely define your computers as end-user vs. infrastructure servers.   Perhaps the OS name/description (like "server".. or lack thereof) - similar to how classifiers work to differentiate windows.

Hope this helps?

[Sanya2]

Thanks Dave.

That helps. 

Thx,
Sanya