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

[DhanarajG]

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

1. Is there a supported agent-based approach within ServiceNow that can collect detailed Windows server information without relying on WMI/WinRM discovery credentials?

2. Can Agent Client Collector (ACC) be used as an alternative for Discovery and CMDB population in this scenario?

3. Has anyone successfully implemented Windows Discovery using:

   • SNMP only
   • ACC
   • Another ServiceNow-supported agent

   while avoiding local administrator or elevated Windows credentials?

4. 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 · Accepted solution]

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.

[DhanarajG]

Thanks for the detailed explanation. I completed a PoC with ACC by installing the agent on my laptop and verified that the CI was successfully created in the CMDB.

I have one follow-up question regarding ACC deployment at scale:

If we choose ACC as an alternative to WMI/WinRM-based Discovery, would the ACC agent need to be installed on every Windows server or endpoint that we want to discover and monitor?

For example, if an organization has hundreds of Windows servers, would ACC need to be deployed individually to all of those servers?

My understanding is that with traditional Discovery using a MID Server and WMI/WinRM credentials, we don't need to install any software on the target devices. However, with ACC, it appears that an agent must be present on each device.

From an operational and licensing perspective, what would be considered the best practice? Are there any scalability, management, or cost considerations we should be aware of when choosing ACC over traditional Discovery?

[Pratiksha]

1. Is there a supported agent-based approach within ServiceNow that can collect detailed Windows server information without relying on WMI/WinRM discovery credentials?

Yes. Agent Client Collector (ACC) can be used as an agent-based approach for collecting information from Windows servers without relying on traditional WMI/WinRM-based Discovery credentials.

If the primary concern is avoiding local Administrator or highly privileged Windows credentials, ACC-V (Agent Client Collector – Visibility) can also be considered for discovery and visibility use cases.

Another option to consider is Just Enough Administration (JEA), where appropriate, to provide the required access with more limited privileges rather than granting full local Administrator rights.

2. Can Agent Client Collector (ACC) be used as an alternative for Discovery and CMDB population in this scenario?

Yes. ACC can be used for this scenario, and ACC-V can help with discovery/visibility of Windows devices and their information.

It provides an agent-based approach where information can be collected from the endpoint without depending on the same WMI/WinRM credential model used by traditional Windows Discovery.

The appropriate approach will depend on the level of CI information and relationships that need to be populated in the CMDB and the specific Discovery requirements.

3. Has anyone successfully implemented Windows Discovery using SNMP only, ACC, or another ServiceNow-supported agent while avoiding local Administrator or elevated Windows credentials?

• SNMP only: Generally, SNMP is not a replacement for Windows Discovery when detailed Windows server information is required. SNMP can provide certain device-level information, but it will not provide the same depth of Windows-specific information as the Windows Discovery approach.
• ACC: Yes, ACC can be used for Windows endpoint/server visibility and discovery without relying on traditional WMI/WinRM credentials.
• ACC-V: ACC-V can help with Windows discovery/visibility and is worth considering when the objective is to minimize the use of privileged Windows credentials.
• JEA: If traditional Windows Discovery is still required, JEA can be explored to reduce the level of privilege granted to the Discovery account instead of using a full local Administrator account.

4. If ACC is the recommended approach, are there any licensing, prerequisites, or limitations compared to traditional Discovery using WMI/WinRM?

From a licensing perspective, the licensing model is based on the number of discovered devices/endpoints, rather than simply whether WMI/WinRM or an agent-based approach is being used.

However, the prerequisites and capabilities should be validated against the exact use case. ACC/ACC-V has its own deployment and connectivity prerequisites, and there can be functional differences compared with traditional Discovery, particularly around the depth of discovery information and the types of relationships that need to be identified.

Therefore, if the requirement is to replicate the complete Discovery dataset and CMDB relationships provided by traditional Windows Discovery, I would recommend validating the specific attributes, CI classes, and relationships required before choosing ACC as a complete replacement.

Recommended approach

If the main requirement is to avoid granting local Administrator/elevated Windows credentials, I would consider the following options:

1. ACC-V – preferred agent-based option to investigate for Windows visibility/discovery.
2. JEA + traditional Discovery – worth considering if the organization wants to continue using the existing Discovery framework while minimizing privileges.
3. SNMP – not recommended as a complete replacement for detailed Windows Discovery.
4. Traditional WMI/WinRM Discovery – still appropriate where the full depth of Windows Discovery and CMDB relationships is required and the required permissions can be provided securely.

Regards,

Pratiksha

[DhanarajG]

Thanks for the detailed explanation. I completed a PoC with ACC by installing the agent on my laptop and verified that the CI was successfully created in the CMDB.

I have one follow-up question regarding ACC deployment at scale:

If we choose ACC as an alternative to WMI/WinRM-based Discovery, would the ACC agent need to be installed on every Windows server or endpoint that we want to discover and monitor?

For example, if an organization has hundreds of Windows servers, would ACC need to be deployed individually to all of those servers?

My understanding is that with traditional Discovery using a MID Server and WMI/WinRM credentials, we don't need to install any software on the target devices. However, with ACC, it appears that an agent must be present on each device.

From an operational and licensing perspective, what would be considered the best practice? Are there any scalability, or cost considerations we should be aware of when choosing ACC over traditional Discovery?