WMI discovery inconsistent results between discoveries

[guykl]

I working on a windows discovery schedule. 
i have done the following:

- credentials (have tested them)

- open all needed firewalls

- gave the mid the needed capabilities 

but when I run a discovery, some of the devices, I get WMI not connected, and some are stuck on identifying, but if I run a specific discovery it works. 

So I run another discovery with around 20 devices to check if it’s the amount. Around half of the devices created a CI, than I ran another one and now 100% of the devices works, but then I rerun everything, I still get WMI no connect on some of them.

A bit later I rerun the 20 and it went back to around half working

is there a reason for such inconsistency? I have opened all the firewalls, and working on 20 ips is not enough to warrant, performance issue or anti spam issues 

[shubhamseth]

@guykl 

The inconsistent behaviour suggests this is likely not a credential issue, since the same devices work successfully in subsequent runs.

Common causes include:

• Intermittent WMI/RPC connectivity issues (Ports 135 + dynamic RPC range)
• Windows Firewall or endpoint security intermittently blocking connections
• MID Server resource constraints (thread/concurrency limits)
• DNS or reverse DNS resolution issues
• WMI service instability on target servers
• Network latency or packet drops between MID and targets

Since individual discoveries succeed but larger schedules show random failures, I would focus on:

1. Reviewing the Shazzam and WMI logs for failed devices.
2. Verifying RPC dynamic ports are open, not just port 135.
3. Checking MID Server CPU, memory, and thread utilization during discovery.
4. Reviewing antivirus/EDR tools that may throttle WMI requests.
5. Testing WMI manually from the MID Server using the same account against failing targets.

The fact that a rerun discovers previously failed servers is a strong indicator of an intermittent connectivity or WMI/RPC issue rather than a Discovery configuration problem.

Hope this helps.

[pr8172510]

Hi @guykl,

The intermittent behavior is the key clue here. Since the same devices sometimes succeed and sometimes fail, the issue is likely environmental rather than a Discovery configuration problem.

One common cause documented by ServiceNow is incomplete WMI/RPC connectivity. For Windows Discovery, ensure the following ports are open between the MID Server and the target:

TCP 135 (RPC Endpoint Mapper)
TCP Dynamic RPC Ports (49152–65535 by default)

If only port 135 is open, Discovery may successfully initiate communication but fail when Windows assigns a dynamic RPC port for subsequent WMI queries.

 checking:

• Discovery Status logs
• ECC Queue records
• MID Server logs (agent0.log)
• Windows Event Logs on the target
• Endpoint security/AV software that may throttle WMI
• MID Server resource utilization

A useful validation is to test WMI directly from the MID Server host using PowerShell or WBEMTEST. If WMI connectivity is inconsistent outside ServiceNow, the issue is likely network, RPC, or endpoint-related.