I recently resolved a long standing issue that affected legacy web applications running inside a MED-V 2.0 workspace. Often web applications will trigger documents and other objects that will launch within their respective host application either through an instance of that application via COM or through a special control via ActiveX (like PDF documents.)
On more than one occasion involving one or more application the parent windowed application (usually a legacy version of Internet Explorer) will trigger an application to launch containing critical data sent to that application by way of the web application. Usually this followed a Java process that would crunch some data and then generate a document object, populate the data and then launch the form from within Microsoft Word. What was happening in every case of this issue was – the Word Window never displayed when running inside a MED-V workspace.
Make sure the problem is not resolved with the super-secret hotfix.
First of all, if you are experiencing the occasional disappearing window, there was an out of band hotfix for the Windows XP RDPShell that addressed disappearing windows. You can call up Microsoft support and request this hotfix by its name (KB2446473.) However, this only addresses a flaw in the RDPShell and did not likely apply in the cases I mentioned above because these problems were not intermittent. They were very consistent and could be reproduced consistently.
Tracking it down . . .
Running the workspace in full screen mode never exhibited the issue. This issue only occurred when running in the seamless mode of MED-V. Launching a parallel command prompt in the workspace and running tlist.exe revealed that the WINWORD.EXE process was running so the application was not crashing. Killing the MEDVGUEST.EXE process from a command prompt prior to attempting to reproduce the problem caused the issue to go away as well. This led to me down the path of investigating what was really going on. The active Word window was being sent behind the browser window and was not being brought to the foreground for the RAIL mechanism used by MED-V to display the active window. Further debugging revealed LockSetForegroundWindow as a common denominator. Some research into the SetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx) and/or LockSetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633532(VS.85).aspx) yielded a way to control this.
- HKEY_CURRENT_USER\Control Panel\Desktop
- Value: ForegroundLockTimeout
- Data Type: DWORD
If the time required to launch the Word application window is less than the value specified in the ForegroundLockTimeout, the application will be launched behind the Internet Explorer window.
If the time taken to load the Word window is greater than the time set in ForegroundLockTimeout registry key, the window will be launched on top of Internet Explorer. Setting this value inside the workspace to 0 resolved the issue.
While this may likely resolve all instances of this type of problem bear in mind that I also learned that if the base priority of Internet Explorer is higher than the Microsoft Word window, it will still be launched behind the Internet Explorer window to avoid active window focus change.
I recently had an issue where I encountered something quite bizarre. In an effort to reduce size on disk of dynamically expanding virtual hard disks (VHDs) I found myself feeling like I needed to take medication. After sysprepping an operating system image on the disk, the current file consumption on the disk was approximately 12 GB and the size of the dynamically expanding virtual hard disk was 15 GB (with a capability of growing to 127 GB as that was the size designated when creating the VHD.)
I then mounted the disk as a drive in Windows 7 using diskpart.exe in order to perform some offline defragmentation, pre-compaction, and compaction. I found that after disk defragmentation was completed in Windows 7, the total size of the disk grew to the full 127 GB although the total file consumption the disk was still at 12 GB. I had never encountered this before. I have, in the past, seen defragmentation cause some gain in VHD size but only ever at a maximum of 10-20%. To top that off, pre-compaction and compaction did nothing to reduce the size.
Now, just to give some background, the Windows 7 virtual stack used to mount VHDs did not understand the TRIM command (which is what the file system started sending down in Win7 to let the storage stack know an area was no longer in use). Anytime defragmentation is run on a dynamically expanding VHD where the stack doesn’t understand TRIM will in fact result in a larger VHD than you started with. BUT NOT THIS MUCH! I even verified that volume snapshots were disabled on the volume as that can also explain a large increase in the size of the VHD.
Realizing this was done on a host machine using a customer’s corporate operating system image, I took a copy of the original VHD and mounted and defragmented the disk on one of my plain vanilla operating system images and found the behavior I expected – only a nominal increase in size. At this point, I realized something outside the norm of the operating system was causing this growth. I could have easily done the tedious approach of removing individual 3rd-party filters on the image (using the divide-and-conquer method) while running defragmentation but I wanted to see if what was doing this was even related to defragmentation. I decided to simply just mount the drive again and monitor the disk size while doing absolutely nothing interactively to affect the drive.
I went to lunch. I came back, the disk was already at 32 GB. By the end of the afternoon, it was back to 127 GB. There was obviously some file-system based software performing this. It turns out, there is a McAfee Encryption policy in place (they were running 3rd-party disk encryption software) that silently encrypts new logical drives as they are added. When I mounted the VHD through Windows 7’s Disk again while this software had been disengaged, the issue did not occur.
I hadn’t been taking crazy pills after all.
I recently had a customer inquire further as to how the mechanics differ between all of the application modes in MED-V. I would have thought this far into the life cycle of MED-V that I had gone into enough detail on the subject. Turns out, while the article I wrote on TechNet a couple of years back (http://blogs.technet.com/b/medv/archive/2011/06/02/med-v-v2-why-would-an-application-fail-in-seamless-mode-when-it-succeeded-in-full-desktop-mode.aspx) gave a good high-level explanation, more clarification is needed.
So in addition to the information I laid out back in 2011, I’ve done some more diving into RAIL (Remote Applications Installed Locally) the inline VPC implementation of TSRemoteApp (now called RemoteApp) where the RemoteApp Server component was ported to Windows XP for the guest integration.
First of there are actually two “full-screen” modes in MED-V 2. One involves starting full screen mode from either the MED-V toolkit or using the command MEDVHOST /fullscreen to launch the workspace in full screen mode with the MEDV Guest services and agents still engaged. If you were to access the Virtual PC out of band using the VPC Window or by double-clicking on the .VMCX file, you would get the warning message about another user being logged on (see http://blogs.technet.com/b/medv/archive/2011/08/24/med-v-v2-strange-message-lt-virtual-pc-name-gt-was-closed-with-a-user-logged-on.aspx)
I outlined the basics of the differences in this high-level chart:
RDPINIT/RDPShell and Active Setup
In addition to items that depend on Explorer.exe such as Login Scripts, Active Setup also does not run. You may can get around this by leveraging group policies and the RUNONCE.EXE command. You can specify the startup applications as a part of a user’s logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on. To specify the startup applications as a part of a user’s logon settings, follow these steps:
1. In the server Group Policy Management Console (GPMC), select the GPO (that applies to the GUEST OS [XP]) and edit.
2. Click Computer Configuration, and then click Administrative Templates.
3. Click System, double-click Logon and then double-click Run these programs at user logon.
4. In the Run these programs at user logon Properties dialog box, click Enable.
5.Click Show, and then click Add.
6.Type the name of the startup application – runonce.exe /AlternateShellStartup (must include the argument)
7.Click OK two times.
One Final Note on Termination
When a Remote Application is terminated, the process on the XP Guest that is associated with the application is terminated. However, the RDP session remains in a disconnected state until is reset by an administrator. This behavior can be modified by using the group policy “Set time limit for logoff of remote app sessions.”
Any other processes that should be terminated when the Remote Application is terminated can be specified in the following Registry key.
This is a registry key that the RDP RAIL Shell uses to filter out “system” processes (in addition to rdpshell.exe and rdpinit.exe). Processes configured via this key are ignored by the RAIL Shell. In addition, they will be terminated upon exiting of the RDP session.
A process can be added by adding a REG_DWORD value with a name of the process and a value of 0x0. The following is a list of processes that are terminated by default when a Remote Application ends.
Clipsrv.exe Conime.exe Ctfmon.xe Dwm.exe Imepadsv.exe
Lmsvcs.exe Msgsvc.exe Nddeagnt.exe Netdde.exe Netstrs.exe
Os2srv.exe Proquota.xe Rdpclip.exe Screg.exe Taskeng.exe
Running a MED-V application that depends on presence may not properly show presence when hovering over it in the System Tray
Let’s review some basic information about how MED-V: The way MED-V V2 works is the Windows 7 host machine connects to the Guest Virtual PC through an RDP-style connection. This basically turns the Windows XP Virtual PC into a mini-RDP server. This must always be in the back of your mind while you test your applications under a MED-V solution. Leveraging RDP removes the need for a hooking DLL to be injected into the guest OS and cuts down on the overhead of the MED-V Guest Agent.
Since applications that run under MED-V are basically the same to the Windows 7 host as applications running remotely on an RDS or Terminal server, you will encounter specific limitations in cosmetic desktop features. For example, the AeroPeek style thumbnail preview of the remote application will not be visible. Window titles will show an appended (Remote) to differentiate it from the local applications.
In addition to what comes through the remote connections, MED-V will republish (pass along) critical messages that appear in the Windows XP system tray. For example, password expiry notices and update notices from WSUS (or Configuration Manager) will also appear on the local desktop. Applications that publish to the Windows XP System tray in the guest will also appear in the host (with an appended “Remote.”)
One item that is not simply a cosmetic issue that you will need to be aware of when considering MED-V for application remediation are applications that have presence indicators in the system tray. Changes in presence often cause a change in icon or icon color as well as their pop-out status message. While these status icons will appear in the Host system tray, there will be potential issues with changes in user presence updating icons properly. Applications such as Communicator, Windows Messenger, and Lotus SameTime may not always update/change presence notifications properly when running in a MED-V workspace.
Let’s use the example of a user being signed in initially as “available.” When the use steps away and becomes idle, the system tray icon may not initially reset the icon appearing in the host to “Away” even though the user is away from their desk.
Using Virtual PC with Windows 7: Be sure to use Integration Features when the Narrator Accessibility Feature is Enabled
There is an important item to be aware of if you are using Windows Virtual PC (VPC7) and you are also using the Windows Narrator Accessibility feature. The Narrator is an excellent aid for the visually impaired as it reads screen text and echoes verbally various actions. In addition, it will echo verbally what you are typing to ensure accuracy.
If you are running Windows 7using Virtual PC for legacy applications and are incorporating the narration feature, you will need to be aware of an important security item. Normally, when there is a secure field (such as password prompts) instead of echoing the keystroke, the narrator feature will say “hidden” instead. In the case of Windows Virtual PC, this will also be in effect when you type in the password for the guest operating system – IF – and this is a big IF – integration features are enabled. If you are using MED-V to provision these virtual PC’s you will automatically be engaging integration features.
If you are not using MED-V or VPC integration features, you may run into a situation where the Windows 7 narrator will read the contents of the password upon entry into the guest. The Windows Narrator monitors the keyboard to read keystrokes. It also communicates with Windows to check if the field is a secure field or not. In case it is a password field, narrator will not read the keystrokes. Normally, when the password is typed in the password dialog, the response from the narrator will always be “Hidden.” With integration features disabled, this translates to the Windows Narrator in the host as a simple sending of keys to a pane control.
The purpose of Virtual PC for Windows 7 was to provide a seamless integration experience through RemoteApp whether it be through simple Windows XP Mode – or through the MED-V enterprise provisioning solution. If you have users who will still need the Narrator Accessibility feature for their legacy applications, please ensure that integration features are enabled even if they are using VPC in full screen mode.
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.
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.