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.

[Aman_07]

Hi @BharatC 

I am currently testing MSSQL Database Discovery on a Windows Server and are encountering an issue during the Windows OS - Servers pattern execution, specifically within the Collect MSSQL Info extension

Error observed

When the pattern attempts to execute commands such as:

wmic /NAMESPACE:\\root\Microsoft\SqlServer\ComputerManagement15 PATH SqlServiceAdvancedProperty GET PropertyName,PropertyNumValue,PropertyStrValue,ServiceName,SqlServiceType /VALUE

we receive the following error:

Test-Path : Access is denied

At:
...\agent\scripts\PowerShell\SecureTempFolder.psm1:64 char:9

if (Test-Path -Path $folder -PathType Container)

CategoryInfo          : NotSpecified: (:) [Test-Path], UnauthorizedAccessException
FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.TestPathCommand

Current Validation

The following has been confirmed:

• Windows Server Discovery is successful.
• sqlservr.exe is detected on the target server.
• The root\Microsoft\SqlServer WMI namespace is accessible.
• ComputerManagement15 is successfully identified.
• Failure occurs when the pattern attempts further command execution during Collect MSSQL Components Info using Utility.
• The error consistently references SecureTempFolder.psm1 and Test-Path : Access is denied.
• Because this MSSQL collection step fails, the complete MSSQL Database Discovery flow is not proceeding successfully.
  
  Any idea about this?

• Does this error indicate that the Discovery credential requires additional access to a remote temporary folder or Windows administrative share on the target server?
• What minimum permissions are required for the Discovery credential to allow the MSSQL pattern commands to execute successfully without granting full administrator access