The MED-V Blog

MED-V V2: Additional Guidance for Launching Startup Programs in MED-V V2

2013-04-06T12:53:21Z

In many situations, there are times when you need to remediate an application using MED-V that requires one or more components to be resident at user logon/startup. These type of programs can certainly be remediated with MED-V. it is important to understand that while there are several ways of doing this in Windows, but not all of those ways will work within MED-V. Typically, the options for startup upon user login include:

Launching in the System Tray: These applications will automatically launch and will be published to the host system tray with a “(Remote)” option. No additional configuration should be necessary when running these types of applications under MED-V.
Launching via the “Run” key (in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run): These applications will also automatically start when the user logs in and no additional configuration should be necessary when running these types of applications under MED-V.
Launching via the “Startup” Program Group in the Windows Start Menu: Here is where you will run into problems. Since Explorer.exe is not the shell used when launching applications in MED-V (RDPShell is) the Startup program group shortcuts will not be launched.

Additional Options for Launching Shortcuts

Since the shortcut contains vital information such as working directory, command line arguments, etc., simply putting the command into the Run key will not suffice as a workaround in many cases. You can, however, configure the run key to process the shortcut .LNK file by adding the entry to the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run as a REG_SZ value (give it a name of your choice) and use the following syntax for launching the application:

cmd /c start "window name" <PATH><NAME>.LNK

Please Note: The “Window Name” is not optional and must be in quotes. The name can be whatever you choose so long as the path is valid to the .LNK file of the shortcut.

How FTA’s (File Type Associations) Work in MED-V V2

2013-04-06T02:04:54Z

One of the most major feedback items about MED-V V1 was the lack of FTA (file type association) linkage between host documents and guest applications. This changed in MED-V V2. Through the use of RDP-redirected folders and the RemoteApp-style of FTA configuration, you are able to take advantage of this so long as the applications are published properly to the host (Windows 7) and the application maintains those associations in the guest operating system (Windows XP.) This only works in one direction (host documents to guest applications.)

Host Operation

MED-V FTA overrides are user-based and are registered to HKEY_CURRENT_USER. For example, if you have an application called “Application A” with an executable of Application1.exe, and it registers an extension - .ABC, there will be a registration for the FTA located in HKEY_CURRENT_USER\Software\Classes\.ABC

The default value will be REG_SZ-based in the form of <PAI><VMName> where the PAI will be the hash of the published application and separated by dots will be the name of the virtual machine hosting the application (with spaces replaced with periods “.” If present in the VMName field.) So if you have a published application in the virtual machine called “Windows XP Compatibility” it would look something like this:

6abd1cee.Windows.XP.Compatibility

There will be a subkey HKEY_CLASSES_ROOT\.abc\OpenWithProgids tying to this same special object. In addition, you will see a registration for this file type object by its name (6abd1cee.Windows.XP.Compatibility) also registered in HKEY_CURRENT_USER with a \shell\open\command sub key that
contains the path to open the published application. Using the above example, it would like this:

“C:\Program Files\Microsoft Enterprise Desktop Virtualization\medvhost” /launchapp “Windows XP Compatibility” “||6abd1cee” “Application A” “%1”

In the screen shot below, you will see a series of examples using Visio 2002 as the published application registering its file type associations in the host.

Guest Operations

The application will launch and load the file from the host operating system using RDP folder redirection (i.e. \\TSCLIENT\C\Users\<USERNAME>\Desktop, if clicking on the host desktop.) You will not expect this seamless behavior when running the application from a VPC window (a full desktop) because it is
out of band to MED-V and the MED-V agents cannot automatically redirect using the RDP folder redirection mechanism. The only File Type Associations that will automatically publish will be those associations in the guest operating system belonging to applications that are auto-published.

Conflicts

Conflicts may occur if the published application shares a file type with one installed in the guest. From my experience it will only be a concern if you are desiring the use of the local application in place of the published application.

Updated List of Recommended Hotfixes for Windows 7 SP1 Computers Running MED-V V2.

2013-03-06T16:52:00Z

In July 2011, we published a blog on recommended hotfixes for Windows 7 computers running MED-V v2 (Additional Recommended Updates for MED-V 2.0 that Address Application Issues) referenced here: http://blogs.technet.com/b/medv/archive/2011/07/20/additional-recommended-updates-for-med-v-2-0-that-address-application-issues.aspx?wa=wsignin1.0

Here is an updated list of post-Windows 7 Service Pack 1 hotfixes we recommend you install for use with MED-V that address RDP/RemoteApp/RAIL-related issues. In addition to the post-SP1 hotfixes mentioned previous (also mentioned below)

. . . it is also recommended that you install these hotfixes:

If you start experiencing cosmetic issues with published applications in MED-V, make sure you have these patches installed. These hotfixes can be downloaded from their respective KB article pages.

Support Tip: MED-V apps disappear when a Windows 7 host is set to use the Japanese Language

2013-02-28T18:02:36Z

Hello everyone, John Behneman here, and today I wanted to take a minute to mention an issue you might run into if you use MED-V on a Windows 7 host that is set to use the Japanese language. What happens is that when a MED-V v2.0 Windows 7 host is set to use the Japanese language, the currently published MED-V applications may no longer appear on the start menu.

This should only happen if you have the following update applied:

KB2541024 - Microsoft Enterprise Desktop Virtualization (MED-V) 2.0 – Localization Update (http://support.microsoft.com/kb/2541024/EN-US)

The reason for this is because the shortcuts are getting updated incorrectly, thus the applications are no longer visible.

Fortunately the fix is pretty straight forward. What we need to do is run these three commands on the Windows 7 host after the language change:

wmic /namespace:\\root\Microsoft\Medv PATH Setting set UxAppPublishingEnabled=0
REG DELETE "HKCU\SOFTWARE\Microsoft\MEDV\Application Publishing" /f
wmic /namespace:\\root\Microsoft\Medv PATH Setting set UxAppPublishingEnabled=1

Once you restart the computer the icons will republish automatically although it may take a few seconds as the MED-V Workspace starts up.

Note that these commands can be run via a script or they can be run manually – your choice.

John Behneman | Senior Support Escalation Engineer | Microsoft CTS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms- identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

MED-V V2: Problems with Drive Redirection when Smart Card Redirection is disabled

2013-02-27T04:10:40Z

You may encounter issues with the C:\ Drive not being properly redirected from the guest to the host (and thus causing the “Documents/My Documents” folder to not be redirected and synchronized between the host and the guest) when Smart Card Redirection has been disabled. Any features dependent upon connections from the guest to \\TSClient\C will also be affected. Please note that this is an intermittent problem and it may not occur on all machines. This is a known issue and is related to a well-known issue that was once affecting Windows Server 2003 RDS servers a few years back. That issue was addressed with a hotfix and is discussed in the
following KB article:

“When you use Remote Desktop Connection to connect to a Windows Server 2003-based terminal server, or to Windows XP, the first drive letter of the computer from which you connect is not redirected to the Terminal Services session”

http://support.microsoft.com/kb/940458

For MED-V scenarios, smart cards are disabled in MED-V default for authentication. This configuration can be set under the following registry key:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\UserExperience

Value: SmartCardLogonEnabled

It defaults to 0. It needs to be turned on by setting to 1 to allow for Smart Card use. Enabling this will also resolve the issue mentioned above. NOTE: If SmartCardLogonEnabled and CredentialCacheEnabled are both enabled, SmartCardLogonEnabled overrides CredentialCacheEnabled.

Right now this workaround will be the only remediation provided for this issue. There will be no hotfix for this issue.

System Center Blogs: Now on iPhone, Android and Windows Phone

2012-11-27T18:27:28Z

If you liked the original System Center Blogs app that was published last year for Windows Phone and Android, you’ll be happy to know that both apps have now been updated, plus there is a new version now available for iOS. The updates include bug fixes and feature additions as well as a current list of blogs that includes the major official Microsoft System Center related properties.

As before, these are apps I created via AppMakr (no affiliation) with the intention of simply making it easier for IT pros to keep up with all the latest news and information we publish regarding System Center, WSUS and our MDOP virtualization products. If you’re interested in more of the history and background behind this you can read about that in the original post here, but if you want to skip all that and jump straight to loading them up and checking them out you can do a simple search for System Center via your phone or you can view them on the web using the links below:

Enjoy!

J.C. Hornbeck | Knowledge Engineer | Management and Security Division

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Support Tip: Windows XP Compatibility 2 Setup Wizard ends prematurely when installing a MED-V Workspace

2012-07-24T17:48:04Z

When deploying a MED-V 2.0 workspace, an error message may be generated during the VHD copy routine of the setup. The Workspace Setup then roles back and presents the following message:

Windows XP Compatibility 2 Setup Wizard ended prematurely

Windows XP Compatibility 2 setup wizard ended prematurely because of an error. Your system has not been changed. To install this program at a later time, run the setup wizard again. Click the Finish button to exit the setup wizard.

When executing the Workspace setup from an elevated command prompt using the following verbose logging switches, an IO error is present in the log indicating VHD file corruption:

setup.exe /l*vx! C:\temp\log.txt # NOTE: KB 2545723 provides an alternate way to create a verbose setup log see more Information Section

The verbose setup log indicates a problem with the VHD embedded in the file with the .medv extension:

A generic exception occurred while unpacking VHD
System.IO.IOException: I/O error encountered in attempting to open file ---> Xceed.Compression.CompressionException: Expected end of stream not found
at Xceed.Compression.ManagedDeflateDecompressor.Decompress(Byte buffer, Int32 offset, Int32 count, Boolean& endOfData, Byte& decompressed, Int32& remaining)
at Xceed.Compression.CompressedStream.Read(Byte buffer, Int32 offset, Int32 count)
at Xceed.Utils.Streams.ChecksumStream.Read(Byte buffer, Int32 offset, Int32 count)
at Xceed.Zip.ReaderWriter.ZipReader.ReadItemData(Byte buffer, Int32 offset, Int32 count)
at Microsoft.Medv.WorkspaceCustomActions.VhdUtil.Decompress(Session session, String compressedVhdPath, String vhdInstallationFilePath, Boolean overwriteExistingVhd)
--- End of inner exception stack trace ---
at Microsoft.Medv.WorkspaceCustomActions.VhdUtil.Decompress(Session session, String compressedVhdPath, String vhdInstallationFilePath, Boolean overwriteExistingVhd)
at Microsoft.Medv.WorkspaceCustomActions.CustomActions.InstallVhd(Session session)
CustomAction InstallVhdFile returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

Normally you could rename the *.medv file to a .zip extension and then open the compressed folder and access the embedded VHD file. In this scenario, the following message may be generated:

Windows cannot open the folder
The Compressed (zipped) Folder 'C:\temp\Windows XP x86 SP3 Hard Disk.zip is invalid.

This can occur if there is corruption of either the *.medv file or the embedded *.vhd file contained within the *.medv file.

To resolve this issue, restore the Med-V Workspace package from backup or create a new package using the MED-V Workspace Packager. Make sure that any antivirus or malware scanners are disabled during the packaging process. If you must run your malware scanner due to corporate policy please reference KB article 2504827 to put in place the proper exclusions. These exclusions should be applied to both the Workspace packager and the Med-V Host.

KB2504827 - MED-V 2.0 workspace setup fails with a fatal error : http://support.microsoft.com/kb/2504827/EN-US

For more information see the following:

KB2545723 - How to Enable Microsoft Installer logging and Verbose logging to gather additional troubleshooting Information : http://support.microsoft.com/kb/2545723/EN-US

John Behneman | System Center Support Engineer

Get the latest System Center news on Facebook and Twitter:

MED-V URL redirection is not working and no *.mdvurl file is being created

2012-02-13T19:48:19Z

Here’s a new Microsoft Enterprise Desktop Virtualization (MED-V) Knowledge Base article we published today. This one talks about an issue where a restricted user can attempt certain actions that they don't have permission to yet get a (false) message indicating it was successful.

=====

Symptoms

Microsoft Enterprise Desktop Virtualization (MED-V 2.0) URL redirection does not work and no temporary URL file *.mdvurl is created in %localappdata%\temp (e.g. C:\Users\username\AppData\Local\Temp\tmpE38B.tmp.mdvurl).

Cause

This can occur if the URLs in the MED-V URL list are not valid. An example would be a URL that has a trailing * such as:

http://www.msn.com*

Resolution

To resolve this , navigate to the following registry location and remove the trailing * from any URL addresses listed.
HKLM\software\microsoft\medv\v2\UserExperience\RedirectUrls

More Information

The only issue relevant to this problem is addressed in the first blog post listed below, in the first section, regarding the creation of the temporary URL file containing the URL to pass the guest via RDPcopy (*.mdvurl). All the other issues that cause URL redirect failures outlined in these two articles do not exist in this scenario.

Understanding and Troubleshooting MED-V v2 URL Redirection
http://blogs.technet.com/b/medv/archive/2011/08/10/understanding-and-troubleshooting-med-v-v2-url-redirection.aspx

GPO Settings That Could Potentially Cause Issues with MED-V Features
http://social.technet.microsoft.com/wiki/contents/articles/5127.aspx#Internet_Explorer_Policies

=====

For the most current version of this article please see the following:

2671040 : MED-V URL redirection is not working and no *.mdvurl file is being created

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

Microsoft Enterprise Product Roadmap Webcast

2012-01-19T17:16:47Z

Please join us for a high level discussion into Microsoft software investments designed to cover most of the major product lines. This will be a 35,000 foot view into the following areas:

Windows Family
Virtualization
Office System
Unified Communications
IT Management
Security

This particular webcast is scheduled for Friday, January 20 at 1:00pm Pacific Time although others are scheduled as well. See this link for more information.

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

MED-V Host Agent Setup fails with “MED-V Host Agent requires Windows Virtual PC 7 version 6.1.7600 or higher”

2012-01-19T17:08:35Z

Hi everyone, Mark Stanfill here and today I wanted to take a minute to quickly tell you about an issue I recently ran into where the MED-V Host Agent Setup (MED-V 2.0 Host Agent) fails with the following error message:

MED-V Host Agent Setup

MED-V Host Agent requires Windows Virtual PC 7 version 6.1.7600 or higher.

This is an error you can get if Windows Virtual PC is not present on the host OS and it does not have the 958559 update applied. Now fortunately for us this is an easy fix. To resolve this issue and allow the MED-V 2.0 Host Agent to install, use the following steps:

Download and install the 958559 update (http://support.microsoft.com/default.aspx?scid=kb;EN-US;958559).
Reboot the host OS when prompted.
Re-run MED-V_HostAgent_Setup.exe

That’s it!

Mark Stanfill | Senior Support Escalation Engineer

Get the latest System Center news on Facebook and Twitter: