If you believe in the openness, freedom, and affordability of the Internet, this blog is very important. – http://blog.netflix.com/2014/03/internet-tolls-and-case-for-strong-net.html
If you are currently still running MED-V 2.0, be very aware of a known issue. If you install the RDP/RDC 8.1 update for Windows 7 SP1, you may notice after installing the update, you are seeing application crashes of the MED-V Workspace. This update is labeled KB2830477. It was originally released last year and there were sporadic reports of problems with MED-V hosts running it. It has recently been re-released (February 11, 2014) and I have noticed many more reports of this occurring. This issue has been reported for both XP Mode and MED-V in the Technet forums as well.
Right now, there is an investigation ongoing. I would advise in the meantime that you do not install this update on MED-V hosts. If you have already installed this update on MED-V hosts and are experiencing the problem, you can simply uninstall the update and the issues should disappear.
Please note that this is an optional update. This update is not needed for MED-V or Windows 7 functionality. It is not a security update either. It may provide enhanced features if you need to connect your Windows 7 host to Windows Server 2012 or Windows Server 2012 R2-based RDP Sessions or RemoteApps.
Here is the subsequent KB article on the update:
KB2830477: “Update for RemoteApp and Desktop Connections feature is available for Windows”
Microsoft has already announced that one of the World Finalist teams in its 2014 Imagine Cup student competition will get to meet co-founder Bill Gates. Now there’s word that the company will give the winners in three of its categories some extra prizes in the form of software boot camps and experiences.
Throughout my tenure while working in support, I would occasionally come across issues where the issue I was troubleshooting with a particular product was the actual installation. Too often the error would be some generic error (with an error code of 1603 or something similar) or one of those “unexpected errors.”
One way to get to more detailed information was to enable advanced debug logging of the Windows Installer service. You can enable advanced logging for a particular package by using the following synatx when attempting to run the installation:
Msiexec /i <path to your .msi package> /L*V C:\Setup.log
where the “L*V” is what enables the Windows Installer to create a verbose log file.
But what if you want to turn on debug logging for not just the packages being installed, but also for the Windows Installer service itself? This was used to isolate the strict name checking issue with App-V 5 MSI wrappers. You will need to do what we call the “Voice Warmup” trick. It gets its name from the fact that enabling all options spells out “voicewarmup.” To do so, do the following
1. From an elevated command prompt, stop the Windows Installer Service if started:
net stop msiserver
2. Open up the Registry Editor.
3. Navigate to the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
4. Create a new string value (REG_SZ) called “logging.” (No Quotes)
5. In the data field, type “voicewarmup!” (No Quotes)
6. In the same key, you will also need to create a new DWORD value called “debug.”
7. In the data field, type “7.”
8. Exit the Registry Editor.
9. Restart the Windows Installer Service.
net start msiserver
After you install (or attempt to install) the application, the log files will be located in %TEMP%.
I would advise not keeping these values in place on a production server.
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 – http://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 0×80041010 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.
0×80070005 – 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.
0×80041003 – 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.
0×80041001 – 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 (0×80041010) 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.