Discovery Failing at Windows Classification Despite Existing Discovery Service Account Permissions

[Aman_07]

Hi All,

I would like some clarification on the expected behavior for ServiceNow Discovery when discovering new Windows SQL Servers.

A few months ago, we successfully implemented Windows Discovery using a dedicated service account.

Windows Discovery is currently working successfully for servers that were included in the original Discovery scope.

Current Database Discovery:

We are now implementing SQL Server Discovery and plan to reuse the same Windows service account using Windows Authentication.

The DBA team has already:

• Granted the required SQL access (VIEW SERVER STATE)
• Provided a list of non-production SQL Servers for testing

Issue

When I run Quick Discovery against one of the pilot SQL servers, Discovery fails during the Windows Classification phase

Could not find any valid credentials to authenticate the target for type [Windows]
Active, couldn't classify: No WMI connection

From the WMI Runner logs:

• ServiceNow successfully finds and attempts the Windows credential
• All credential attempts fail authentication
• TCP 135 is open
• WinRM (5985) is open
• DNS resolution is successful

My Question

My understanding was that since the Windows Discovery service account already has the required permissions, I should only need to grant the additional SQL permissions for Database Discovery.

However, based on the behavior, it appears that the SQL pilot servers may require the same Windows Discovery onboarding/configuration to be applied individually on those servers.

Could someone clarify:

1. Are permissions such as DCOM, WMI namespace access, Distributed COM Users, Performance Monitor Users, etc., typically configured on each target server?
2. If a service account already works for Windows Discovery on one set of servers, should it automatically work on other Windows servers?

Any guidance would be appreciated.

Thanks in advance.

[BharatC · Accepted solution]

Hi @Aman_07 

Those WMI/DCOM permissions live locally on each server — they don't travel with the service account. So even though your account already has AD-level access and works on your original servers, each new server needs those same local permissions set up on it individually (usually via a GPO scope or manual config).

Confirm with your Windows/AD team whether the pilot SQL servers are in the same OU/GPO scope as your original Discovery servers. If not, apply the same GPO (or manually configure DCOM/WMI/local group permissions) to the pilot servers, then re-run Quick Discovery

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards

Bharat Chavan

[Aman_07]

Hi @BharatC , Thank you..S

Any way to request the OS access, and to have that rolled out on a large scale.  it’s not a sustainable ask to  deploy that to the ~400 servers in footprint that have SQL.

Just wanted to understand, How to be rolled out on a large scale?

[BharatC]

hi @Aman_07 

Add all 400 SQL servers to one AD security group and attach a GPO to it — that handles local group membership and firewall rules automatically. For DCOM launch permission and WMI namespace access, which GPO can't set directly, push a small PowerShell script through that same GPO as a startup script so it applies itself without manual work. Test on a few servers first, then roll out in batches, and check with your AD team whether your existing Discovery servers already use a similar GPO you can just extend.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards

Bharat Chavan

[Aman_07]

@BharatC  Thanks..very helpful