To inventory with WMI, vScope can use a normal user account. What’s important is that vScope is allowed to read WMI, and that the local firewall is not enabled. Here is how to set up a domain user account to enable vScope to perform a discovery.

For this you have to make a few settings on the machines to be scanned. Several of these can be done via Group Policy Objects via Active Directory, but the most important of them all (Rights for WMI namespace below) must be done manually or with a startup-script on each target machine, otherwise the user will not have access to WMI .

Configure WMI Control in Windows 8. Windows Management Instrumentation (WMI) is a key part of the Windows 8 operating system. The following steps have been tested with: Windows Server 2003 R2 Service Pack 2. Windows Server 2008 R2 Datacenter Windows Server 2012 R2 Standard.

Follow the examples below:

In our case we run Active Directory on Windows 2008 R2 and we want to scan the target machine which is Windows 2012 R2 machine. Our domain is called “ISL” and we name our dedicated WMI user-account “wmiuser”.

(The fastest option for WMI discovery in vScope is to use a domain admin-account. The account is protected with strong encryption and is never used for any write operations. Using a domain-admin account minimizes the workload and guarantees the best results with minimal efforts.)

First – Setting done from Active Directory

Open the Active Directory Administrative Center:

• Go to ISL -> Users
• Right click and select New -> User
• Create user as a normal user and ways User UPN logon to wmiuser@ISL.local
• Make sure Member of is set to Domain Users so that the user is in a valid group.

1 – Create the Group Policy Object

Open the Group Policy Management:

• Create a new GPO and name it WMI Access
• Link it to ISL.local domain (drag and drop the it on ISL.local)
• Make sure that the GPO will be applied to all machines in the domain to be scanned (WMI adjust Security Filtering, etc.)

2 – Settings GPO

DCOM

• Right-click WMI Access (which is the GPO we just created), select Edit
• Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
• Select Properties at: DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
• Check the Define this policy setting
• Select Edit Security …
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Under Permissions: Tick Allow on both Local Access and Remote Access
• Click OK
• Click OK
• Select Properties under: DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
• Check Define this policy setting
• Select Edit Security …
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Under Permissions: Tick Allow at Local Launch, Remote Launch, Local Activation and Remote Activation
• Click OK
• Click OK

Firewall

• Right-click WMI Access (the GPO we just created), select Edit
• Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security
• In the right pane, expand Windows Firewall with Advanced Security until Inbound Rules visible. Right-click on it
• Choose New Rule …
• Select Predefined and Windows Management Instrumentation (WMI) in the list
• Click Next
• Tick all the Windows Management Instrumentation-rules in the list (usually 3 pieces)
• Click Next
• Select Allow The Connection
• Click Finish

3 – Rights for WMI namespace

These settings can not be done with a regular GPO. For a user who is not Admin this step is critical and must be done exactly as instructed below. If not properly done, login attempts via WMI results in Access Denied.

• Write wmimgmt.msc in command prompt
• Right-click WMI Control, and select Properties
• Select the Security tab
• Select Root of the tree and click on Security
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Select Allow for Execute Methods, Enable Account, Remote Enable and Read Security under Permissions for wmiuser
• Mark wmiuser and click Advanced
• Under the Permission tab: Select wmiuser
• Click Edit
• Under Applies To-list: Choose This namespace and all subnamespaces. It is very important that the rights are applied recursively down the entire tree!
• Click OK
• Click OK
• Click OK
• Click OK

Second – Settings done on each machine

4 – Verify

On the machines which are to be scanned by vScope, make sure that the GPO is applied. To force an update:

• In a command prompt: type gpupdate /force
• Ensure that the GPO is applied: Enter gpresult /r
• Under COMPUTER SETTINGS in the printout, look for WMI Access (the GPO we created) under the Applied Group Policy Objects. If it is listed there, it means that it is applied to the machine.
• Scan machine with vScope and enter ISLwmiuser as username and enter the correct password
• Verify the discovery result

5 – Additional Information

We recommend turning off UAC filtering on the target machines. It can be done by setting a registry key manually or through a GPO.

UAC can in some cases filter information through WMI so that the information is not as complete as it could be. Usually you do not need to do this step, but if information is missing, do the following on the target machine:

• Open regedit
• Add or edit the DWORD* key:
• Close regedit

0 = Remote UAC access token filtering is enabled.
1 = Remote UAC is disabled.

So you’re trying to do a simple PowerShell WMI query from a domain-joined computer to a non-domain-joined (workgroup) Server 2008 R2 computer on the same network, e.g. to check the version of the server’s operating system:

But you keep getting nasty messages:

I feel your pain. I was beginning to wonder if getting remote WMI working had something to do with planetary alignment.

Finally I stumbled on John Howard’s article about managing Hyper-V remotely. I had used his HVRemote app for just that purpose in an earlier installation. This time I went directly into the meat of the article and found the initial steps for Hyper-V remote management are all about getting WMI to work remotely. I followed steps 1 through 4 in that article and I was able to run the WMI query successfully.

The article has detailed instructions and pictures. Here is a summary:

Step 1: Make sure you are using a username and password which matches between the client and the server. Directx 11 renderer for windows 7. Yes, that means the domain user name matches the non-domain user name. John says that the user does not need to be an administrator on the target machine, but in my case it is an administrator.

Alternatively, you can use the –GetCredential parameter of the Get-WmiObject command. Then you don’t need matching user names; you just supply explicit credentials for the target computer.

Step 2: In Windows Firewall, enable the pre-defined Windows Management Instrumentation (WMI) rules.

Step 3: Grant DCOM (Distributed COM) permissions. I set this up for Authenticated Users. Component Services > My Computer > Properties > COM Security tab > Launch and Activation Permissions > Edit Limits > Add user > Grant Remote Launch and Remote Activation permissions. (It seems this step is not required if User Account Control is disabled on the target machine.)

Step 4: Grant Remote WMI permissions. Here I deviated slightly from John’s instructions: I only needed remote access to CIMV2, and Authenticated Users was already there so I was just adding a permission. Computer Management > Services and Applications > WMI Control > Properties > Security tab > expand Root and select CIMV2 > Security button > Advanced > highlight Authenticated Users (already there on my server) > Edit > check Remote Enable > OK. Restart the Windows Management Instrumentation service to make sure the changes take effect.

TextMaker Viewer 2010 is a free download for Windows systems only (Windows 7, Vista, Windows XP, and Windows 2000). To use this free document viewer tool, just download TextMaker Viewer 2010 from Officeviewers website: TMViewerSetup.exe. Once finish download, install it and click the “register now” button to get your free serial number. To use this free document viewer tool, users just need to download TextMaker Viewer 2010 from Officeviewers website: TMViewerSetup.exe. Once finish download, install it and click the “register now” button. Note: Users need to register to grab the free permanently serial number for full version TextMaker Viewer 2010. Planmaker viewer 2010 serial numbers.

Update November 5, 2013 The steps here are a little different in Server 2012 R2. You cannot edit the existing Authenticated Users permission. Instead, once you are viewing Advanced Security Settings for CIMV2, click on the Add button, click Select a principal, type Authenticated Users and click OK, then check Remote Enable and click OK.

After this, in the Advanced Security Settings dialog, you’ll see one entry for Authenticated Users inherited from the Parent Object, and a second entry that you just created that is not inherited.

Note: I expected that I would need to enable Network DTC access (described on Technet). However WMI seems work with that turned off:

So Why Does This Work on Domain-Joined Computers without All the Fuss?

As best I can tell, this is because Local Administrators already have these remote DTC and WMI privileges. If you use domain admin credentials, the domain admin is member of the Local Administrators group on the target computer, so the domain admin “inherits” those permissions.