Can ServiceNow Collect Advanced Windows Details Without WMI/WinRM Credentials?

DhanarajG · 3 weeks ago

I have a question regarding Windows Discovery and alternative methods for collecting detailed Windows server information.

We are currently performing ServiceNow Discovery in a customer environment and have successfully validated SNMP connectivity to Windows servers. Using SNMP, we are able to retrieve basic information such as:

Hostname
System description
Network interfaces
Uptime
IP addresses
Other standard SNMP OIDs

However, when it comes to collecting detailed Windows information such as:

Operating system details
Installed software
Running services
Hardware inventory
Disk and memory information
IIS details
SQL Server details

ServiceNow Discovery appears to require Windows credentials (WMI/WinRM) with the appropriate permissions on the target servers.

The customer currently uses PRTG and has indicated that they are able to retrieve much of this information through SNMP in their monitoring solution.

My Questions

Is there a supported agent-based approach within ServiceNow that can collect detailed Windows server information without relying on WMI/WinRM discovery credentials?
Can Agent Client Collector (ACC) be used as an alternative for Discovery and CMDB population in this scenario?
Has anyone successfully implemented Windows Discovery using:
- SNMP only
- ACC
- Another ServiceNow-supported agent
while avoiding local administrator or elevated Windows credentials?
If ACC is the recommended approach, are there any licensing, prerequisites, or limitations compared to traditional Discovery using WMI/WinRM?

Environment

ServiceNow Discovery
MID Server deployed and functioning correctly
SNMP connectivity validated
Customer prefers a least-privilege approach and would like to minimize administrative access requirements on Windows servers

I'd appreciate hearing about any real-world implementations, recommendations, or best practices from others who have addressed similar security concerns.

Thanks in advance for your help!

ayushraj7012933 · 3 weeks ago

Hi @DhanarajG ,

SNMP can be used for basic Windows discovery, but it cannot be considered a complete replacement for WMI/WinRM when the requirement is detailed Windows server discovery.

The important point here is that PRTG showing Windows information through SNMP does not necessarily mean ServiceNow Discovery can collect the same information through SNMP. PRTG may be using additional sensors, agents, scripts, or other data sources.

For your requirement, I would suggest the following approach.

1. If complete Windows Discovery is required

Use the standard Windows Discovery method through the MID Server with the required Windows credentials.

You don't necessarily need to provide Domain Admin credentials. Instead, create a dedicated Discovery service account and grant only the permissions required for ServiceNow Discovery.

The flow would be:

MID Server → WMI/WinRM → Windows Server → Discovery → CMDB

This is the preferred approach if you need information such as:

Windows OS details
CPU/Memory/Disk
Installed software
Windows services
Running processes
IIS
SQL Server
Other application/server information

2. If WMI/WinRM is not allowed

In that case, I would evaluate Agent Client Collector (ACC).

The architecture becomes:

Windows Server → ACC Agent → ServiceNow → CMDB

Since the agent runs on the Windows server, you don't have to depend on the MID Server remotely connecting to the server using WMI/WinRM in the same way as traditional Discovery.

However, I would not assume that ACC provides exactly the same Discovery coverage as traditional Windows Discovery.

I recommend doing a PoC on 2–3 representative Windows servers and checking whether ACC provides all the attributes required by your CMDB, especially:

Installed software
Services
Processes
IIS
SQL Server
Hardware
OS information
Relationships

3. SNMP-only approach

I would use SNMP mainly for the information that Windows exposes through SNMP.

For example:

SNMP → Hostname / IP / Interface / Uptime / System information

But I would not design the solution around SNMP-only if the requirement is complete Windows inventory.

4. Recommended solution for your security requirement

If the customer's concern is specifically "we don't want to provide Local Administrator or Domain Administrator access", I would first work with the Windows/security team to create a least-privileged Discovery account and validate the required permissions.

If the security policy completely prohibits WMI/WinRM access, then proceed with an ACC PoC and compare the resulting CMDB data with the existing Discovery requirements.

So my recommendation would be:

WMI/WinRM + least-privileged account → preferred for full Windows Discovery

ACC → alternative when remote Windows Discovery access is restricted

SNMP → suitable for limited/basic information, not a full replacement for Windows Discovery

This approach also avoids creating custom scripts or trying to force SNMP data into CMDB attributes that ServiceNow Discovery normally obtains through Windows-specific discovery.

View solution in original post

SGienow · 2 weeks ago

Check with your account rep to be 100% sure, is always the right answer... but whether Discovery, SG connector, (outside SCCM,) or ACC-V, I believe the SU is the same.

Look at ITOM Infrastructure Workspace, for ACC-V (and mid server,) features etc

Edit to also add: Yes, ACC is agent based and you need the agent on any device you want to be discovered/updated by it. You would need to put it on every server you wanted to discover/update with it.

The only native SN feature that discovers without an agent or connection to a DB or other platform such as a SG connector, is Discovery as far as I am aware. You would need ACC-V on every device.