Discovery Access for Various Classes

[gregpower]

We are expanding the classes we discover in our CMDB by quite a significant amount. All of which we've determined will be a Principal Class. Some are on Prem, some are AWS Cloud but the one roadblock we have seen for everything is around the appropriate access for discovery to pull in the required data. The issue we run into is there doesn't seem to be a quick way to validate that access short of setting up the full discovery pattern. With so many to onboard we want to have the pre-requisites implemented and validated prior to the developers setting up the pattern to speed things along. 

Is there any tools that people use to validate all the Pre-requisites for a new class? Any suggestions on how to speed up the access validation would be greatly appreciated!

[pavani_paluri]

Hi @gregpower ,

When you expand your CMDB and add new classes, the hardest part is making sure ServiceNow Discovery has the right access (credentials, ports, permissions) before you start building or customizing discovery patterns. Out of the box, ServiceNow doesn’t give you a simple “pre‑flight check” button that says yes, this credential works for this class. The only guaranteed way to test is to actually run a discovery pattern, which can be heavy and time‑consuming.

Test credentials directly: In the Discovery Credentials list, you can pick a credential and run a quick test against a server. This checks if ServiceNow can log in (SSH, WMI, SNMP, API, etc.) without running the full pattern.
Run lightweight probes: Instead of a full discovery, trigger just a probe (like SSH for Linux, WMI for Windows, AWS API for cloud). These are small checks that confirm connectivity and authentication.
Validate cloud credentials: For AWS, Azure, or GCP, ServiceNow has a built‑in option to test whether your keys or roles have the right API permissions before you run discovery.
Use debug logs: Run discovery on a single IP with debug enabled. The logs will show exactly where it fails — whether it’s a credential issue, a closed port, or something else.
Manual checks outside ServiceNow:

Sometimes the fastest way is to test the account directly:
Log into a Linux box with the discovery account over SSH.
Run a WMI query on a Windows server with the discovery account.
Use AWS CLI or Azure CLI with the IAM role/service principal to confirm permissions.

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for

Kind Regards,

Pavani P