Are you still Using MED-V? If so, do NOT install this update

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.

http://social.technet.microsoft.com/Forums/windows/en-US/ffe5c710-9fb1-4540-9d85-9d76e3a79846/kb2830477-causes-problems-in-wn7-x64-and-xp-mode?forum=w7itprovirt

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”

http://support.microsoft.com/kb/2830477/en-us

MED-V: More Detail on Full-Screen vs. Seamless Mode

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.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs

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

Wfshell.exe         Win.com

 

 

MED-V: To Cache Credentials or to not Cache Credentials (Ramifications of Disabling “DisablePasswordSaving” vs. Enabling it)

How’s that for a double negative? Disabling the disabling of password saving. In essence, allowing users to cache/save passwords for SSO (single-sign-on) when authenticating to MED-V workspaces. In MED-V, if the credentials do not match, or you do not check the box to have your credentials
remembered, you are presented with the standard RDP prompt for access to the virtual machine.

This is not to be confused with the initial MED-V prompt for authentication (first appearing during first-time-setup) which looks like this: 

Both RDP and MED-V can allow for the caching of credentials, however, while MED-V only temporarily caches credentials in memory, RDP will cache using the Credential Manager. The MED-V authentication mirrors that of RDP in that the Windows 7 host is connecting via RDP to the Windows XP virtual
machine. Depending on how you have configured MED-V settings for authentication, the end user is typically prompted at some point to enter their password, either the first time MED-V is started or the first time that they try to open a published application. If LogonStartEnabled has been configured,
it will happen when MED-V starts in the user session. Otherwise, it will occur when you first launch a published MED-V application. Caching credentials seems like it would make sense as it does improve the user experience, but there are trade-offs.

Unintended Inconvenience

• If the user accidentally mistypes their credentials in the logon dialog and specifies to cache them, the incorrect credentials are saved and the user will be prompted to re-enter their credentials each time the VM is started or resumed. This state will persist until the user credentials are manually cleared.
• If the user selects to cache their password and later the password expires or credentials domain name has been renamed, the user will be prompted to re-enter their credentials each time the VM is started or resumed until the cached password is cleared.

MED-V has a special credential manager that helps to avoid the above inconvenience. It allows you to control aspects of credential caching including:

• Whether the credentials the end user enters are stored in Credential Manager.
• In what manner the end user is presented with the option of entering and saving their password. For example, if MED-V is configured to start when the end user logs on to the host but Authentication is disabled, the end user is only prompted one time during logon. In this case, credentials are valid until the end user logs off from the host. If it is necessary, you can use Credential Manager to remove any stored end-user credentials. By default, credential storing is disabled, but you can change this setting either before or after workspace deployment.

Pre MED-V Workspace Deployment

While you are creating the MED-V workspace package, you can modify the PowerShell (though the New-MedvConfiguration cmdlet) by setting the UxCredentialCachingEnabled to either 1 or 0. This simply tells MED-V whether or not the “Remember My Credentials” will be in place for MED-V FTS and RDP
authentication prompts.

After MED-V Workspace Deployment

The MED-V Credential component cannot override the Group policy Remote Desktop Connection Client “Do not allow passwords to be saved” value. This is represented in the registry by the DisablePasswordSaving value. One way you can set this post-deployment is by  modifying this policy. This policy controls whether the password saving check box appears on the RDP client dialog window and whether the MED-V credential prompt is displayed.

My favorite way of disengaging credential caching altogether is by changing the UxCredentialCacheEnabled in WMI to FALSE.

The WMIC command easily can do this:

WMIC /namespace:\rootMicrosoftMedv PATH setting set uxCredentialCacheEnabled=FALSE

After that, the option to save the password will no longer be available:

 

 

If you also want to manually leverage the RDP policy to DisablePasswordSaving, you can do so by going to the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftVirtual MachinePoliciesDisablePasswordSaving 

Play it Safe

While users prefer caching the credentials to avoid retyping in the credentials, there are risks associated with doing so.  When credential caching is enabled, the end user’s password is stored in a reversible format through CredMan (the Windows Credential Manager.) This opens up the user to potential issues should a
malicious program somehow get on to that system and is able to run as SYSTEM.  The credentials could then be retrieved. The only way to reduce this exposed surface area is by setting DisablePasswordSaving to Enabled and modifying the UxCredentialCacheEnabled property.

 

 

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.

MED-V: How to Customize and Repackage a Workspace using PowerShell

 One of the benefits of MED-V 2 was the introduction of PowerShell to control, manage, and deploy the MED-V workspace. A good example of where PowerShell comes in handy is when you have a workspace that you have already configured and packaged – but now you need to make an adjustment to the configuration for future deployments of that workspace. A walkthrough of how to do this is as follows:

1. Navigate to the directory where the workspace package was created.
2. After making a backup of this directory, notice that you have both a .REG file and a .PS1 file. The .REG file contains the basic configuration. You can use the PS1 file to set advanced settings an regenerate the MED-V workspace.
3. Open the .PS1 file in the integrated script editor. You will notice it looks like the script below:

   import-module -Name “Microsoft.Medv”
   $regFileInfo = New-MedvConfiguration -VmNetworkingMode “BRIDGED” -UxLogonStartEnabled “False” -UxCredentialCacheEnabled “True” -FtsMode “Attended” -VmMultiUserEnabled “False” -FtsAddUserToAdminGroupEnabled “True” -FtsStartDialogMsg “A virtual environment is being created for application compatibility. The first time setup process can take several minutes to complete.” -FtsFailureDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsRetryDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsSetUserDataEnabled “True” -FtsSetJoinDomainEnabled “True” | Export-MedvConfiguration -Path “C:medv2-packagesWindows XP Compatibility.reg” -PassThru
   if ($regFileInfo) #If the .Reg file was created, then create the workspace package
   {
    New-MedvWorkspace -WorkspaceName “Windows XP Compatibility” -VhdFilePath “C:vpcMedv-ws-xp.vhd” -SettingsFilePath “C:medv2-packagesWindows XP Compatibility.reg” -VhdRegPath “C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_InternetZoneHighSecurity.reg,C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_RestrictedBrowsingMode_Apply.reg” | Export-MedvWorkspace -Path “C:medv2-packagesWindows XP Compatibility.msi” -Overwrite
   }

    

Let’s say you wanted to adjust the FtsAddUserToAdminGroupEnabled option and set it to “false.” You could simply make the adjustment in the .PS1 file and repackage the workspace.

You could even add in additional advanced options (Boolean.) For example, if you wanted to disable host guest network printer sharing, you could add an additional parameter to the script to add the –UxPrinterSharingEnabled parameter and set it to “False.” Once you have made the changes, save the new .PS1 file and close the Powershell ISE. By the way, you can use the WMI reference for additional options:

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

Repackaging a Workspace Using PowerShell.

If you are doing this customization, you will need to re-package the workspace using the PS1 file.

1. Open a PowerShell command prompt as Administrator.
2. Change to the current directory of the of the workspace package.
3. Execute the PS1 file. This will start the process of creating the workspace package with these customized settings. Once the packaging process is complete you can deploy the newly created setup, MSI and workspace package.

Some issues with the MED-V V2 Toolkit and how to Remediate them

I wanted to address some issues that have been seen with the MED-V Toolkit. These are minor/cosmetic issues and can easily be remediated.

MED-V Toolkit Freezing

There is a known issue where the MED-V Administration toolkit freezes when attempting to change the logging level while MED-V first time setup is in progress. This is caused by the MED-V workspace needing to be completely setup before changing the logging levels using the Administration toolkit.  If this happens before FTS completes, allow the MED-V first time setup to complete before changing the MED-V logging levels using the toolkit. If more verbose logging is needed during first time setup for troubleshooting use the registry to set the Event Log Level

• Registry Key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftMedvv2Diagnostics
• Data Type: DWORD
• Value: EventLogLevel

Levels include the following: 0 (None), 1 (Error), 2 (Warning), 3 (Information), 4 (Debug). Default setting is 3.

Wrong icon appears for the MED-V Toolkit

There are cases where the MED-V Administration toolkit will display the wrong icon in the taskbar. Instead of the correct icon, it is the icon of another MED-V application. This happens when MED-V is configured to use Normal Start and an application is used to start MED-V. Whatever application is used to start MED-V is the application ICON that will be shown for the MED-V toolkit or other MED-V related UI.  This is a known product code issue. If this happens, here are some remediation steps to try to alleviate the issue.

1. Change the startup type of MED-V to the default fast start
2. Change the user settings for the taskbar properties to Never combine. Do the following:
3. Right-click the taskbar and then click Properties.
4. In the Taskbar and Start Menu Properties dialog box, click the Taskbar tab.
5. In the drop-down bar for the Taskbar buttons box, select Never combine.
6. Click OK.

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.

MED-V V2: Using the CTRL-ALT-Pause Key Combination to Access Hidden Dialog boxes in MED-V

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

• Bubble notifications

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.

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.