Windows 10 WMI Access Denied After Upgrade: Fixing Remote Event Viewer and WMI Permissions

During our domain-wide Windows management rollout, we encountered a peculiar scenario: A Windows 8.1 Pro machine that previously allowed full remote WMI access and Event Viewer connectivity suddenly became inaccessible after upgrading to Windows 10 Pro (version 1909 in our case). Here's our troubleshooting journey:

✔ WinRM service running (confirmed via Get-Service winrm)
✔ Firewall completely disabled
✔ GPOs successfully applying (verified with gpresult /h report.html)
✖ WMI queries failing with "Access denied" (0x80070005)
✖ Event Viewer snap-in showing "Network path not found"

The root cause emerged when we examined the WMI namespace security. Windows 10 implements additional security layers that aren't mirrored from Windows 8.1 upgrades. Here's the PowerShell script we used to verify:


# Check WMI security for root namespace
Get-WmiObject -Namespace "root" -Class __SystemSecurity | 
ForEach-Object {
    $_.GetSecurityDescriptor().Descriptor
}

This revealed that the BUILTIN\Administrators group lacked ENABLE and REMOTE ACCESS permissions.

We implemented this multi-pronged solution:

1. Repairing WMI Namespace Permissions

Create a PowerShell script (Repair-WmiPermissions.ps1):


# Grant remote access to Administrators group
$namespace = "root"
$security = Get-WmiObject -Namespace $namespace -Class __SystemSecurity
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$binarySD = $security.GetSecurityDescriptor().Descriptor
$newSD = $converter.BinarySDToWin32SD($binarySD)
$newSD.DACL += (New-Object System.Management.ManagementClass Win32_ACE).Create(
    $ADMINISTRATOR_SID,
    $REMOTE_ACCESS_FLAG,
    $CONTAINER_INHERIT_FLAG,
    $NO_PROPAGATION_FLAG
)
$binarySD = $converter.Win32SDToBinarySD($newSD)
$security.SetSecurityDescriptor($binarySD)

2. DCOM Configuration Updates

We modified machine-wide DCOM settings using dcomcnfg:

Open Component Services → Computers → My Computer
Right-click → Properties → COM Security tab
Under "Access Permissions", add DOMAIN\Admins group with "Local Access" and "Remote Access"
Under "Launch and Activation Permissions", repeat the same addition

3. Registry Tweaks

Added these registry values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System:


"LocalAccountTokenFilterPolicy"=dword:00000001
"FilterAdministratorToken"=dword:00000000

After implementing these changes (plus a reboot), we confirmed functionality with:


# Test remote WMI access
Get-WmiObject -ComputerName PROBLEM-PC -Class Win32_OperatingSystem -ErrorAction Stop

# Test remote Event Log access
Get-WinEvent -LogName System -ComputerName PROBLEM-PC -MaxEvents 1

The Windows 10 upgrade process doesn't always properly migrate WMI security settings. Key takeaways:

Always verify namespace-level permissions after OS upgrades
Windows 10 implements stricter DCOM defaults than Windows 8.1
The LocalAccountTokenFilterPolicy registry setting is often overlooked

After upgrading our test machine from Windows 8.1 Pro to Windows 10 Pro, we encountered a peculiar scenario where remote WMI queries and Event Viewer access were being denied despite proper GPO configurations. The machine appeared to accept other remote management operations through Computer Management, making this an especially puzzling case of selective permission failure.

Before diving into solutions, let's confirm these critical indicators:

Successful Computer Management connections (services, disk management working)
WinRM service running (confirmed via Get-Service WinRM)
Firewall completely disabled for testing purposes
WMI service responding locally (wmic /node:localhost process list brief works)

The root cause often lies in DCOM and WMI namespace security descriptors. Here's a PowerShell script to audit and repair these settings:


# Check current WMI namespace permissions
Get-WmiObject -Namespace "root\cimv2" -Class __SystemSecurity | 
ForEach-Object { $_.GetSecurityDescriptor().Descriptor }

# Repair script for WMI permissions (run as admin)
$computer = $env:COMPUTERNAME
$namespace = "root\cimv2"
$user = "DOMAIN\AdminGroup" # Replace with your admin group

$wmiSecurity = Get-WmiObject -Namespace $namespace -Class __SystemSecurity
$converter = New-Object System.Management.ManagementClass Win32_SecurityDescriptorHelper
$sd = $wmiSecurity.GetSecurityDescriptor().Descriptor
$sd.DACL += $converter.TrusteeToSID($user)
$wmiSecurity.SetSecurityDescriptor($sd)

Windows 10 introduced stricter DCOM defaults. Verify these registry settings:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"DefaultLaunchPermission"=hex:01,00,04,80,90,00,00,00,a0,00,00,00,00,00,00,00,\
  14,00,00,00,02,00,74,00,05,00,00,00,00,00,14,00,0b,00,00,00,01,01,00,00,\
  00,00,00,01,00,00,00,00,00,00,14,00,09,00,00,00,01,01,00,00,00,00,00,05,\
  12,00,00,00,00,00,18,00,0b,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,\
  20,02,00,00,00,00,18,00,0b,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,\
  23,02,00,00

For Event Viewer access issues, check these components:

Windows Management Instrumentation service dependencies
Event Log service status (wevtsvc)
Security descriptor for remote event log access:


# Grant remote event log access
wevtutil sl Security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

When all else fails, use these diagnostic commands:


# WMI connectivity test
Test-WSMan -ComputerName TARGETPC -Authentication Default

# Network trace (requires admin)
netsh trace start scenario=NetConnection capture=yes tracefile=C:\temp\wmidebug.etl
# Reproduce the failure
netsh trace stop

# WMI provider logging
reg add HKLM\SOFTWARE\Microsoft\WBEM\CIMOM /v "Logging" /t REG_DWORD /d 2 /f

Windows 10 upgrades sometimes leave behind permission artifacts:

Run dcomcnfg and verify Component Services > Computers > My Computer properties
Check winmgmt /verifyrepository for WMI database consistency
Rebuild WMI repository as last resort: winmgmt /resetrepository