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.”
Lately, I have many customers who are in the process or quickly planning their migration from Windows XP to Windows 7. Some of them are even looking to become early adopters of Windows 8. In the process of inventorying, rationalizing, and providing application compatibility remediation for their legacy applications, the need for leveraging MED-V for last-resort application compatibility remediation has created questions with regards to Windows XP supportability and how MED-V may or may not affect that. For application issues such as 16-bit remediation for x64, MED-V is the only option for enterprise customers.
Given that the supported MED-V solutions (v1 and v2) and its scaled-back VPC counterpart Windows XP Mode leverage the use of a Windows XP operating system instance, the question is always posed to me – Does the Windows XP EOL policy also apply to MED-V? The question may also be asked slightly differently but more pointedly: Does MED-V extend the Windows XP EOL policy?
The short answer is: No MDOP solution extends or affects the Windows XP Lifecycle end-of-life date for support. That date is firm and will not change. April 8, 2014 – as per the reference here: http://www.microsoft.com/en-us/windows/endofsupport.aspx
MED-V Version 1
MED-V Version 1 is technically still in support however, only MED-V V1 workspaces containing the Windows XP operating system are. Even though MED-V V1 did temporarily allow for the use of Windows 2000 workspaces on Windows 7 when released in 2009, it did not extend the support date for Windows 2000 instances beyond the end of 2010. Since mainstream support for MED-V v1 ends on August 10, 2013 (per http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=desktop+virtualization&Filter=FilterNO) there is no confusion as there is with MED-V V2 since MED-V V1 will already be out of support by the time 2014 arrives. If customers running MED-V V1 have not already started looking for alternative means of application remediation going forward for Windows 7 and/or Windows 8, the time to start thinking about that is now. Note: MED-V (any version) is not supported on Windows 8.
MED-V Version 2 and Virtual PC for Windows 7
MED-V version 2 will be supported until December 4, 2016 (per http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=desktop+virtualization&Filter=FilterNO.)
What this means is the actual MED-V and VPC7 code will be supported beyond the Windows XP EOL date – but the Windows XP code will not be. In essence, the host machine’s software will be fully supported until that date but no security or critical updates will be released for the guest operating system (other than potentially code fixes for elements pertaining to the MED-V guest agent.) Remember, MED-V is designed to only serve as a temporary solution for remediation. The end game should be the modernization or replacement of the application(s) in question. Also take heed the same applies for Windows XP Mode.
So the big question . . .
Finally, the last question I am always asked is: What do you recommend our end game date for leveraging MED-V should be?
My honest answer has never wavered: April 8, 2014 – if not sooner.
It looks like both MED-V v1 and v2 will be around for the remainder of the Windows XP support lifecycle. Because of this, I often I get asked the question, “Which version of MED-V should I be using?” as well as “Why should I be using MED-V instead of Windows XP mode?” The following table lists the differences in the basic feature set between versions 1 and 2 of MED-V. This decision making relies on comparing several factors. You also have to take into consideration that MED-V v2 was a complete re-engineering of the product. There is no direct upgrade path between MED-V v1 and v2.
General Feature Differences between MED V1 and V2
This table focuses on the Primary feature changes and enhancements that drove development of the MED-V/Windows 7/Optimized Desktop Strategy. These include features added into the product as a result of customer feedback for version 1.
|Feature||MED-V V1||MED-V v2|
|Policy Source||XML-based from Server||Local Registry (can be deployed by policy)|
|SSO Support Host-Client?||No||Yes|
|Workspace Support||Persistent and Revertible||Only Persistent|
General Component Differences between V1 and V2
If you are an experienced MED-V v1 users, you will need to be aware of some functional component differences. The following table lists the differences between the installable components available between versions 1 and 2 of MED-V.
|Component||MED-V V1||MED-V v2|
|MED-V Policy Server||Yes||No|
|Image Distribution Server||Yes||No|
|MED-V Client||MED-V Client||MED-V Host Agent|
|MED-V Workspace||MED-V Workspace (Manually Installed)||MED-V Guest Agent (Auto-installed)|
|VM Preparation||VM Preparation Tool||MED-V Workspace Packager|
|MED-V Management Console||MED-V Management Console||MED-V Workspace Packager|
Differences that Affect Enterprise Decisions
There will be many customers who have been surveying MED-V for enterprise deployments. Many may have looking at MED-V version 1 and are trying to determine whether MED-V v1 or MED-V v2 is suitable. The following chart outlines many factors that determine adoption in the enterprise. Use this to help you make that decision.
|Feature||MED-V V1||MED-V V2|
|Client Host OS Support||XP, Vista, and Windows 7||Windows 7|
|VPC Engine||VPC 2007 (VPC 6)||VPC7 (Non VT requires Patch)|
|URL Redirection||Basic (Bidirectional)||Host-to-Guest only|
|Full Desktop Mode||Yes||Only through VPC|
|Policy Source||Server (XML)||Registry/GPO|
|Seamless Integration||Yes – Manual||Yes – Automatic|
|Application Publishing Foundation||Kidaro||RDP/RemoteApp|
|Console||Yes||Yes (Workspace Packer)|
|Integrated Image Distribution||TrimTransfer/BITS/Pre-Staging||Pre-staging Only (ConfigManager Integration with DCM)|
The Feature Comparisons between XP Mode, MED-V V1, and MED-V v2
Finally, how both MED-V v2 and v1 stack up in comparison with XP Mode is outlined in the table below. XP Mode is designed to be a consumer solution while MED-V is for the enterprise.
|Feature||XP Mode||MED-V v1||MED-V v2|
|Seamless Application Compatibility Environment||X||X||X|
|Host/Guest Folder Integration||X||X|
|USB/Smart Card Redirection||X||X|
|Dynamic Application Publishing||X||Manual||X|
|Custom XP Image||X||X|
|SCCM Integration||(Bridged)||(Bridged and NAT)|
|IE6 Web Redirection||Bi-Directional||Host to Guest only|
|Shared VHD Support||X||X|
|WMI Monitoring Interface||X|
|Network Printer Syncing||Steve Thomas||X|
When you install Virtual PC 2007 Service Pack 1 on a computer running Windows Vista or Windows 7 x64 edition, the installation appears in a subdirectory of the “Program Files (x86)” directory. Additionally, the VirtualPC.exe process displays in Task Manager as a 32-bit process.
When Virtual PC 2007 is installed on a 64-bit host Operating System it installs to the 32-bit program files directory. This is because unlike Virtual Server, Virtual PC 2007 is a 32-bit application which uses 64-bit drivers when necessary.
In order to run on a 64-bit host Operating System the drivers must be 64-bit themselves, but the only benefits of making the application 64-bit is the ability to access larger amounts of memory and to run more virtual machines at the same time. While both of these things are very important for Virtual Server, they are not as important for Virtual PC.
This works as designed for hosting 32-bit operating systems as guests on x64 hosts.
Recently, we have had some customers asking us about leveraging App-V to virtualize locales. You may also refer to them as regional settings. Since Windows 2000, the Windows operating system has been multi-locale aware and is able to preserve user-specific locales.
The user locale determines which default settings a user wants to use for formatting dates, times, currency, and large numbers. The user locale is not the language. The only influence the user locale has on the language is on the names of the days and months. For example, if you use the long date format to display “April 22, 2010,” the “April” string will change based on the user locale.
Changing the user locale automatically adds an Input Locale with the default settings for the associated language. I made some serious tests involving easily discernable applications with regional setting differences (locale differences.) While the operating system now support user locales, there are still legacy applications that only recognize system locales. Some of these applications may be hard-coded to correspond to a specific locale.
App-V is language or locale neutral and should have full support for different languages and character scripts, sorting orders, time/date/address formats, various International keyboards and global Input Method Editors (IME), and other locale settings. This approach is called “single World-Wide binary”.
It is important to understand that while we are locale aware, the actual isolation and sandboxing of the locale regional settings takes place at a system level even though the preferences are stored at the user profile level. App-V is not expected to make the application localized or culture-aware if it’s not already supported. It won’t make the application to work on a culture that the application does not originally support in the locally installation.
If it were as simple as simple as making registry modifications within the virtual environment, this may would work. Most locale-aware applications, however will actually call API’s directly in Windows whether they are user locales or system locales. For example, retrieving the user locale by calling GetUserDefaultLCID and the system locale by calling GetSystemDefaultLCID. When the application is calling the API directly, it is not reading the registry entries because it is calling the Win32 API directly and it will be querying the registry – but outside the virtual environment.
We recommend that users look to the AppLocale Utility as a possible remediation. The AppLocale utility allows users to run a legacy application without changing to the code-page/system locale needed by that particular application. AppLocale emulates the code-page required by that legacy application without changing the machine’s system locale. This can provide the “sandbox” you may need for the application’s locale.