Verify WMI Access for a Regular Non-Admin Domain User

This guide walks through enabling and testing WMI access for a regular domain user without admin rights, ideal for securely setting up vScope’s inventory access on Windows machines.

Prerequisites

Ensure you’ve configured DCOM access, WMI namespace permissions, and firewall exceptions by following Setting up WMI-access through AD & GPO.

Machines Defined

• Client: The machine where vScope or the testing script is run
• Target: The machine being inventoried

Testing WMI Access for System Information

1. Open PowerShell on the Client machine.
2. Run the following command, replacing Target and isl\wmiuser with the appropriate values:

Get-WmiObject -Class Win32_ComputerSystem -ComputerName Target -Credential isl\wmiuser

If successful, details about the Target system should appear, such as:

Domain : isl.local Manufacturer : VMware, Inc. Model : VMware Virtual Platform Name : Target PrimaryOwnerName : Windows User TotalPhysicalMemory : 8589463552

Troubleshooting Errors

• Access Denied (E_ACCESSDENIED): Indicates insufficient DCOM rights. Review Setting up WMI-access through AD & GPO: Settings from Active Directory.
• ManagementException (GetWMIManagementException): Points to insufficient rights on the WMI namespace. See Setting up WMI-access through AD & GPO: Rights for WMI Namespace.

Testing Access to System Patch Information

To verify permissions for retrieving system patch information (Quick Fix Engineering updates), run:

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName Target -Credential isl\wmiuser

You should see a list of installed updates, for example:

| Source | Description      | HotFixID    | InstalledBy         | InstalledOn   |
|--------|------------------|-------------|---------------------|---------------|
| Target | Update           | KB3192137   | NT AUTHORITY\SYSTEM | 2016-09-12    |
| Target | Update           | KB3199986   | NT AUTHORITY\SYSTEM | 2017-01-19    |
| Target | Security Update  | KB3213986   | NT AUTHORITY\SYSTEM | 2017-01-19    |

If this list is empty, it may indicate insufficient permissions. To confirm, try the command with a domain administrator credential:

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName Target -Credential isl\administrator

Troubleshoot Missing Patch Information

1. RDP into the Target system with admin rights.
2. Open Event Viewer > Windows Logs > System and look for Event ID 10016 during the WMI query attempt.

If found, the error message likely reads:

The application-specific permission settings do not grant Local Activation permission for the COM Server application...

This indicates that the user lacks permissions to activate a COM Server application (e.g., TrustedInstaller).

Resolving Permissions for TrustedInstaller

1. Open regedit as an administrator.
2. Locate the CLSID associated with the error under HKEY_CLASSES_ROOT\CLSID\{CLSID-ID}.
3. Identify the AppID in this registry key, which should match TrustedInstaller.
4. Navigate to HKEY_CLASSES_ROOT\AppID\{AppID-ID}.

If the Security tab in DCOM Config for TrustedInstaller is grayed out, adjust permissions:

Grant Permissions to TrustedInstaller in DCOM

1. Open dcomcnfg.
2. Locate TrustedInstaller under Component Services > Computers > My Computer > DCOM Config.
3. In Security settings, add wmiuser with all permissions enabled.

Verifying Access

After updating permissions, restart the Windows Modules Installer service. Run the following on the Client system:

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName Target -Credential isl\wmiuser

If successful, you should see the list of installed QFE as when using an administrator credential.

Note

Ensure UAC is not filtering the results if information is still missing.

You may also try the Automated setup via GPO.