使用Get-Counter远程获取Windows Server 2012性能计数器报错
Get-Counter Remote Connection Issues to Windows Server 2012 It sounds like you’ve already nailed down the key clues: your direct Get-Counter call fails with Unable to connect to the specified computer or the computer is offline, but the server is online, permissions check out, and running the same logic via Invoke-Command works perfectly. That slow connection delay you see with Computer Management on 2016 is almost certainly part of the same puzzle—both issues stem from differences in how remote management protocols handle initial connections and authentication handshakes.
Here’s a breakdown of likely causes and actionable fixes to try:
1. Verify Critical Remote Services on the Target Server
Get-Counter relies on a handful of background services that Invoke-Command (which uses WinRM/PSRemoting) doesn’t depend on in the same way. Make sure these are running on your Server 2012 machine:
- Remote Registry: Required to fetch performance counter definitions from the target’s registry
- Windows Management Instrumentation (WMI): The backbone for many remote monitoring tools
- Performance Logs & Alerts: Some counter types need this service to initialize properly
You can check these remotely using the working Invoke-Command method:
Invoke-Command -ComputerName "YourServer2012" -ScriptBlock { Get-Service -Name RemoteRegistry, Winmgmt, SysmonLog }
2. Extend Timeout Values
The default timeout for Get-Counter might be too short to handle the slow initial connection you’re experiencing (just like the Computer Management delay). Try increasing it explicitly:
Get-Counter -ComputerName "YourServer2012" -Counter "\Processor(_Total)\% Processor Time" -TimeoutSeconds 60
You can also adjust the WinRM client timeout to give more time for the connection handshake:
Set-Item WSMan:\localhost\Client\Timeout -Value PT60S
3. Lean Into PSRemoting (Your Working Method, Optimized)
Since Invoke-Command already works reliably, wrap your Get-Counter logic in a script block to bypass the direct connection issue. This leverages the already-authenticated WinRM pipeline:
$counterResults = Invoke-Command -ComputerName "YourServer2012" -ScriptBlock { # Fetch multiple counters at once if needed Get-Counter -Counter @( "\Processor(_Total)\% Processor Time", "\Memory\Available MBytes" ) } # Access results locally just like a regular Get-Counter output $counterResults.CounterSamples
4. Rule Out Network/Authentication Delays
- Use IP instead of hostname: DNS resolution delays can trigger timeouts. Test with the server’s IP address to eliminate this variable:
Get-Counter -ComputerName "192.168.X.X" -Counter "\Processor(_Total)\% Processor Time" - Reset Kerberos cache: Stale Kerberos tickets can cause authentication bottlenecks. Run this on your local machine and retry:
klist purge - Validate firewall rules: Ensure the target server has inbound rules enabled for:
- Windows Management Instrumentation (WMI)
- Remote Registry
- WinRM (already enabled if
Invoke-Commandworks)
5. Reset Corrupted Performance Counter Registry Entries
If performance counter registry keys are corrupted, even working services can cause connection failures. On the target Server 2012 machine, run this command to reset counters:
lodctr /R
Then restart the Winmgmt and RemoteRegistry services to apply the fix.
内容的提问来源于stack exchange,提问作者cgoll

