Troubleshooting WMI/PerfMon Remote Connectivity Issues on Windows Server 2008 R2 SP1 for SQL Server Memory Monitoring


2 views

When attempting to establish a Performance Monitor connection to a Windows Server 2008 R2 SP1 system for SQL Server memory analysis, many administrators encounter the frustrating "The parameter is incorrect" error. This occurs despite having proper credentials, running services, and WMI connectivity confirmed through PowerShell commands like:

Get-WmiObject -ComputerName remoteServer -Class Win32_OperatingSystem | Select-Object Caption

The specific behavior manifests in several ways:

  • Initial connection appears successful when browsing counters
  • Counter selection shows correct remote server information (disk letters, etc.)
  • Upon finalizing counter selection, the monitoring reverts to local machine data
  • Error message appears when changing computers in the MMC interface

The root cause often relates to WMI namespace permissions. Here's the definitive fix:

# PowerShell script to fix WMI namespace permissions
$namespace = "root\cimv2"
$computer = "remoteServer"
$user = "DOMAIN\AdminUser"

# Get current security descriptor
$sd = Get-WmiObject -Namespace $namespace -ComputerName $computer -Class __SystemSecurity | 
      ForEach-Object { $_.GetSecurityDescriptor().Descriptor }

# Add new access rule
$trustee = ([wmiclass]"Win32_Trustee").CreateInstance()
$trustee.Domain = $user.Split('\')[0]
$trustee.Name = $user.Split('\')[1]

$ace = ([wmiclass]"Win32_Ace").CreateInstance()
$ace.AccessMask = 0x1f3ff  # Full control
$ace.AceType = 0  # Allow
$ace.AceFlags = 0  # Object and container inherit
$ace.Trustee = $trustee

$sd.DACL += $ace

# Apply changes
$wmi = Get-WmiObject -Namespace $namespace -ComputerName $computer -Class __SystemSecurity
$wmi.SetSecurityDescriptor($sd) | Out-Null

If the registry modification doesn't resolve the issue, consider these approaches:

Option 1: Direct WMI Performance Counter Query

$counters = @(
    "\Memory\Available MBytes",
    "\SQLServer:Buffer Manager\Page life expectancy",
    "\Process(sqlservr)\Working Set"
)

$samples = 60
$interval = 5

1..$samples | ForEach-Object {
    Get-Counter -Counter $counters -ComputerName remoteServer
    Start-Sleep -Seconds $interval
} | Export-Counter -Path "C:\perf\SQLMemoryAnalysis.blg" -FileFormat BLG

Option 2: Logman Utility

logman create counter SQLMemTrace -o "C:\perf\SQLTrace" -f bin -v mmddhhmm -c "\Memory\*" "\SQLServer:Buffer Manager\*" "\Process(sqlservr)\*" -si 5 -s remoteServer
logman start SQLMemTrace

After applying any solution, verify connectivity with:

Test-WSMan -ComputerName remoteServer
Get-CimInstance -ComputerName remoteServer -ClassName Win32_PerfFormattedData_PerfOS_Memory

For ongoing monitoring, consider configuring Performance Counter Alerts through SCOM or creating a dedicated monitoring VM with direct network access to the target server.


When attempting to monitor SQL Server memory allocation patterns on a Windows Server 2008 R2 SP1 system through Performance Monitor, I encountered a frustrating roadblock. Despite having successfully executed similar remote monitoring tasks across various Windows Server versions, this particular scenario presented unexpected challenges.

The core symptoms manifest when:

  1. Launching Performance Monitor (either via MMC or perfmon.exe)
  2. Attempting to connect to the remote server
  3. Receiving "The parameter is incorrect" error message
  4. Counters displaying local machine information despite remote server selection

Before diving into solutions, let's confirm the environment was properly configured:

# PowerShell verification of WMI connectivity
Test-WSMan -ComputerName RemoteServerName
Get-Service -ComputerName RemoteServerName -Name RemoteRegistry

Key verification points:

  • Remote Registry service running on target server
  • No firewall restrictions blocking connectivity
  • Domain admin credentials used for MMC
  • WMI connectivity confirmed via PowerShell

Through extensive troubleshooting, several potential culprits emerged:

WMI Namespace Permissions

Windows Server 2008 R2 SP1 introduced specific WMI namespace security requirements. To verify and adjust permissions:

# Check WMI namespace permissions
$namespace = "root\cimv2"
$computer = "RemoteServerName"
$user = "DOMAIN\AdminUser"

$wmisecurity = Get-WmiObject -Namespace $namespace -ComputerName $computer 
              -Class __SystemSecurity -Impersonation 3

$converter = [System.Management.ManagementClass]"Win32_SecurityDescriptorHelper"
$binarySD = $wmisecurity.PSBase.InvokeMethod("GetSD",$null)
$converter.BinarySDToWin32SD($binarySD)

Performance Counter Corruption

Corrupted performance counters can cause this behavior. The reconstruction command:

# Rebuild performance counters (run on target server)
lodctr /R
winmgmt /RESYNCPERF

After testing various approaches, this combination proved effective:

  1. WMI namespace repair:
    # On the target server
    winmgmt /verifyrepository
    winmgmt /salvagerepository
  2. Performance counter reset:
    # Requires admin privileges on both machines
    unlodctr /M:PerfProc
    unlodctr /M:PerfDisk
    lodctr /R
  3. Security policy adjustment:

    Configure the following GPO settings:

    • Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → "Network access: Restrict clients allowed to make remote calls to SAM"
    • Add the monitoring workstation to the allowed list

When traditional Performance Monitor fails, consider these PowerShell alternatives:

# Sample remote memory monitoring script
$computer = "RemoteServerName"
$cred = Get-Credential

Invoke-Command -ComputerName $computer -Credential $cred -ScriptBlock {
    Get-Counter -Counter "\Memory\Available MBytes" -SampleInterval 5 -MaxSamples 12 |
    Export-Counter -Path "C:\PerfLogs\MemoryUsage.blg" -FileFormat BLG -Force
}

To avoid future issues:

  • Regularly rebuild performance counters on monitored servers
  • Maintain consistent WMI namespace permissions across the environment
  • Document and standardize remote monitoring configurations
  • Consider implementing SCOM for enterprise-scale monitoring