Partager via


Understanding and Troubleshooting MED-V v2 URL Redirection

imageHi everyone, Steve Thomas here and I wanted to take a minute to talk about understanding and troubleshooting MED-V v2 URL redirection.  One of the most important reasons for deploying MED-V v2 is for legacy Internet Explorer browser compatibility. Like in V1, URL redirection is included to enhance the user experience and to ensure that any URL typed in the host will get properly redirected to the legacy browser running in the guest browser. The process is slightly different in v2. In MED-V 2, URL Redirection involves the process of passing a URL resource between the host and the guest by way of a remote copy leveraging the underlying RDP support from Windows Virtual PC for Windows 7. This is important to know in the event you may experience problems with URL redirection.

The MED-V Host agent will create a temporary URL file containing the URL to pass into the guest via RDPcopy. For example:

C:\Users\steveth\AppData\Local\Temp\tmpE38B.tmp.mdvurl

The MED-V Host agent will then launch the guest browser application by triggering a command similar to as the following:

"C:\Windows\System32\vmsal.exe" "Windows XP Compatibility (Shared)" "||BrowserLauncher" "BrowserLauncher" "C:\Users\steveth\AppData\Local\Temp\tmpE38B.tmp.mdvurl"

In the above example the “BrowserLauncher” application from my currently running workspace “Windows XP Compatibility (Shared),” is called through the VMSAL.EXE process (VPC application launcher.)

How to Troubleshoot

If you encounter issues where a configured URL is not redirected from the host to the guest properly, follow these steps to help you nail down where the issue may.

1) Verify the syntax of the URL.

2) Verify you are not encountering the issue outlined in the following KB:

https://support.microsoft.com/kb/2504970

3) If the above fails, create a text file in an accessible location on the host (like C:\Temp). Put the URL in the file. Call it Test.mdvurl.

4) Assuming the file created is ”C:\Temp\test.mdvurl”, MED-V is installed in “C:\Program Files\Microsoft Enterprise Desktop Virtualization”, and your VM is named “myvm”, launch the URL in the guest with the following command:
“C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe" /LaunchApp “C:\windows\system32\vmsal.exe" "myvm" "||BrowserLauncher" "BrowserLauncher" "C:\Temp\test.mdvurl"
(REPLACE "MYVM" WITH YOUR VM NAME)
This will test the MED-V Host Agent’s capability to trigger the Virtual PC application launcher to trigger the guest browser launcher.

5) If that fails, try the Virtual PC application launcher command by itself as the next step:

“C:\windows\system32\vmsal.exe" "myvm" "||BrowserLauncher" "BrowserLauncher" "C:\Temp\test.mdvurl"

(REPLACE "MYVM" WITH YOUR VM NAME)

If #3 works but #2 does not, there is a problem with the vmsal wrapper in MED-V. If #2 fails too, you can try running the BrowserLauncher directly by going into the VM (for example, via a guest command prompt window), creating the .mdvurl file by hand, and then running:

“C:\Program Files\Microsoft Enterprise Desktop Virtualization\BrowserLauncher.exe" "C:\Temp\test.mdvurl"

If this works but the previous two attempts do not, there is probably a problem with the tsclient mappings to the host filesystem. This can be confirmed by trying to list \\tsclient\c\temp, for example. If the attempt to do this fails, this indicates a VPC failure to create the mappings. Often when this happens because auto-publish and integration components have not been enabled in the guest VPC. Also be careful that RDP/TS policies are not affecting your MED-V Hosts. The two policies that we have seen inadvertently cause MED-V folder redirection issues are:

Path: Administrative Templates\Windows Components\TerminalServices\Terminal Server\Device and Resource Redirection

Policy: Do not allow drive redirection

Or

Path: Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Client/Server data redirection

Policy: Do not allow drive redirection

Steve Thomas | Senior Support Escalation Engineer

App-V Team blog: https://blogs.technet.com/appv/
AVIcode Team blog: https://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
DPM Team blog: https://blogs.technet.com/dpm/
MED-V Team blog: https://blogs.technet.com/medv/
OOB Support Team blog: https://blogs.technet.com/oob/
Opalis Team blog: https://blogs.technet.com/opalis
Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: https://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: https://blogs.technet.com/mdm/
SCVMM Team blog: https://blogs.technet.com/scvmm
Server App-V Team blog: https://blogs.technet.com/b/serverappv
Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: https://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: https://blogs.technet.com/sus/

clip_image001 clip_image002

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    December 27, 2013
    Here’s a new Microsoft Enterprise Desktop Virtualization (MED-V) Knowledge Base article we published