MED-V: The Case of the Unresponsive Word Window

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

Reference: http://technet.microsoft.com/en-us/library/cc957208.aspx

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.

The Case of the Ever-Expanding, Dynamically-Expanding VHD

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 3^rd-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 3^rd-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.

MED-V V1: How to Update the Policy Update\Polling Interval

Within MED-V V1, you can modify the default policy interval by modifying one of the XML files on the client. While the official documentation alludes to this:

“A typical MED-V Management Server can support 5000 users based on the recommended hardware configuration. The client-server communication is lightweight: clients are normally configured to poll the server for policy every 15 minutes, and image updates every 4 hours (Can be changed using MED-V configuration)”

What is does not state is how exactly you change the policy update interval from the default interval of 15 minutes.

To modify the Policy Update Interval, this would have to be done on the client side. You can do this by editing the Configuration.XML located in %ALLUSERSPROFILE%\MED-V\Local\Config

The value is UpdaterTimeInterval and it is found under the element as displayed in the example below:

<Configuration>
<SpecialFileProcessor>
<WorkspaceKeys type="System.String">Kidaro.KeysStorage.KeysConfigurationFileProcessor</WorkspaceKeys>
<ClientPolicy type="System.String">Kidaro.Policy.Server.PolicyFileProcessor</ClientPolicy>
</SpecialFileProcessor>
<!-- Should the service update the configuration from the server. -->
<EnableServer type="System.Boolean">true</EnableServer>
<!-- Time interval in seconds between updates of configuration files. -->
<UpdaterTimeInterval type="System.Int32">900</UpdaterTimeInterval>
</Configuration>

Increase the default UpdaterTimeInterval value of 900 (15 minutes in seconds) to desired interval then save the file and restart the MED-V Client service.

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.

 

 

How MED-V Affects Windows XP End-of-Life Support Policy (It Doesn’t.)

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.

Bringing Legacy Blog Back to Cover Legacy Products

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.)

MED-V V2: How to Enable Advanced Logging

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:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMedvv2Diagnostics

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.

Help! My Virtual PC Appears to be Possessed!!!! (a.k.a – the Case of the Auto-Hibernating Virtual PC)

I recently encountered a customer issue where, periodically, for what appears to be no reason at all, while a user is working in a Virtual PC (virtual machine in Windows Virtual PC for Windows 7) – it will hibernate on its own. In some cases, the user was in the process of doing work.

At first I did not think that would be possible but it was quickly confirmed. A quick investigation confirmed that MED-V 2.0 was installed – yet the user was working outside of MED-v using the Virtual PC in VPC only – or full desktop mode.

We also noticed the following event was being logged in the MED-V event log at the same time this was occuring.

Event ID: 11004

Task Category: Guest Patching

Message: “VM is being stopped during the configured update window.”

It turns out the Virtual PC was interrupted by the Guest Patching Service of MED-V 2.0. What we did to resolve this was adjust the registry value GuestUpdateDuration in the registry key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftMedvv2VM) to 0. This prevented the problem from re-occuring.

MED-V assumes it will be waking a VM up when not in use by MED-V. When the same VM used by MED-V is currently opened exclusively by VPC in full desktop mode, MED-V tiggers VPC to close the VPC using its default action (hibernate.) The value GuestUpdateDuration defines the number of minutes that MED-V should keep the MED-V workspace awake for updating, starting at the time contained in GuestUpdateTime. Enter 0 to disable.

Remember that MED-V v2.0 was only designed for provisioning applications to run in seamless mode.

MED-V: Support for Multiple Drives within MED-V

Support for multiple drives and volumes within a virtual PC (workspace) used by MED-V will depend on the version of MED-V being used. MED-V v2 only supports the use of one fixed disk volume within a single virtual hard disk (VHD.)

It is technically possible to use more than one partition/volume within a single virtual hard disk but it is not recommended if it can be avoided.

MED-V v1 supported the use of multiple virtual hard disks (VHDs.) In addition, MED-V also supported multiple volumes (drives) as well as the use of the SUBST command to mount drive letters to local directories.

MED-V: Performance Issues when using Internet Explorer 8 and later in a v1 workspace

Due to performance limitations of Virtual PC 2007 and the additional resources required for Internet Explorer version 8 and later to function properly, it is not recommended to use any version greater than Internet Explorer 7 in the MED-V 1.0 Workspace.

Only Windows Internet Explorer 6 SP2 and Windows Internet Explorer 7 are officially supported for the MED-V 1.0 SP1 workspace installation. This is referenced on the following link:

http://technet.microsoft.com/en-us/library/ff603753.aspx

For Version 2 of MED-V, Windows Internet Explorer 6, Windows Internet Explorer 7, Windows Internet Explorer 8, and Windows Internet Explorer 9 are supported for the MED-V 2.0 workspace installation.