Discovery Exclusions for discovery schedules still being scanned

[Josh Evans]

Hello,

We have several IPs that we need excluded from discovery scans that are still being scanned during our discovery schedules. I have also added these IPs to our exclusion list of our global discovery range set and they are still being scanned. Has anyone ran into this issue before and if so how did you go about troubleshooting and resolving it?

Thanks,

Josh

[pratiksha5]

I use this personally and it works fine. Can you share the screenshot of the exclusion and also the schedule screenshot?

[Fabian Kunzke]

Good morning Josh,

This is a hard topic to get on top of. The reason is, that scanning IP addresses can happen for mutliple reasons. But let's go through that step by step.

1) Range Item crossover

The first and most important concept is range item crossover. This means, that you can have range items which contain addresses of other range items. For item exclude lists, this concept is important. It leads to an issue where you can have something in your exclude list for one range item, but not for another. As you've hinted, you can use the global exclude list to go around this issue. Here is a support article guiding you how to use it.

If you want to troubleshoot this, deactivate every discovery schedule, then run them one-by-one. This will tell you, which schedule still runs towards those ip addresses.

2) Discovery actions outside of schedules

Now, it is important to understand that you can go around the schedules themselves when it comes to discovery. This - however - shouldn't be a larger scale topic. To check if this applies, verify the following questions:

- Does this happen on a regular basis?

- Does this happen continuously?

- Does this happen to a constant set of ip addresses?

If it does happen regularly outside of discovery schedules, check for any custom scripts which utilize discovery functionality. As an example we developed a pinging tool which just pings the ip-address on demand to see if it is active or not. This was used quite frequently and thus looked like a scheduled action.

If it happens continuously, but not regularly, check for on demand actions and possibly workflow triggered interactions.

If it happens with a constant set of ip addresses, reach out to the owners of the devices behind them. This could also be the result of some monitoring interaction.

Now that said, if you already checked step 1), my best bet are on-demand/quick discoveries which largely ignore discovery setups (Note: the discover now action does not count here).

3) Use mid server range definition

If all of this fails to get you anywhere, you should define ip excludes for the mid servers. This results in any and all interaction where a mid-server and any of the ips are involved to no longer work.

In short:

1) Step through your schedules to check for overlap and non-global excludes

2) Check for custom actions, Service Mapping setups (note: service mapping does NOT ignore global excludes), Event Management & SecOps interactions

3) Contact the device owners to pinpoint which mid-servers are interacting with the devices

4) Use Mid-Server ip exclude lists to lock out any communication of the mid-servers towards the devices

Hope this guides you into a feasable direction.

Regards

Fabian

[Yashsvi]

Hi @Josh Evans,

To exclude the child application service from being scanned during the Parent application service discovery in ServiceNow Discovery:

1. Navigate to Discovery > Discovery Schedules.
2. Find and open the schedule used for the Parent application service.
3. Go to the Exclusions tab in the schedule configuration.
4. Create a new exclusion rule:
   • Set the type to CI Class.
   • Specify the CI class name of the child application service.
5. Save the exclusion rule and apply it to the discovery schedule.
6. Test by running a discovery and verify that the child application service is no longer scanned as part of the Parent application service.

This should help resolve the issue of prolonged Service Map discovery times by excluding unnecessary scans of the child application service.

Thank you, please make helpful if you accept the solution. 

[NCS1]

I was facing a similar issue and came across the replies, particularly one from @Fabian Kunzke , where he mentioned something regarding custom scripts.

Here’s what I experienced:
The discovery schedule was picking up IPs that were already excluded via Global Exclusions. I verified this by running a Quick Discovery, which correctly showed that the IP address 10.0.X.X could not be discovered since it was part of the global exclusion list.

However, the MID Server scans were still discovering these excluded IPs. Fabian’s suggestion about custom scripts helped me pinpoint the issue. Specifically, I looked into this fix script :  IP Address Column Type in Discovery, which impacts the Discovery Range Item Exclude table.

Here’s what I did:

1. I added the exclusions directly into the Discovery Range Item Exclude table.
2. Instead of running Quick Discovery, I ran the scheduled discovery that scans the relevant range.

This resolved the issue for us. I recommend trying it out in your sub-prod environment first.

Hope this helps!