Troubleshooting System.Management.ManagementException: Invalid class

The System.Management.ManagementException: Invalid class error can be caused by network-related issues, firewall restrictions, or insufficient permissions.

🔌 Required Ports for Remote WMI Queries

To successfully query WMI over the network, ensure the following ports are open:

For RPC-based WMI (Default Method)

🔧 How to Open These Ports

1️⃣ Open Firewall Ports on the Remote Server

Run the following PowerShell command on the remote machine to allow WMI traffic:

# Allow RPC and WMI in Windows Defender Firewall
New-NetFirewallRule -Name "Allow WMI" -DisplayName "Allow WMI" -Enabled True -Direction Inbound `
-Protocol TCP -LocalPort 135 -Action Allow

New-NetFirewallRule -Name "Allow WMI RPC" -DisplayName "Allow WMI RPC Dynamic Ports" -Enabled True `
-Profile Any -Direction Inbound -Action Allow -Protocol TCP `
-LocalPort 49152-65535

2️⃣ Ensure Remote DCOM Access is Enabled

Run dcomcnfg.exe on the remote server:

• Expand Component Services → Computers → My Computer → DCOM Config
• Right-click My Computer, select Properties → COM Security
• Ensure "Remote Activation" is allowed for ANONYMOUS LOGON or the specific user account in use for the Nodinite Windows Server Monitoring Agent.

3️⃣ Ensure WMI Service is Running

Run the following on the remote machine:

Get-Service Winmgmt

If it's stopped, restart it:

Restart-Service Winmgmt

✅ Next Steps

1. Verify Network Connectivity: Can you ping the remote server?

2. Test WMI Remotely:

    Get-WmiObject Win32_OperatingSystem -ComputerName RemoteServer -Credential (Get-Credential)
   

3. Check Firewall Logs: If WMI still fails, check if packets are being blocked.

Here’s a PowerShell script to fully configure firewall, DCOM, and WMI settings on the remote server to ensure WMI queries work properly.

🚀 PowerShell Script to Allow Remote WMI Access

This script (The example further down on this page assume you Save it as 'Enable-RemoteWMI.ps1'):

✅ Opens required firewall ports (TCP 135, 49152-65535 for RPC).
✅ Enables WMI & DCOM remote access.
✅ Restarts the necessary services (Winmgmt).

# Run this script on the remote machine with Administrator privileges

Write-Host "🔧 Configuring Windows Firewall for WMI Access..." -ForegroundColor Cyan

# Open Firewall Ports for WMI over RPC
New-NetFirewallRule -Name "Allow_WMI_RPC" -DisplayName "Allow WMI RPC" -Enabled True `
-Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 135

New-NetFirewallRule -Name "Allow_WMI_Dynamic" -DisplayName "Allow WMI Dynamic RPC Ports" -Enabled True `
-Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 49152-65535

Write-Host "✅ Firewall rules added for WMI."

# Enable DCOM and allow remote activation
Write-Host "🔧 Configuring DCOM permissions..." -ForegroundColor Cyan

$comSecurity = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole"
Set-ItemProperty -Path "Registry::$comSecurity" -Name "EnableDCOM" -Value "Y"
Set-ItemProperty -Path "Registry::$comSecurity" -Name "LegacyAuthenticationLevel" -Value 2
Set-ItemProperty -Path "Registry::$comSecurity" -Name "LegacyImpersonationLevel" -Value 3

Write-Host "✅ DCOM settings updated."

# Grant remote WMI access
Write-Host "🔧 Configuring WMI namespace permissions..." -ForegroundColor Cyan

$namespace = "root\cimv2"
$account = "Authenticated Users"  # Change this to a specific group/user if needed

# Get existing WMI security settings
$wmi = Get-WmiObject -Namespace "root" -Class "__SystemSecurity"
$acl = $wmi.GetSecurityDescriptor()

# Define a new ACE (Access Control Entry) for remote access
$ace = ([WMIClass]"\\.\root\cimv2:__ACE").CreateInstance()
$ace.Trustee.Domain = ""
$ace.Trustee.Name = $account
$ace.Trustee.SidString = (New-Object System.Security.Principal.NTAccount($account)).Translate([System.Security.Principal.SecurityIdentifier]).Value
$ace.AccessMask = 0x20  # Enable Remote Access
$ace.AceType = 0x0       # Allow Access

# Apply new permissions
$acl.DACL += $ace
$wmi.SetSecurityDescriptor($acl)

Write-Host "✅ WMI permissions updated."

# Restart WMI Service
Write-Host "🔄 Restarting WMI Service..." -ForegroundColor Cyan
Restart-Service Winmgmt -Force
Write-Host "✅ WMI Service restarted."

Write-Host "🚀 WMI Remote Access is now fully configured!" -ForegroundColor Green

📌 How to Use the Script

1. Run on the remote server where WMI needs to be accessed.
   • Open PowerShell as Administrator and execute:

     Set-ExecutionPolicy Unrestricted -Force  # (if necessary)
     .\Enable-RemoteWMI.ps1
     

2. Verify connectivity from another machine:

   Get-WmiObject Win32_OperatingSystem -ComputerName RemoteServer -Credential (Get-Credential)
   

   Replace RemoteServer with the actual hostname.

🔍 Troubleshooting

✅ Still blocked?

• Check Windows Defender Firewall Logs (Event Viewer > Security Logs).
• Temporarily disable the firewall to test:

  netsh advfirewall set allprofiles state off
  

✅ Permission issues?

• Ensure the user running WMI queries is an Administrator or in the "Performance Log Users" group.

Now you should be able to query WMI remotely without getting the "Invalid class" error!

Do I require "CredSSP" ?

• Normally; No, CredSSP is usually not required for standard remote WMI calls. However, you might need it in specific scenarios where double-hop authentication is involved, such as:

• Running a WMI query from Machine A to Machine B, where Machine B then accesses Machine C.

• Using delegated credentials to access network resources from the remote machine.

• Using custom PowerShell scripts with code that performs the double hop.

Note

The Nodinite Windows Server Monitoring Agent supports running PowerShell scripts for Monitoring, and also for end-users to execute commands from a script collection. The script code you write may require "CredSSP" to be properly setup.

✅ When WMI Works Without CredSSP

If you are just executing a direct remote WMI query, standard Kerberos or NTLM authentication is enough.
Example:

Get-WmiObject Win32_OperatingSystem -ComputerName RemoteServer -Credential (Get-Credential)

• Authentication: Uses Kerberos (if in a domain) or NTLM (if standalone).
• No CredSSP needed for this scenario.

❓When do You Need CredSSP?

Use CredSSP if you see authentication errors like:
❌ "Access denied" even when using correct credentials.
❌ "The RPC server is unavailable" when network/firewall settings are fine.

In PowerShell Remoting (Invoke-Command or Enter-PSSession), CredSSP is needed for scenarios like:

Invoke-Command -ComputerName RemoteServer -ScriptBlock {
    Get-WmiObject Win32_Service
} -Credential (Get-Credential) -Authentication CredSSP

✅ Use CredSSP only when required, since it can expose credentials on the network.

❓ How to Enable CredSSP (If Needed)?

1️⃣ On the Client Machine (Running the WMI Query)

Enable-WSManCredSSP -Role Client -DelegateComputer RemoteServer

2️⃣ On the Remote Server (Receiving the WMI Query)

Enable-WSManCredSSP -Role Server

3️⃣ Run PowerShell with CredSSP Authentication

Invoke-Command -ComputerName RemoteServer -ScriptBlock {
    Get-WmiObject Win32_OperatingSystem
} -Credential (Get-Credential) -Authentication CredSSP

❓ When to Avoid CredSSP?

⚠️ CredSSP can be a security risk because it forwards your credentials to the remote machine.

• Use it only if absolutely necessary (e.g., when accessing third-party systems or network shares remotely).
• Safer alternatives: Kerberos delegation, configuring WMI permissions properly, or using WinRM instead.

⁉️ Final Answer: Do You Need CredSSP?

• For standard WMI remote queries? ❌ No, not required.
• For multi-hop authentication (Machine A → Machine B → Machine C)? ✅ Yes, use CredSSP.
• For PowerShell Remoting (Invoke-Command) with WMI? ⚠️ Only if necessary.