Since the dawn of the 21st century (and even before) you have been hearing many items related to acronyms interchangeably describing manageability features within Microsoft products (as well as others.) For example, WMI has been at the heart of most Microsoft Manageability products and solutions given the fact it is one of the primary interfaces within the Windows operating systems. While Microsoft’s WMI ties mostly to its products, it is based upon a series of open, universal standards. And this is the heart of deciphering how acronyms and standards can be interchangeably used to describe the same entity.
So let’s weave through the sometimes confusing relationship between these manageability acronyms – WBEM, WMI, CIM, DMI, DTMF, WSMAN, WinRM, and SNMP of protocols/interfaces/standards. In this little game, I will try to go through these acronyms within the average blog post attention span. WMI is Microsoft’s implementation of the open Web-Based Enterprise Management (WBEM), which comes from the Distributed Management Task Force (an industry organization.) WBEM relies on protocols – which can come from legacy standards such as RPC (Remote-Procedure Call) or DCOM (Distributed Component Object Model) or more modernized http-based SOAP standards such as WinRM (Windows Remote Management) based on the WS-MAN (Web-Services Management) standard. SOAP (Simple Object Access Protocol) itself, is is a command extension protocol designed to be used with HTTP (Hyper-Text Transport protocol – or the web) or SMTP (Simple Mail Transport Protocol – or internet email.)
The WMI interface – based upon the WBEM standard – is built upon an infrastructure centered upon the Common Information Model (CIM) and its respective Object Manager (CIMOM), is what links management applications and providers. The infrastructure also serves as the object-class store and, in many cases, as the storage manager for persistent object properties. WMI implements the store, or repository, as an on-disk database named the CIMOM Object Repository. As part of its infrastructure, WMI supports several APIs through which management applications access object data and providers supply data and class definitions.
Beyond WMI, WBEM’s architecture extends to a variety of underlying technologies besides WMI and Win32 because not everything is or will always be on Microsoft technologies – including the Desktop Management Interface (DMI), and the Simple Network Management Protocol (SNMP) Some of these standards define data storage schemas as well as interfaces. Some define commands within communication protocols. Some or more modernized. SNMP has been deprecated in the most recent versions of Windows in favor of technologies such as WinRM.
I like to use the relationship of WinRM and WMI (alongside their open counterpart standards WS-MAN and WBEM) by stating that one is a management protocol and one is a management interface.
To Read more, check out the standards themselves:
When I worked in support, I troubleshot WMI quite bit using many tools. One tool I still keep my eye on with regards to ongoing development was – and still is – the WMI Explorer utility. I am happy to report a new version of an excellent troubleshooting tool for WMI is now available:
WMI Explorer 2.0 is now available for download:
Microsoft .NET Framework 4.0 Full or .NET Framework 4.5.1
Minimum display resolution: 1024×768
Administrator rights to view some WMI objects
(Optional) Internet access for automatic update check
This is a very intuitive tool for visually troubleshooting WMI issues. It gives you a direct view into the WMI namespace.
New Features include:
New: Asynchronous mode for enumeration of classes and instances in the background.
New: Method execution.
New: SMS (System Center Configuration Manager) Mode.
New: Property tab showing properties of selected class.
New: Input & Output parameter information in Methods tab with Help information.
New: List View output mode for Query Results.
New: Update Notifications when a new version of WMI Explorer is available.
New: Connect to multiple computers at the same time.
New: Quick Filter for Classes and Instances.
New: User Preferences.
New: View WMI Provider Process Information.
Improved: UI display on higher scaling levels and resolution.
Improved: Connect As option to provide alternate credentials.
Improved: Display of embedded object names in Property Grid.
NOTE: This is not an official Microsoft tool, and is available “AS IS” with NO support.
Asset Intelligence has been used for years to enhance the inventory capabilities of Microsoft System Center Configuration Manager (SCCM) by extending hardware inventory and adding license management functionality. The Asset Intelligence features of SCCM (2012, 2012 SP1, and 2012 R2) can report application data such as digital PID, MSI product codes, and publisher names for each virtual application registered on a client computer. With App-V 4.6 virtual applications, this was hindered by some limitations including lack of full integration into the SFT package as well as FB1 definitions to be defined for every applications.
App-V 5 improves upon the limitations of SCCM collecting Asset Intelligence data by incorporating Asset Intelligence information into the package.
Captured During Sequencing
Using a special process, the Sequencer will capture Asset Intelligence metadata during the monitor phase. The data is then placed inside the AppXManifest file embedded into the APPV package. This is the only supported time the information can be placed inside the package. In most cases, App-V 5 packages will have asset intelligence unless the application itself specifically does not install that metadata or is an older legacy application without an installer.
The package manifest stores this information under the <AssetIntelligence> element. Additional properties are then specified under the sub-element <AssetIntelligenceProperties>:
Please note that Asset Intelligence data is optional and not required for valid AppV operation for an application. This information is provided for the purposes of inventory with SCCM.
Appearance on Client
The Asset Intelligence marker is attached to the package record in the registry and WMI to inform the AppVHandler in SCCM 2012 SP1 and R2 whether or not the package has asset intelligence.
You can see this when you type Get-AppvClientPackage in PowerShell under the HasAssetIntelligence value.
Why would a package not have Asset Intelligence?
There are a few reasons why an App-V 5 virtual application would not have this information in the manifest:
Timed out during sequencing: If the AI sequencing collector fails to collect the information within a specific period, it will time out. You can disable this value by adding a DWORD value called DisableTimeout to HKLMSoftwareMicrosoftAppVSequencerAssetIntelligence (Will need to create key by default.) Set this value to 1.
No attempt to collect: If the element is missing from the manifest, it means that no Asset Intelligence was gathered during sequencing. You will always see this if the package was converted but it also could be tied to an error collecting it on the sequencing workstation. This means that SCCM will have to manual scan this package as if it were a legacy package by injecting itself into the virtual environment.
Attempt was made but failed: If the element exists but is empty, it means that collection was attempted and nothing was gathered.
To continue the subject of WMI troubleshooting: I am always frustrated at the quick, shotgun method of rebuilding the WMI repository as a rote, rudimentary troubleshooting step. This is very dangerous and risky. Rebuilding the WMI repository manually has resulted in some 3rd party products not working until reinstallation – IN SOME CASES – even this does not work. This is especially a shame since it may not always be necessary and even if it were – if there is severe WMI corruption, it may almost be better to “in-place” upgrade the OS or do a complete reinstallation of the operating system and software as incomplete repositories can yield lingering problems.
Before you go down that road, ask yourself the following:
1.) Have I properly troubleshot the error to the point that the only possible source could be corruption?
2.) Have I researched and installed all of the latest service packs and hotfixes related to WMI? (Hint: Go to http://support.microsoft.com and search WMI, hotfix, and <OS>)
3.) Have I gone through the rudimentary WMI checklist so I don’t get burned by simple things such as firewall rules? (Hint – https://madvirtualizer.wordpress.com/2014/01/22/the-importance-of-troubleshooting-wmi-part-2/)
4.) Have I ran WMIDiag (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7684)
and received really bizarre errors like 0x80041010 WBEM_E_INVALID_CLASS or does it fail to connect at all?
5.) Do you fail to connect to WMI Control from Computer Management?
If you answered “yes” to 4 out of the 5 above, here are some steps you can do to safely troubleshoot the WMI repository using “soft” actions:
Instructions for Operating Systems Prior to Windows Vista (XP/2003)
1. Open the Services MSC console and stop the Windows Management Instrumentation service.
2. You will be prompted to stop dependent services. Click “Yes” on the prompt.
3. Once the service is stopped, browse to %SystemRoot%\System32\wbem. Rename the Repository folder to Repository.old.
4. Once the folder has been renamed, restart the WMI and dependent services in the following order:
Windows Management Instrumentation
SMS Agent Host (If SCCM/SMS is installed)
Windows Firewall / Internet Connection Sharing (ICS)
Any other services that were detected as dependencies
5. Once services have restarted, verify the Repository folder has been recreated. Now bear in mind, it could take up to one hour for WMI to fully rebuild.
Instructions for Windows Vista and Later (2008/Win7/2008 R2/Win8)
1. Open an elevated command prompt.
2. Verify the WMI repository is not corrupt by running the following command:
If the repository is not corrupted, a “WMI Repository is consistent” message will be returned. If you get something else, go to step 3. If the repository is consistent, you need to troubleshoot more granularly. The repository is not the problem.
3. Run the following commands to repair WMI:
If the repository salvage fails to work, then run the following command to see if it resolves the issue:
After the last command, there should be a “WMI Repository has been reset” message returned that verifies the command was successful.
Even the above commands should be a last resort if you are getting an error related to “Access Denied” or “RPC Server unavailable.”
To continue my discussion regarding the importance of troubleshooting WMI, I want to move the focus to a devising a targeted approach when troubleshooting so you can optimize the time it takes for you to zero in on the issue.
WMI issues generally fall into the following areas:
Configuration Issues: These are issues relating to the configuration of WMI on the local (or mostly remote) machine including:
• DCOM Security\Permissions or Configuration
• Firewall Configuration
• WMI namespace security
Infrastructure Issues: These are issues related to WMI components including:
• WMI service setup
• DCOM registration problems
• Missing WMI classes
• Improper WMI provider registration
• Missing System files
• WMI repository corruption (*GASP*)
• Deleted WMI repository (*HEADDESK*)
WMI Managed Entity Issues: These may be issues related to the extensible WMI components including:
• Security requirements
• Not running (e.g service, application) or de-installed application
• External dependencies
As I mention in my last article, you obviously want to verify your firewall rules (which are built into versions of Windows since Windows XP.)
WMI (ASync) Properties – In
WMI (DCOM) – In
Port: TCP 135
WMI (WMI) In-Out
Then you will want to zero in on the error itself.
0x800706BA – RPC Server Unavailable
When this error appears during connecting to a WMI namespace:
• The machine does not exist.
• The machine cannot respond because the appropriate firewall exceptions have not been made. Check firewall settings.
When this error appears during operation it could be:
• The client machine doesn’t have correct firewall settings for asynchronous call backs.
• Connecting to a machine which doesn’t exist.
0x80070005 – E_ACCESS_DENIED
When this error occurs during connecting to a WMI namespace –
• The username/password does not exist.
• The user does not have the remote launch or remote activation options set.
• Check dcomcnfg.exe under the COM Security Tab.
When this error occurs during operation –
• The specific user does not have the DCOM permissions.
• Minimum authentication level needed for the namespace is more than what is used.
• Check the settings on the Default Properties tab of DCOMCNFG.EXE.
0x80041003 – WMI Access Denied
During connecting to a WMI namespace – The user does not have the appropriate WMI permissions on a namespace. Check WMIMGMT.EXE and permissions for that namespace.
During operation – Specific user doesn’t have WMI access permissions.
0x80041001 – Unknown Error
Ah, the UNKNOWN ERROR. Often this is cause by a 3rd-party provider or non-OS software that extends the Repository has been either removed from the environment and left WMI subscriptions in the repository or is malfunctioning.
Enable WMI Verbose logging on the server and review the WMI logs in %SYSTEMROOT%\system32\wbem\logs. The Wbemess log will show which WMI subscription was sending notifications when the criteria was met.
You will need to follow the steps below to remove the WMI subscriptions once you isolate them:
1. Click Start, run, type Wbemtest then type root\cimv2\applications\ and click “Connect” button
2. Click on ‘Enum Classes’, click the Recursive radio button, click OK.
3. Scroll down until you see _FilterToConsumerBinding class. Double-click on it.
4. Click the “Instances” button on the right hand side.
5. Choose those you isolated and click on the delete button.
When you retrieve a managed resource in a WMI script, the CIMOM (WMI service) looks for the managed resource’s blueprint (class definition) in the default namespace if no namespace is specified. If the CIMOM cannot find the managed-resource class definition in the default namespace, a WBEM_E_INVALID_CLASS (0x80041010) error is generated.
0x8007000E – Not enough Storage is available to complete this process
This usually indicates a problem with a provider, handle leak, memory leak, or other problem tied to WMI functionality.
1. Use the WMI Control to ensure that the service is working on the local system.
2. If the problem involves communicating with a remote system then use the WMI Control to test the ability to connect to the remote system
3. If the service appears to be working, use verbose logging to see the activity (queries) that is being processed by the service and to identify any problems. You can also use WMICHK and WMIDIAG to check the health of the service and the hosted providers.
4. For Access Denied type issues verify that the DCOM and WMI Service settings are at default values, and the Network Service account has been granted impersonation rights.
5. Check the service settings if the WMI service fails to start or if client programs cannot communicate with the service. In some cases you may need to reregister all the modules to recover the service.
6. If queries appear to be returning an incomplete results set, try increasing the buffer thresholds.
7. If problems persist, make a backup copy of the existing WMI database (repository), and then try building a new one.
Often in Virtualization and Management Products like SCVMM, MED-V, Config Manager, UE-V, and App-V the symptom of an issue appears in the respective System Center or MDOP product but the root cause is often caused by an anomaly in an underlying operating system component. Often that component is WMI. For this reason, it is invaluable have a solid understanding of WMI and WMI troubleshooting. WMI is often a component that can cause problems due to one or more of the following WMI issues:
- Corrupted repository
- Incomplete namespace
- Access Denied
- Invalid String in WMI property/data
- Unexpected value
- Memory leak
- Code Defect by WMI Provider
One of the most common errors encountered is error 0x800706BA – RPC Server Unavailable.
This error has context. If it is during connecting to a WMI namespace, it is usually because:
- The machine does not exist.
- The machine cannot respond because the appropriate firewall exceptions have not been made. Check firewall settings.
If it is during operation, it is likely because:
- The client machine doesn’t have correct firewall settings for asynchronous call backs.
- Connecting to a machine which doesn’t exist.
First I would verify the firewall rules. I would make sure the following rules are set:
- WMI (ASync) Properties – In Program: %SYSTEMROOT%\System32\WBEM\unsecapp.exe
- WMI (DCOM) – In Port: TCP 135 Program: %SYSTEMROOT%\System32\svchost.exe
- WMI (WMI) In-Out Program: %SYSTEMROOT%\System32\svchost.exe
I deal with WMI problems all the time. I generally follow this little troubleshooting checklist for RPC errors:
- Use the WMI Control MMC (WMIC.MSC) to ensure that the service is working on the local system.
- If the problem involves communicating with a remote system then use the WMI Control to test the ability to connect to the remote system
- For Access Denied type issues verify that the DCOM and WMI Service settings are at default values, and the Network Service account has been granted impersonation rights.
- Check the service settings if the WMI service fails to start or if client programs cannot communicate with the service. In some cases you may need to reregister all the modules to recover the service.
MED-V: To Cache Credentials or to not Cache Credentials (Ramifications of Disabling “DisablePasswordSaving” vs. Enabling it)
How’s that for a double negative? Disabling the disabling of password saving. In essence, allowing users to cache/save passwords for SSO (single-sign-on) when authenticating to MED-V workspaces. In MED-V, if the credentials do not match, or you do not check the box to have your credentials
remembered, you are presented with the standard RDP prompt for access to the virtual machine.
This is not to be confused with the initial MED-V prompt for authentication (first appearing during first-time-setup) which looks like this:
Both RDP and MED-V can allow for the caching of credentials, however, while MED-V only temporarily caches credentials in memory, RDP will cache using the Credential Manager. The MED-V authentication mirrors that of RDP in that the Windows 7 host is connecting via RDP to the Windows XP virtual
machine. Depending on how you have configured MED-V settings for authentication, the end user is typically prompted at some point to enter their password, either the first time MED-V is started or the first time that they try to open a published application. If LogonStartEnabled has been configured,
it will happen when MED-V starts in the user session. Otherwise, it will occur when you first launch a published MED-V application. Caching credentials seems like it would make sense as it does improve the user experience, but there are trade-offs.
- If the user accidentally mistypes their credentials in the logon dialog and specifies to cache them, the incorrect credentials are saved and the user will be prompted to re-enter their credentials each time the VM is started or resumed. This state will persist until the user credentials are manually cleared.
- If the user selects to cache their password and later the password expires or credentials domain name has been renamed, the user will be prompted to re-enter their credentials each time the VM is started or resumed until the cached password is cleared.
MED-V has a special credential manager that helps to avoid the above inconvenience. It allows you to control aspects of credential caching including:
- Whether the credentials the end user enters are stored in Credential Manager.
- In what manner the end user is presented with the option of entering and saving their password. For example, if MED-V is configured to start when the end user logs on to the host but Authentication is disabled, the end user is only prompted one time during logon. In this case, credentials are valid until the end user logs off from the host. If it is necessary, you can use Credential Manager to remove any stored end-user credentials. By default, credential storing is disabled, but you can change this setting either before or after workspace deployment.
Pre MED-V Workspace Deployment
While you are creating the MED-V workspace package, you can modify the PowerShell (though the New-MedvConfiguration cmdlet) by setting the UxCredentialCachingEnabled to either 1 or 0. This simply tells MED-V whether or not the “Remember My Credentials” will be in place for MED-V FTS and RDP
After MED-V Workspace Deployment
The MED-V Credential component cannot override the Group policy Remote Desktop Connection Client “Do not allow passwords to be saved” value. This is represented in the registry by the DisablePasswordSaving value. One way you can set this post-deployment is by modifying this policy. This policy controls whether the password saving check box appears on the RDP client dialog window and whether the MED-V credential prompt is displayed.
My favorite way of disengaging credential caching altogether is by changing the UxCredentialCacheEnabled in WMI to FALSE.
The WMIC command easily can do this:
WMIC /namespace:\rootMicrosoftMedv PATH setting set uxCredentialCacheEnabled=FALSE
After that, the option to save the password will no longer be available:
If you also want to manually leverage the RDP policy to DisablePasswordSaving, you can do so by going to the following registry key:
Play it Safe
While users prefer caching the credentials to avoid retyping in the credentials, there are risks associated with doing so. When credential caching is enabled, the end user’s password is stored in a reversible format through CredMan (the Windows Credential Manager.) This opens up the user to potential issues should a
malicious program somehow get on to that system and is able to run as SYSTEM. The credentials could then be retrieved. The only way to reduce this exposed surface area is by setting DisablePasswordSaving to Enabled and modifying the UxCredentialCacheEnabled property.