When many organizations move to Windows 7, they also take on the task of discovering, inventorying, testing, and remediating all of their current applications currently used in production. Often part of that process includes a decision to deliver those applications with App-V. The App-V 4.6 SP1 Sequencer and client offers a streamlined workflow to virtualize, package, and deliver those applications to the desktop or RDS server providing a simplified, centralized approach to application delivery and management. It also, at the same time, resolves many application interference issues through isolation and state separation.
When a product such as App-V undergoes a significant maintenance release, there are always the possible regressions. With 4.6 SP1, there were a few, and the App-V team was able to quickly isolate many of them and provide fixes in a timely manner. Servicing is always an important process in the support of production software.
App-V service releases (a.k.a hotfixes) are released in a manner that allows for the simplification of the deployment of fixes. Hotfixes are based on major release points (i.e 4.6, 4.6 SP1) and are designed to be cumulative. This way, if you deploy the recent hotfix pack, you can rest assured you are getting all of the cumulative patches released since the last major revision. In the case of App-V 4.6 SP1, the most recent release is 4.6 Hotfix Package 6 (build 220.127.116.11121.) if you are not currently running your 4.6 clients at this build you can leverage the hotfix download link found with the associated KB article here:
The hotfix packages are made available in MSP format. This allows for flexibility in enterprise deployment of the patch. Remember, since the patches often affect revision changes of the App-V filter drivers, a reboot is necessary when deploying the patch.
But What about the Sequencer?
As many client changes involve patching the App-V System Guard (the component that facilitates the virtualization engine) it requires making revision to the App-V 4.6 SP Sequencer as well. I always advise all of my customers to ensure that they are always using the most recently released build of the App-V Sequencer.
The relase process for the sequencer is slightly different. Not every cumulative patch, involves a change to the sequencer. With this, you will not always see inclusion of the sequencer with every cumulative hotfix release. In the case of the most recent release of App-V as of this writing, the most recent service release of the App-V 4.6 SP1 sequencer is the refresh build that came with 4. SP1 Hotfix 3. You can download the release via the KB article for the hotfix here:
Hotfix Package 3 for Microsoft Application Virtualization 4.6 SP1: August 2011
Instead of an MSP file, when a sequencer is patched, an entirely new installation is made available. This makes sense because sequencer machines are often never “upgraded.” They are often cleanly reverted. This allows sequencing engineers to refresh their machines images used for sequencing in a clean manner without having to worry about patching.
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.
Just about a year ago, I moved all new posts over to Technet.com. In spite of that, this blog still continues to get much attention due to a lot of the existing content proving to be very useful for users. For that I am extremely happy to help and it recently gave me an idea. I have been mulling over how I should focus my current blog over at Technet with regards to information, guidance, and support tips. While I have a lot of great information coming (a lot of new products/product versions in the pipeline) I also have a wealth of information I’ve been needing to post tat was related to existing products and legacy products (Softgrid/App-V 4.x/MED-V V1, etc.) I also realize there is a strong user community and install base still present who may not be moving off until the products get closer to end of life.
– Steve Thomas
With this said, I decided that I would use this blog on WordPress in the future for legacy product information (App-V 4.x/Softgrid/MED-V V1/VMM 2008/VPC) while keeping my blog over at Technet more related to current and forward technologies (App-V 5.0/UE-V/Hyper-V 2012/Win8/Win2012.)
If you are experiencing issues with MED-V published applications or startup programs such as:
- Hidden dialogs (intentional or unintentional)
- Pop-up or child windows not displaying correctly
You may notice that some of those issues are resolved with many known fixes in Windows 7. Additional Recommended Updates for MED-V 2.0 that Address Application Issues http://blogs.technet.com/b/medv/archive/2011/07/20/additional-recommended-updates-for-med-v-2-0-that-address-application-issues.aspx
Even with the fixes in place, you may notice there are still some application dialogs that are opened in an application running in the guest but are hidden from the user and will prevent the user from interacting with the application. When this happens, use the following workaround to troubleshoot/facilitate use:
- Open a MED-V application on the desktop or select an active application
Use the following key combination CTRL+ALT+Pause
To return back to the MED-V Experience use the same key combination.
This allows you to get to the MED-V workspace desktop and see all open dialogs and applications.
In MED-V V2 all events logs are stored on the MED-V Host (Windows 7) and the MED-V Guest (Windows XP) using the “MEDV” event log. By default the event logs are set to Error and Warning events. Additional Debug level logging can be enabled via the registry in both the guest and the host by navigating to
the following key on both the host and the guest:
Set the “EventLogLevel” value to “4”
(You will need to create this value as a DWORD value.)
This can be enabled on both the host and the guest operating systems. Once enabled, all Debug events are listed in the MED-V event log with an Event ID of “0.”
The event logs on the Host can be used to troubleshoot problems with the MED-V Host engine such as URL redirection. The event logs on the guest can be used to troubleshoot the MED-V services running in the Windows XP operating system. It is recommended to enable this on both operating systems
when troubleshooting elements such as host network printer redirection and URL redirection.