This is the part 2 of a 4-part Mad About MED-V series. This screencast presents the user experience of running MED-V applications by going through essential user operations of a MED-V client.
The Mad About MED-V screen series include:
and each link is to be updated once the associated screencast is published. The remainder of this posting highlights some of the content presented in Part 2.
Seamless UI Integration with Host Computer
As discussed in Part 1 of this series, a MED-V workspace policy optionally allows a MED-V application integrated into the All Programs menu of the host computer as shown below, despites the fact that the MED-V application is configured and running in a Virtual PC behind the scene.
Running MED-V Application
To run a MED-V application, the workspace must first be started. A MED-V client can be loaded at Widows startup time if specified in the MED-V Client Settings, in such case a workspace can be also set to start automatically. This ensures the workspace is always in place, should a user require running a MED-V application once the computer has been started. And if the workspace has not been initialized, it will start on demand followed by bringing up the application upon completing the workspace initialization. Once a workspace is started, additional options like locking/restarting/stopping workspace become available when right-clicking the MED-V client icon in the system tray. A user also at this time has the access to utilities like the File Transfer tool as shown below. The Fire Transfer tool enables a user to transfer files between the host computer and the MED-V application running in the Virtual PC in the background.
In MED-V workspace policy, a MED-V administrator can optionally configure a color border to surround a running MED-V application as shown above. The setting of showing a color border can be easily changed or disabled within workspace policy by a MED-V administrator.
A MED-V workspace policy can be configured to automatically redirect a request for a target website from the host computer to the browser in the Virtual PC. This allows every request to a target URL with a web application incompatible with the browser installed on the host computer gets redirected to a compatible browser running in the Virtual PC behind the scene. The following screen capture shows a request redirected from the host computer which runs IE7 to the IE6 (with a red border) running in the hidden Virtual PC.