CIM works locally but not remotely
Documentation: Microsoft Learn
Work the problem
Local CIM succeeds
Fictional case: Win32_OperatingSystem returns locally on SRV01. From the management host, its name resolves but the configured WSMan port times out.
Reasoning notebook
Record the evidence that supports your answer and the check you would run next. Your notes stay in this browser — nothing is uploaded.
Why it happens
Adding -ComputerName switches the transport to WS-Management on port 5985, so a query that needed no network at all now depends on the same infrastructure as remoting. Older scripts using Get-WmiObject went over DCOM instead, which is why migrating to the CIM cmdlets can break connectivity that previously looked fine. Namespace permissions are also evaluated separately from local administrator membership.
Check this first
What to look for
The failure occurs before the remote query can reach the provider. Check connectivity and listener configuration before namespace permissions.
Working through it
- Run Test-WSMan against the target to confirm the management stack answers at all.
- Repeat the query with -EA Stop so the real exception surfaces rather than being swallowed.
- Try a DCOM attempt with New-CimSessionOption -Protocol Dcom to identify which transport is actually blocked.
- Check WMI namespace security on the target through wmimgmt.msc for the account being used.
- Create a reusable session with New-CimSession when several classes are needed, which also separates connection problems from query problems.
Avoiding it next time
Verify the repair: Retest the intended transport, then query the same class remotely with the intended account and namespace.