Windows Virtual PC

Using Scripting API for Advanced Operations in Windows Virtual PC

Windows^® Virtual PC (WVPC) brings for the first time scriptable API to a Microsoft client virtualization product. These APIs are a very powerful tool in the hands of power users and administrator to do some very cool things and achieve functionality which is not obvious or possible from the normal user interface. We present here a few examples of how to use these API in Windows PowerShell^®.

Deleting a Virtual Machine completely

Windows virtual PC provides a new and unique console view for Virtual Machine (VM) management. Here, VMs are represented as files (.vmcx) in the Virtual Machines folder. The Virtual Machines folder is present at (%systemdrive%\Users\<user name>\Virtual Machines). Here you can see how many VMs are registered on your system, their state and create new VMs. Removing a VM is just deleting the .vmcx file. But this does not remove the VM completely. Rather, it just unregisters the VM, and the virtual machine files are still present on your system (in the folder %localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\) which you can bring back very easily by just double-clicking on the .vmc file. But this would create a lot of clutter on your system over time if you create a lot of VMs.

Using the following PowerShell script you can easily remove a VM completely. Please replace “My VM” with the name of your virtual machine. Be very careful while using this script as it would remove all the files related to your virtual machine including VHDs.

   1: $vpc = New-Object -ComObject "virtualpc.application"

   2:  

   3: $vm = $vpc.FindVirtualMachine("My VM")

   4:  

   5: if ( $vm )

   6:  

   7: {

   8:  

   9: if ($vm.state -eq 5) # check for running state

  10:  

  11: {

  12:  

  13: echo "cannot delete a running VM"

  14:  

  15: }

  16:  

  17: else 

  18:  

  19: {

  20:  

  21: if ($vm.state -eq 2) # check for saved state

  22:  

  23: {

  24:  

  25: echo "Discarding saved state"

  26:  

  27: $vm.DiscardSavedState()

  28:  

  29: }

  30:  

  31: if ($vm.undoable -eq $true)

  32:  

  33: {

  34:  

  35: echo "discarding undo disks"

  36:  

  37: $vm.DiscardUndoDisks()

  38:  

  39: }

  40:  

  41: foreach ($hdc in $vm.HardDiskConnections)

  42:  

  43: {

  44:  

  45: echo "deleting vhd file"

  46:  

  47: $hd = $hdc.HardDisk ;

  48:  

  49: $vm.RemoveHardDiskConnection($hdc) ;

  50:  

  51: del $hd.File ;

  52:  

  53: }

  54:  

  55: echo "deleting virtual machine"

  56:  

  57: $vpc.DeleteVirtualMachine($vm)

  58:  

  59: }

  60:  

  61: }

  62:  

  63: else

  64:  

  65: {

  66:  

  67: echo "VM does not exists"

  68:  

  69: }

Moving the parent of a VM’s hard disk to some other location

Moving a VM is easy. Just copy all the virtual machine files (.vmc, .vhd, .vsv etc) to a different location and double-click on the .vmc file to start the VM from there. What if your virtual machine has a differencing disk? If the parent VHD is located in the same folder as the child then you just need to move all the files together for relocating you VM. But if your VM’s parent is in some other folder, then you cannot change the location of the parent, otherwise your VHD chain would break and you would not be able to start your VM. Let us see, with the help of an example, how you can use the VPC COM APIs to get over this limitation.

Suppose the parent disk (parent.vhd) is present at c:\vhdstore.

Your other VM files are present in the usual location (%localappdata%\Microsoft\Windows Virtual PC\Virtual Machines\) and you want to move these files to the D: drive as you want to format your C: drive. You place the parent VHD in the location D:\VHDStore and all the other files at D:\VMs. Now your VM won’t start as you parent location would not match with the one that is present in the child VHD.

Run the following commands on the PowerShell to restore the new path of the parent VHD and make the VM operational again. It’s assumed that your VM name is “My VM” and the new parent location is “D:\VHDStore\parent.vhd”

   1: $vpc = New-Object -ComObject "virtualpc.application"

   2:  

   3: $vm = $vpc.FindVirtualMachine("My VM")

   4:  

   5: $hd = $vpc.GetHardDisk("D:\VHDStore\parent.vhd")

   6:  

   7: $vm.HardDiskConnections.Item(1).harddisk.parent = $hd

Now you should be able to start your VM from the new location.

You can use this trick even if you just want to change the location of your parent VHD and not move the other files.

Disabling Time Sync between the host and guest

Windows virtual PC periodically syncs the time of the guest to that of the host to keep both of them in sync. But if you do not want that to happen then you can disable time sync totally using the following script. Please remember that the Virtual Machine should be in the turned off state before running this script.

   1: $vpc = New-Object -ComObject "virtualpc.application"

   2:  

   3: $vm = $vpc.FindVirtualMachine("My VM")

   4:  

   5: $vm.SetConfigurationValue("hardware/bios/time_sync_at_boot",$false)

   6:  

   7: $guest = $vm.GuestOS

   8:  

   9: $guest.IsHostTimeSyncEnabled = $false

In closing…

Using the COM APIs provided with WVPC, you can achieve some of the things that seem to be not possible using the conventional user interface.  Keep a watch on this blog space for more such tips and tricks. And you can check out the WVPC COM APIs here http://msdn.microsoft.com/en-us/library/dd796756(VS.85).aspx, and see the vast set of APIs provided to help with your VM management tasks.

Palash Kar

SDE

Microsoft Virtualization Team

Auto-Start and Close Options for Windows Virtual PC

In Windows® Virtual PC (WVPC), Virtual Machine (VM) start-up and close behavior can be configured to have a customized user experience.   Few start-up options can actually lead to perceivably faster launching of Virtual Applications.  In this blog, we will discuss these options and settings along with their pros and cons.  This should be helpful for you to understand the best performance tweaks that can be done with WVPC VM and the kind of impact it can have on your machines.

Once a VM is created, it can be started in Desktop mode from the Windows® Virtual PC Center. However Windows® XP Mode VM can be directly started from the Start Menu.

Figure 1: Windows® Virtual PC Center to create or launch a VM

If Integration Components (IC) are installed (recommended), then by default the VM tries to enable Integration Features (IF) on VM start-up. This behavior can be changed through VPC Settings -> Integration Features -> Uncheck ‘Enable at startup’.  However the user always has the option to manually enable/disable Integration Features while VM is running, from the tools menu as well. The same can also be accomplished through script #1.

Start-up time of a VM may be reduced if this setting is disabled but Integration Features like Clipboard (copy/paste), Drive, Printer and Smart Card redirection will not be available. Also the POST screen of the VM booting would be visible.

This may be the ideal usage setting where VM needs to be used in isolation from the host or is only remotely accessed through Remote Desktop Connection etc.

Figure 2(a): WVPC Settings to change Auto-Enable Integration Features                                Figure 2(b): Manually disabling Integration Features

Script #1: Disable Integration Features at Start-up

   1: Option Explicit   ' Force explicit variable declaration.

   2:  

   3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

   4: Set objArgs = WScript.Arguments

   5: Set objVPC = CreateObject("VirtualPC.Application")

   6:  

   7: defaultVMTag = "default_vm"

   8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

   9:      

  10: if objArgs.Count < 1 Then

  11: WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

  12:      WScript.Echo "Considering default VM."     

  13:      vmName  = defaultVM

  14: Else

  15:      vmName  = objArgs(0)        

  16: End if

  17:  

  18: DisableIF()

  19:  

  20: Sub DisableIF()

  21:     Dim vmcTag, objVM

  22:     vmcTag = "ui_options/use_enhancedmode"

  23:     Set objVM = objVPC.FindVirtualMachine(vmName)

  24:     

  25: if objVM is Nothing Then

  26: WScript.Echo "VM not found: """ + vmName + """" 

  27: Else

  28: WScript.Echo "Disabling Integration Features at Startup for the VM: """ + vmName + """"

  29: objVM.SetConfigurationValue vmcTag, False

  30:     WScript.Echo "Integration Features at start-up disabled successfully"        

  31: End if

  32: End Sub

This script will disable Integration Features for the default VM (or the specified VM, if <VMName> is passed as an argument to the script).

Similarly, a Virtual application can also be launched from Windows® 7 Host start menu once the application has been published from the VM. All published applications of a VM are listed under, Programs -> Windows Virtual PC -> <VMName> Application* in Windows® 7 Start Menu.

PS: Scripting provides a useful means to perform a number of operations on VMs such as Creating, deleting, changing VM configuration, states and tracking VM state, health and other information about it. PowerShell is another powerful medium to interact with the VM. The blog uses VBScript for code snippets. These code snippets can be saved as <ScriptName>.vbs file and executed in Windows® 7 command prompt with the following syntax: cscript <Scriptname>.vbs arg1

Starting a headless VM

Sometimes, you might want to start a VM in the back ground without any User Interface. This can be of great use for IT Administrators/Professionals, Developers & testers. For example if you want to reduce the latency of Virtual Applications start-up time, remotely use the VM through Remote Desktop Connections or execute some tests in isolation without any user interference.

This is referred as a Headless VM configuration.

Here is a sample VB script to start the VM in Headless mode.

Script #2: Starting a VM in Headless Mode

   1: Option Explicit   ' Force explicit variable declaration.

   2:  

   3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

   4: Set objArgs = WScript.Arguments

   5: Set objVPC = CreateObject("VirtualPC.Application")

   6:  

   7: defaultVMTag = "default_vm"

   8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

   9:      

  10: if objArgs.Count < 1 Then

  11: WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

  12:      WScript.Echo "Considering default VM."     

  13:      vmName  = defaultVM

  14: Else

  15:      vmName  = objArgs(0)        

  16: End if

  17:  

  18: WScript.Echo "Starting VM: """ + vmName + """"

  19: StartHeadlessVM()

  20:  

  21:    Sub StartHeadlessVM()

  22:     Dim objVM

  23:     Set objVM = objVPC.FindVirtualMachine(vmName)

  24:     if objVM is Nothing Then

  25:         WScript.Echo "VM not found: """ + vmName + """"          

  26:     Else

  27: Dim objVMTask

  28:         Set objVMTask = objVM.Startup()

  29:         'Set objVMTask = objVM.TurnOff() 'Immediately Turns Off/Powers Down the VM

  30:         'Set objVMTask = objVM.Save()    'Hibernate the VM

  31:         'Set objVMTask = objVM.GuestOS.Shutdown(0) 'Controlled Shutdown

  32:         'Set objVMTask = objVM.GuestOS.Shutdown(1) 'Forced Shutdown

  33:         objVMTask.WaitForCompletion -1

  34:         WScript.Echo "VM Started : """ + vmName + ""        

  35:     End if

  36:    End Sub

When host logoff, shutdown or restart is initiated, each running headless VM is first hibernated. This may cause some delay in host logoff, shutdown or restart. Also Integration Features cannot be enabled for headless VM. Additionally, user also has to keep a track of headless VMs as they run behind the scene i.e. without any User Interface.

Auto Start a VM

A VM can be configured to start at Windows® 7 start-up. When a VM is setup to start on Windows 7 Start up, it drastically reduces the time required for first time launch of Virtual Application. However, with this configuration, the VPC.exe will keep running, holding the resources like RAM allocated to the VM and speed up battery drainage on laptops. However in case of desktops the following configuration can help is faster launching of Virtual Application. Since the VM would be started immediately after login into Windows 7, there might be some impact on the responsiveness of the host for couple of seconds.

Auto Start a Virtual Application:

Copy the shortcut of the Virtual Application to start-up folder of Windows 7 that needs to be started on Windows 7 start-up. In this example, Virtual Application-Internet Explorer 6 has been set to auto start with Windows 7 start-up.

Location:

Virtual Application: %appdata%\Microsoft\Windows\Start Menu\Programs\Windows Virtual PC\<VMName> Applications*

Windows 7 Start-up Folder: %appdata%\Microsoft\Windows\Start Menu\Programs\Startup

Auto Start VM in Headless mode

Create a shortcut of script #2 under Windows® 7 start-up folder with the following target: cscript <pathoftheScript>\<scriptname>.vbs <”VMName”>

Figure 3: Set a Virtual Application to Auto-Start

Auto Start VM in Desktop Mode

VM can also be set to auto start with Windows® 7 start-up in desktop mode. This can be easily accomplished by adding the shortcut of the <VMName> .vmcx file (vmcx file is located in Windows® Virtual PC Center) in start-up folder.

Figure 4: Set VM to Auto-Start in Desktop Mode

Close a VM

A VM in Desktop Mode can be manually closed by the user, either from the user Interface (Figure - 5) or through scripts (refer script #3 for details). Notice that there are 4 options for ‘Closing’ a VM. Each option has its own benefits and use case.

Figure 5: Close VM options.

Hibernate: This is very similar to hibernate of a physical machine. The VM is initially set to Pause/sleep state and then VM memory is purged to a save state file (<VMName>.vsv). The difference in VM hibernate as appose to a Physical machine is that VM is unaware about hibernation or resume thereafter. Unlike the physical machine where the machine itself initiates hibernation/resume, here the Host does it for the VM. Hence, this operation doesn’t require ICs to be installed. This mechanism offers benefits like quick shutdown and resume, no data loss. This is the default close setting for XP Mode VM. This setting can be modified either through VPCSettings -> Close.

It is not recommended to migrate a VM in hibernate state as difference in processor architecture of the two host machines can render the save state useless. In such case, deleting the save state file would allow the VM to boot up, but may lead to data loss.

Alternatively VM can be hibernated through scripts. Script #2 can be easily modified to accommodate the same.

Shutdown: This would initiate a graceful shutdown of the VM. Since this is done by Guest OS it requires ICs to be installed in the VM. Here the scripts provide an additional option to force shutdown the VM. Shutdown of a VM is absolutely identical to a physical machine.

Turn Off: This is very similar to Powering off the machine. It is not recommended as it may lead to data loss or corruption of Guest OS.

Turn Off and discard changes: This option appears only when ‘Undo Disks’ is enabled. It will delete all data in the undo disk (.vud file). This option should be used with caution as it may lead to data loss.

Figure 6: Default close VM setting for XP Mode

Script #3: Enable prompt while closing the VM

   1: Option Explicit   ' Force explicit variable declaration.

   2:  

   3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

   4: Set objArgs = WScript.Arguments

   5: Set objVPC = CreateObject("VirtualPC.Application")

   6:  

   7: defaultVMTag = "default_vm"

   8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

   9:      

  10: if objArgs.Count < 1 Then

  11: WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

  12:      WScript.Echo "Considering default VM."     

  13:      vmName  = defaultVM

  14: Else

  15:      vmName  = objArgs(0)        

  16: End if

  17:  

  18: PromptAtClose()

  19:  

  20:    Sub PromptAtClose()

  21: Dim vmcTag, objVM

  22:     vmcTag = "ui_options/onclose_showmessage"

  23:     Set objVM = objVPC.FindVirtualMachine(vmName)

  24:     if objVM is Nothing Then

  25:         WScript.Echo "VM not found: """ + vmName + """"          

  26:     Else

  27: WScript.Echo "Enable prompt on VM close: """ + vmName + """"

  28:         'This will enable prompt at close. User can then choose the close method

  29:         objVM.SetConfigurationValue vmcTag, True

  30:         'To set the default behaviour at VM close. No prompt will be thrown in this case

  31: 'and default action can also be set

  32:         'objVM.SetConfigurationValue vmcTag, False

  33: 'objVM.SetConfigurationValue "ui_options/onclose_defaultaction", "save" 'save/shutdown/turnoff

  34:         WScript.Echo "Close option set successfully"        

  35:     End if

  36:    End Sub

However, shutdown in case of a Virtual Application does not involve any explicit User Interface. Let’s look at the VM state transitions that take place when a user interacts with Virtual Applications:

1. VM will be started if it is not already running when the first Virtual Application is launched.
2. When the last Virtual Application (launched by the user) is closed and none of the other Virtual Application’s window is opened, the VM hibernates after 5 minutes. Script #4 can be modified to set the value of the VMC tag: ‘ui_options/seconds_to_save’ to the desired time duration).
3. While Virtual Applications are running and Windows® 7 host is logged off or shutdown, graceful (controlled) shutdown of VM is initiated.
4. Similarly, if Windows® 7 host goes to hibernate or sleep state, the VM is paused. On host resume, the VM auto wakes up. This may also cause the Virtual applications to be unresponsive during this short time interval.
5. In case of forced Host shutdown, VM is powered off abruptly.

Note: In case of headless VM, Windows® 7 Host logoff/shutdown/restart will always initiate VM hibernate/save.

‘Never Hibernate’ VM Setting

When the last Virtual Application is closed (launched by the user), the VM will go into hibernate state after 5 minutes by default. This is done to ensure that host resources are freed and battery drain can be reduced when no virtual application is running. This setting can be changed so that the VM never hibernates and subsequent Virtual application can be launched with minimum latency.

Script #4: Set VM to Never Hibernate

   1: Option Explicit   ' Force explicit variable declaration.

   2:  

   3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName  

   4: Set objArgs = WScript.Arguments

   5: Set objVPC = CreateObject("VirtualPC.Application")

   6:  

   7: defaultVMTag = "default_vm"

   8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)

   9:      

  10: if objArgs.Count < 1 Then

  11: WScript.Echo "Syntax: cscript <scriptname>.vbs <”VMName”>"

  12:      WScript.Echo "Considering default VM."     

  13:      vmName  = defaultVM

  14: Else

  15:      vmName  = objArgs(0)        

  16: End if

  17:  

  18:  

  19:  SetValue()

  20:  

  21:  Sub SetValue()

  22:  Dim vmcTag, objVM

  23:  vmcTag = "ui_options/seconds_to_save"

  24:  Set objVM = objVPC.FindVirtualMachine(vmName)

  25:  if objVM is Nothing Then

  26:         WScript.Echo "VM not found: """ + vmName + """"          

  27:  Else

  28:          objVM.SetConfigurationValue vmcTag, 0

  29: WScript.Echo "VM: """ + vmName + """ set to never hibernate"

  30:  End if

  31:  End Sub

This script sets the value of VMC tag "ui_options\seconds_to_save" to 0 and hence VM would never be hibernated even after closing the last Virtual Application. This tag can also be used to increase or decrease the time to hibernate the VM when last Virtual application is closed.

Note: This tag doesn’t impact VMs running in desktop or headless mode.

In most of the cases, this would ensure faster virtual application launch, as VM doesn’t hibernates after closing the last virtual application (launched by the user). But in case of host restart, first virtual application launch will still take time as VM needs to be started first. This can also be tweaked by adding an entry of starting a headless VM on Window 7 startup (refer Auto Start VM in Headless Mode)

Conclusion

In WVPC, you can configure the VM start-up and close behavior using WVPC settings and the sample scripts presented above, to optimize the user experience and performance of VMs and virtual applications.  Check out WVPC and Windows XP Mode today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on TechNet here.

*This may get localized based on Windows® 7 Host language.

Priyank Gaharwar

SDET

Microsoft Virtualization Team

Tip: Using the keyboard to access useful functionality in Windows Virtual PC

When you use a Virtual Machine (VM) created using Windows^® Virtual PC (WVPC), following keyboard shortcuts would be very useful to make life simple without using the mouse:

Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Rahul Razdan

Program Manager

Microsoft Virtualization Team

Publishing Virtual Applications in Windows Virtual PC

Windows® Virtual PC (WVPC) provides a feature called virtual applications, using which you can access applications running in a Virtual Machine (VM) seamlessly from Windows® 7 host Start menu. These applications get added to the host start menu automatically upon installing inside the VM using a feature called Auto Publish.

Preparing a VM for Auto Publish

For a Windows based VM (XP SP3 and higher versions), you need to install “Update for Windows® XP SP3 or above to enable RemoteApp™” or “Update for Windows® Vista SP1 or above to enable RemoteApp™” inside the VM. Windows® XP mode VHD has this package preinstalled. Also, you need to ensure auto-publishing is enabled in the virtual machine settings. Open ‘Virtual Machines’ folder and select the VM à right click à settings à Auto Publish.

Fig. 1.  Enabling Auto Publish using WVPC settings dialog

Publishing an application

By default, applications installed under ‘All users’ profile are auto-published to the Windows 7 host. So, if an application has created its shortcuts in ‘All users’ profile, no action is required from user. There are applications which don’t install for “All users” and get installed for current user only. Follow the steps as below to publish such applications

1. Click on the Start Menu button
2. Right Click on Programs
3. Click open. You'll see the start menu open up as a folder. This is the start menu folder in the user's profile
4. You will see the application folder/shortcut appearing here. Copy that folder/shortcut (Ctrl+C)
5. Right Click on programs again and then Click on "Open All Users"
6. Now paste the above folder/ application shortcut to this folder (“All users” start menu)
7. In a few moments the application will get published to the host start menu

Let’s take an example for publishing command prompt. To publish it simply create a new shortcut to cmd.exe at "C:\Documents and Settings\All Users\Start Menu\Programs" inside the VM. That is all you need to do for publishing the command prompt (Fig 2).

Fig. 2.  Adding a virtual application (cmd.exe) to All User programs folder to Auto Publish it

Using this shortcut, now you can launch any application inside VM as remote app or install new applications.

Controlling publishing

Though auto-publishing works totally automatically, with virtually no user intervention required; there are ways in which publishing can be controlled.

Exclude List

You may want some applications that you install in the guest to not get published to the host Start menu. For this we maintain a list inside the guest registry called the “Exclude List”. This list contains full paths of applications that we do not want to publish to the host start menu. The Exclude List is present in the guest registry at HLKM\Software\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList.

This is illustrated by an example below (Fig 3). For example you install Microsoft Security Essentials (http://www.microsoft.com/security_essentials/ ) to secure your VM. This would publish the anti-virus’s UI to the host start menu which you might not want. You need to add this application to the exclude list. This is illustrated below.

1. Right-click on the Microsoft Security Essentials® shortcut on the Start menu and click on properties

Fig. 3.  Microsoft Security Essentials dialog

2. Retrieve the full path of the application.

Fig 4.  Retrieving the application path for adding it to the Exclude list

3. Add this path to the exclude list (remember to get rid of the quotes) and restart the guest.

Fig 5.  Using Exclude list to prevent a virtual application from getting Auto published

4. Consequently you may want some application which is present in the All-User’s start menu but did not get published. These are windows default application which we have excluded by default. For that just delete the entry of that application from the exclude list and restart the guest. For example for publishing the XP MSPaint.exe to Windows 7 start menu, just delete the mspaint.exe entry from the exclude list.

5. Restart the Virtual Machine.

Manual publishing

Another way you can control the applications that get published to the host Start menu is through manual publishing. Here, the user disables auto-publishing and takes total control of what gets published to the host start menu. This is very useful for IT-Administrators who want to restrict applications that get published, irrespective of the number of applications that the user installs inside the guest.

Steps to manually publish the applications

Applications that get published to the host Start menu have an entry in the guest registry which is managed by the WMI class Win32_TSPublishedApplication. Scripting can be used to manipulate this WMI class to manually publish and unpublish application. This is illustrated below.

1. Shutdown the VM. Disable the Auto Publishing setting and then restart the VM.
2. Log in to the virtual machine as an administrator.
3. Install the application
4. Save the following VBScript to a .vbs file and execute it.
5. Do remember to replace the “App Name” with the name of the application and “App Path” with the full application path.
6. If you run it on a Vista on Windows 7 Virtual Machine, then run in on an elevated command prompt.

   1: '******************************************************

   2: 'Declare the variables to be used in the script

   3: '******************************************************

   4: strComputer = "."

   5: strNamespace = "\root\cimv2\TerminalServices"

   6: 'Replace "App Name" with the application Name.

   7: appName = "App Name"

   8: 'Replace "App Path" with the full application path.

   9: appPath = " App Path" 

  10: '*******************************************************

  11: 'Create a unique ID for the app entry in the allow list.

  12: '*******************************************************

  13:  

  14: set x = createobject("Scriptlet.TypeLib")

  15: strNewGuid=Mid(x.GUID,2,8)

  16:  

  17: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

  18: Set objSWbemObject = objSWbemServices.Get("Win32_TSPublishedApplication")

  19: Set objNewSWbemObject = objSWbemObject.SpawnInstance_()

  20:  

  21: '***************************************************************************************

  22: 'Set the various properties for the application to be added 

  23: '***************************************************************************************

  24:  

  25: objNewSWbemObject.Properties_.Item("Name") = appName  

  26: objNewSWbemObject.Properties_.Item("Alias") = strNewGuid

  27: objNewSWbemObject.Properties_.Item("Path") = appPath

  28: objNewSWbemObject.Properties_.Item("PathExists") = "true"

  29: objNewSWbemObject.Properties_.Item("CommandLineSetting") = "1"

  30: objNewSWbemObject.Properties_.Item("RequiredCommandLine") = ""

  31: objNewSWbemObject.Properties_.Item("IconIndex") = "0"

  32: objNewSWbemObject.Properties_.Item("IconPath") = appPath

  33: objNewSWbemObject.Properties_.Item("VPath") = appPath

  34: objNewSWbemObject.Properties_.Item("ShowInPortal") = "0"

  35:  

  36: '*******************************************

  37: 'Add the application entry 

  38: '*******************************************

  39: objNewSWbemObject.Put_

    7. Restart the guest.

Note: - This is an indicative script and you might have to customize it according to your requirements. E.g., if the icon is not present in the executable file itself but is part of some other file, then that file path needs to be provided for the value of “IconPath”. Details of the various fields can be found at http://msdn.microsoft.com/en-us/library/bb736365(VS.85).aspx .

Steps to manually unpublish the applications

Similarly, you can manually unpublish an application using the following script.

   1: '******************************************************

   2: 'Declare the variables to be used in the script

   3: '******************************************************

   4: strComputer = "."

   5: strNamespace = "\root\cimv2\TerminalServices"

   6: 'Replace "App Name" with the application Name.

   7: appName = "App Name"

   8:  

   9: strQuery = "Select * From Win32_TSPublishedApplication  WHERE Name='" & appName & "'"

  10: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

  11:  

  12: Set colItems = objSWbemServices.ExecQuery _

  13:     (strQuery)

  14: For Each objItem in ColItems

  15:         objItem.Delete_

  16: Next

To remove all the virtual applications, use the modified script below:

   1: '******************************************************

   2: 'Declare the variables to be used in the script

   3: '******************************************************

   4: strComputer = "."

   5: strNamespace = "\root\cimv2\TerminalServices"

   6:  

   7: strQuery = "Select * From Win32_TSPublishedApplication"

   8: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)

   9:  

  10: Set colItems = objSWbemServices.ExecQuery _

  11:     (strQuery)

  12: For Each objItem in ColItems

  13:         objItem.Delete_

  14: Next

Another way to do the same is through WMI management tools like wbemtest.exe or WMI Administrator tools (http://www.microsoft.com/downloads/details.aspx?familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314&displaylang=en ).

Using these tools, you can list the instances of the class Win32_TSPublishedApplication in the namespace root\cimv2\TerminalServices and then delete one or more of the instances to manually unpublish those applications. This is illustrated here http://technet.microsoft.com/en-us/library/cc738926(WS.10).aspx

Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Palash Kar

SDE

Microsoft Virtualization Team

Tip: How do I Shut Down a Virtual Machine?

There are times when you may want to shut down a Windows® operating system on a Virtual Machine (VM) created using Windows Virtual PC (WVPC). In Windows® XP Mode, by default, the VM gets hibernated upon closing the VM’s window. There are various ways to shut down Windows on the VM:

Use Windows functionality (Recommended)

1. On the VM Windows’s toolbar, click Ctrl+Alt+Del menu item.  Alternatively, you can also press the Ctrl+Alt+End key combination on your keyboard.

Figure 1:  Using Ctrl+Alt+Del for the VM as a toolbar menu item

2.  This opens the Windows Security window inside the VM. Click on the Shut Down button.

Figure 2:  Shutting down the VM using the familiar Windows Security dialog options 

3. On the new window, choose the Shut Down option from the drop down.

Figure 3:  Shutting down the VM

Use Windows Virtual PC functionality

1. On the VM Windows’s toolbar, click Tools menu item, and click Settings in the drop down menu.

Figure 4:  Using the Windows Virtual PC Settings option to shutdown a VM

2. This opens the VM’s settings window. On the left navigation pane, click on “Close” option.

Figure 5:  Using the ‘Close’ option in Windows Virtual PC Settings

3. Choose the “Prompt for action” option, and then click “OK”.  Whenever you close the VM’s window, you will be prompted to choose which action to take. You can choose to shut down the virtual machine.

Figure 6.  Setting to automatically shutdown a VM every time the VM window is closed

4. Alternatively, If you want to shut down the VM each time you close the VM’s window, then choose the Shut Down option from the drop down menu under the “Automatically close with following action:" option. If you select this option, the VM will shut down each time you close the VM’s window.

Note: This is not a recommended option as it would result in the VM having to boot up from a shutdown stage whenever you launch the VM, or any virtual application for this VM. This significantly increases start up time for the VM or the virtual application.

Rahul Razdan

Program Manager

Microsoft Virtualization Team

Using Smart Cards in Windows Virtual PC

Smart cards are routinely used in many organizations for login, digital signing, encrypting data or even accessing some applications. A key reason why you may need to use a smartcard reader in a Virtual Machine (VM) on Windows® 7 is application compatibility. For example, if you have a web-based application which requires Internet Explorer® 6, you may use it in Windows XP Mode and login to that application using a smartcard reader. You can use smartcards in any VM created using Windows Virtual PC (WVPC) on Windows 7, just as you use smartcards on Windows 7. There are many types of USB smartcards in use, made by different vendors. Each such device comes with its own device driver software, which needs to be installed in the OS on which the smartcard reader is being used. Smart Cards can be shared between the host OS (Windows 7) and the VM, or can be assigned exclusively to VMs. In this article, we will go over the use of smartcards in WVPC.

Assigning Smart Cards to the VM

Smart cards are shared between the host and the VM by default when Integration Features (IFs) are installed in the VM. You can disable this setting by unchecking the ‘Smartcards’ check-box in the Settings of the VM under ‘Integration features’ as below (Figure 1). Then, the smartcard cannot be used in the VM until the setting is enabled again.

Figure 1:  Settings for Smart Card Sharing

In Integration Features enabled mode of WVPC, Microsoft’s Remote desktops Protocol (RDP) is used to share the devices between the VM and Windows 7 host, as explained in an earlier article. RDP does not allow the use of a smart card when explicitly assigned to the Virtual Machine. Further details about this can be found in http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-9638-07625fe397b9&displaylang=en. Accordingly, the option to assign a smart card is disabled in USB Toolbar or Manage USB Devices as shown below (Fig. 2).

Figure 2:  Smart Card Sharing is disabled in Integration Features enabled mode

USB Smart card readers can be exclusively assigned to a Virtual machine in IF disabled mode only. Smart cards drivers need to be installed in Windows 7 as well as the Virtual machine to get smart cards working in shared mode. To install smart card drivers or to assign a smartcard exclusively to the VM, user needs to follow the below steps:

1. Disable Integration Features (IF) by going to Virtual Machine Toolbar and then selecting Disable Integration features under Tools option as shown below (Fig. 3):

Figure 3:  Disabling Integration Features

    2. Assign the smart card to the VM using USB menu present in the VM toolbar (Fig. 4):

Figure 4:  Assigning USB Smart Card Reader in Integration Features Disabled Mode

   3. Install the required drivers in the VM. For example, go to Device Manager, select the device and use “Update Driver Software” and then provide the required drivers.

   4. Release the device using USB menu same as above in Step 2.

   5. Enable IFs again using the toolbar and then use the smart card.

Smart Card Scenarios:

Two common scenarios requiring the use of a smart card in an organization are login to a VM and connecting to an office network from a VM.

Using Smart card for login to a VM

In an organization where users are required to login to a VM, they can join the VM to the domain and use smart cards to login. During the VM startup, when the user is prompted to enter user credentials, they can enter smart card credentials (Figure 5).

Figure 5: Credential UI prompt

On providing their credentials, user needs to re-enter the same in Windows XP Mode VM as below (Figure 6).

Figure 6: Re-Enter PIN in the Virtual Machine

When the user is logging in to Windows XP Mode, s/he is actually establishing a ‘remote’ session between the Windows 7 ‘client’ and the ‘Windows XP Mode’ RDP ‘server’, as explained in an earlier blog. The second prompt is required to authenticate the RDP session. Smart card credentials are secure and hence cannot be saved for subsequent logins. As such, the user needs to provide smart card credentials each time he/she logs on to the VM.

Logging in to a virtual application running in Windows XP Mode works the same way as above, when you launch a virtual application which requires authentication using a smartcard.

Secure Mode Login

Windows 7 provides an option to enable secure mode login for the machines. The advantage of this policy setting is that it requires the user to enter Microsoft Windows credentials using a trusted path, to prevent a Trojan horse or other types of malicious code from stealing the user’s Windows credentials. WVPC uses this setting to honor the same when the users log on to a VM as well. The Credential UI prompt (shown in Fig. 1) is not shown when this setting is enabled. To enable this setting, open ‘Group Policy editor’ in Windows 7. The setting (Figure 7) is called “Require trusted path for credential entry” present in the Local Group Policy editor under Computer Configuration -> Administrative Templates -> Windows Components -> Credential User Interface.

Figure 7:  Group Policy option for Secure Mode Login

Enabling this setting will ask for the Credentials inside the VM login screen only. Also, the setting is applied across all the VMs on the machine and the remote desktop connection to any other machine as well.

Login in Offline Scenario

Please note that this section is relevant only if you create your own VM with your own copy of an Operating System other than Windows XP®.

In offline scenarios, such as working from home or a remote location without network connectivity, a domain controller (server) to authenticate the credentials is not available because the user cannot access the Corpnet. In such cases, smart card credentials are stored in local cache of Windows Vista or Windows 7, if the machine was used at least once prior to the offline (remote) use. If not, the user cannot login using a smart card. To login to a Windows Vista or Windows 7 VM in such scenarios, either the secure mode needs to be enabled (as above) or the user needs to enable a VMC setting tag (Do_Not_Prompt_Creds) for the VM as shown below. Enabling this setting will bypass Credentials UI prompt and directly take the user to the VM login screen.

The setting is present under the ui_options within the virtual machine configuration file (.vmc file, which can be found under %LocalAppData%l\Microsoft\Windows Virtual PC\Virtual Machines\), as a boolean value. Setting it to ‘true’ will enable the setting, as below:

<ui_options>
        <do_not_prompt_creds type="boolean">true</do_not_prompt_creds>
</ui_options>

This setting is not created by default and there is no direct User Interface to set it. The user needs to make a COM call to enable/disable this setting, as below. This is a per VM setting, which means it needs to be set in every VM separately. Please note that a VM running Windows XP as the guest OS, such as the Windows XP Mode, does not have this issue, by design.

An example script to enable this setting is shown below:

' Get the VPC Object
Set objVPC = CreateObject("VirtualPC.Application")

' Get the Virtual Machine Object
' Change the Name as appropriate
Set objVM = objVPC.FindVirtualMachine("VMNAME")

' Enable the setting
objVM.SetConfigurationValue "ui_options/do_not_prompt_creds", true

Similarly, another example script to disable this setting is shown below:

' Get the VPC Object
Set objVPC = CreateObject("VirtualPC.Application")

' Get the Virtual Machine Object
' Change the Name as appropriate
Set objVM = objVPC.FindVirtualMachine("VMNAME")

' Disable the setting
objVM.SetConfigurationValue "ui_options/do_not_prompt_creds", false

Hot fixes for Using Smart Card in a VM

Base Smart Card Cryptographic Service Provider (Base CSP) allows smart card vendors to more easily enable their smart cards on Windows with a lightweight proprietary card module instead of a full proprietary CSP. The user sees a warning message if it is not installed in some scenarios as shown below (Figure 8):

Figure 8:  Smart Card Error

To overcome this, install the base CSP applicable for Windows XP from http://www.microsoft.com/downloads/details.aspx?FamilyID=e8095fd5-c7e5-4bee-9577-2ea6b45b41c6&displaylang=en

Conclusion

Using smart cards with VMs can be done by just making sure that appropriate drivers-hotfixes are installed in the Virtual Machine. Smartcards can be used for login to the VM or virtual applications in Windows XP Mode, and VPN access to the corporate network. We hope this information is useful to you.  Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Rahul Rajwanshi

SDET

Microsoft Virtualization Team

Use ClearType® to ‘clearly see’ how to make more money

ClearType delivers improved font display quality over traditional forms of font smoothing or anti-aliasing. ClearType improves readability on color LCD displays with a digital interface, such as those in laptops and high-quality flat panel displays. Readability on CRT screens can also be somewhat improved.

To make sure that text displayed within Windows® XP Mode applications looks sharp (Figure 1), you need to enable ClearType:

Figure 1.  Fonts displayed in a ClearType enabled virtual application (Right) are sharper

ClearType can be enabled in Windows XP Mode by following the below steps:

1. Start Windows XP Mode (From the Windows 7 Start menu, click Windows Virtual PC, and then click on Windows XP Mode)
2. On Windows XP Mode desktop click Start, click Control Panel, click Appearance and Themes, and then click Display.
3. On the Appearance tab, click Effects.
4. Click to select the Use the following method to smooth edges of screen fonts check box, and then click ClearType in the list.

Before enabling ClearType, I used to get a headache while reading emails (using Outlook® 2007 running in Windows XP Mode) from my manager, colleagues & wife. After enabling ClearType, I don’t get headaches any more, while reading emails from my manager and colleagues. Ahem!!! 

Check out Windows XP Mode RTM Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Akash Maheshwari

Program Manager

Microsoft Virtualization Team

Using a Host Guest communication channel in Windows Virtual PC

Host Guest Communication 

In Windows^® Virtual PC (WVPC), the virtual machine (guest) and the Windows 7 host need to communicate with each other for sharing data, devices and functionality, such as clipboard sharing, printer sharing, file system and drive sharing, Start menu integration and file association with virtual apps. Such communication is also necessary for displaying the video of the VM on the Windows 7 desktop. In this article, we will discuss in detail how such a guest host communication channel is designed and implemented in WVPC and how you can leverage it to add additional functionality. The communication mechanism is modeled as typical client server architecture with the Windows 7 host acting as the client and the VM acting as the server.

Applications can make use of this feature to start a communication channel and transfer data between the host and guest. The communication channel enables a named pipe client application on the host to exchange data with a TCP server application running in the guest. It is generic and can be used by third-party applications, using its COM APIs which are scriptable. Here are some example applications you could build:

• An application running in the virtual machine could monitor various parameters such as anti-virus status, low disk space, etc. and it can then communicate the status to an application running on the host using its own protocol developed over the communication channel.
• Consider a file created in a virtual application running in a VM, which needs to be printed on a printer connected only to the host. A printer application can be developed to redirect the print command issued in the VM to the host and complete the printing, using the guest-host communication channel.
• An application could be developed to execute a command line tool or script entered on the host command line interface to be redirected to the guest and executed there.

WVPC itself leverages RDP technology from Microsoft Remote Desktop Services^® (RDS; formerly Terminal Services) on top of this guest-host communication channel, to show the guest video on the host. When Integration Features are enabled, or a virtual application is started, a TS session is started from host to guest. Traditionally, TS sessions use the network as a communication channel between a client and server. In contrast, since the VM and the host are running on the same hardware, the TS session initiated by WVPC does not require any network connection, but is established using the guest – host communication channel.

Host Guest Communication Channel Architecture

Overall the architecture of host-guest communication channel is shown in Figure 1.

Figure 1. Architectural overview of Host-Guest Communication Channel

In the above diagram, green boxes are application specific, and blue boxes illustrate the host-guest communication protocol implemented in WVPC. To initiate communication, a TS session is established by VMWindow.exe, a component of WVPC, which acts as a named pipe client, with TS server running inside the VM acts as the TCP server. Typically, an application on the host makes a COM call (StartCommunicationChannel) to setup the channel. And then, applications can communicate with the TCP server that is already set up in the guest. StartCommunication COM call starts a named pipe server on the guest and application’s named pipe client can send data to and receive data from this named pipe server. This server is hosted by WVPC Host Process (vpc.exe). On the guest side, a TCP client is established which communicates to the TCP server which is assumed to be up and running when the COM call is made. The TCP client is hosted by Virtual Machine Guest Service (vmsrvc.exe). Under the hood, the named pipe server on the host (vpc.exe) and TCP client on the guest (vmsrvc.exe) communicate with each other using VPCBus. VPCBus is a new integral component of WVPC which provides the communication infrastructure between the WVPC (Virtual PC host process) and the guest VM. The VPCBus achieves this internally by introducing new synthetic devices inside guest VM. These synthetic devices act as communication channels.

As explained in a previous blog, Integration Components need to be installed in the guest to make use of the communication mechanism. Usage of the new communication mechanism is shown in Figure 2:

Figure 2. Usage of the WVPC Guest Host Communication Channel

The entire communication between guest and host happens over VPCBus. For every communication channel established, two VPCBus channels are opened between host and guest. When integration components are enabled, you can see these VPCBus channels in guest device management. These devices come under “Other devices” category and are named “Virtual PC Integration Device”. These are the devices used by WVPC for performing a TS session inside the guest (Fig. 3).

Figure 3. Guest Host Communication Channel components shown in the Device Manager

Named pipe client in the Host

The typical sequence of actions for an application using the communication  channel is as follows:

1. TCP Server starts in the guest and waits for connection over predefined port number and on LocalHost IP(127.0.0.1). The server can be started manually or be configured to run automatically when guest starts.
2. The Client application starts and gets interface handle for the VM in which TCP server is running.
3. The client VM opens a named event and waits for it to be signaled. The event name is in predefined format "Local\<ChassisTag>_ChannelReady. The chasis Tag for a VM can be found using IVM interface property ChassisAssetTag.
4. When the event gets signaled the client requests the WVPC (Virtual PC host process) to start Named pipe server and establish connection with TCP server in guest. This is done using “StartCommunicationChannel” API. As part of this API client passes the name of Named pipe to be used and the port number on which TCP server is listening.
5. WVPC establishes the VPCBus channels with guest. This results in Guest VPCBus component initiating connection with the TCP Server.
6. TCP Server accepts connection and waits for Data from client.
7. The client then connects to the named pipe using standard Win32 File APIs and starts exchanging data using Read/Write APIs.

With this sequence, host and guest can communicate with each other for the given purpose. For the illustration, let’s take a look at sample named pipe client on the host side which sends “Hello World” to message to guest.

   1: LPCWSTR VMNAME = L"Windows XP Mode";

   2: LPCWSTR PIPE_NAME = L"\\\\.\\pipe\\mynamedpipe";

   3: LPCWSTR PORT_NUMBER = L"6174";

   4:  

   5: int __cdecl main(int , char* )

   6: {

   7:     IVMVirtualMachine* vmObj = NULL;

   8:     IVMVirtualPC* pIVPC = NULL;

   9:     HRESULT hr = S_OK;

  10:     BSTR bName = NULL;

  11:     BSTR bPipeName = NULL;

  12:     BSTR bPortNumber = NULL;

  13:     HANDLE hPipe = INVALID_HANDLE_VALUE;

  14:     WCHAR pszWriteThis[] = L"Hello World!";

  15:     DWORD bytesWritten = 0;

  16:  

  17:     //

  18:     // Initialize VPC COM interfaces.

  19:     //

  20:  

  21:     hr = InitVPCComInterfaces(&pIVPC);

  22:     if (FAILED(hr)) {

  23:         goto Cleanup;

  24:     }

  25:  

  26:     //

  27:     // Find the VM on which communication is to be done.

  28:     //

  29:  

  30:     bName = SysAllocString(VMNAME);

  31:     if (bName == NULL) {

  32:         hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);

  33:         goto Cleanup;

  34:     }

  35:  

  36:     hr = pIVPC->FindVirtualMachine(bName, &vmObj);

  37:     if (hr != S_OK) {

  38:         goto Cleanup;

  39:     }

  40:  

  41:     //

  42:     // Need to wait for the communication channel infrastructure to be up

  43:     // before it is put to use. VM needs to be up and running before

  44:     // channel gets ready.

  45:     //

  46:  

  47:     hr = WaitForChannelReady(vmObj);

  48:     if (FAILED(hr)) {

  49:         goto Cleanup;

  50:     }

  51:  

  52:     bPipeName = SysAllocString(PIPE_NAME);

  53:     bPortNumber = SysAllocString(PORT_NUMBER);

  54:     if (bPipeName == NULL || bPortNumber == NULL) {

  55:         hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);

  56:         goto Cleanup;

  57:     }

  58:  

  59:     //

  60:     // Set up the communication channel to be used by host and guest.

  61:     //

  62:  

  63:     hr = vmObj->StartCommunicationChannel(vmEndpoint_NamedPipe,

  64:                                           bPipeName,

  65:                                           vmEndpoint_TCPIP,

  66:                                           bPortNumber);

  67:     if (FAILED(hr)) {

  68:         goto Cleanup;

  69:     }

  70:  

  71:     //

  72:     // Now communication channel is set up and data transfer can be initiated.

  73:     //

  74:  

  75:     hPipe = CreateFile(PIPE_NAME,

  76:                        GENERIC_READ |

  77:                        GENERIC_WRITE,

  78:                        0,

  79:                        NULL,

  80:                        OPEN_EXISTING,

  81:                        0,

  82:                        NULL);

  83:  

  84:     if (hPipe == INVALID_HANDLE_VALUE) {

  85:         goto Cleanup;

  86:     }

  87:  

  88:     wprintf(L"Sending '%s' to guest.\n", pszWriteThis);

  89:  

  90:     if (WriteFile(hPipe,

  91:                   pszWriteThis,

  92:                   sizeof(pszWriteThis),

  93:                   &bytesWritten,

  94:                   NULL) == FALSE) {

  95:         goto Cleanup;

  96:     }

  97:  

  98: Cleanup:

  99:  

 100:     SAFE_RELEASE(pIVPC);

 101:     SAFE_RELEASE(vmObj);

 102:     SAFE_FREE(bName);

 103:     SAFE_FREE(bPipeName);

 104:     SAFE_FREE(bPortNumber);

 105:     if (hPipe != INVALID_HANDLE_VALUE) {

 106:         CloseHandle(hPipe);

 107:     }

 108:  

 109:     return 1;

 110: }

 111: HRESULT

 112: InitVPCComInterfaces(

 113:     IVMVirtualPC** ppIVPC

 114:     )

 115: {

 116:     HRESULT hr = S_OK;

 117:     if (ppIVPC == NULL) {

 118:         return E_INVALIDARG;

 119:     }

 120:  

 121:     *ppIVPC = NULL;

 122:     hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);

 123:     if (FAILED(hr)) {

 124:         return hr;

 125:     }

 126:  

 127:     REFCLSID classID = _uuidof(VMVirtualPC);

 128:  

 129:     hr = CoCreateInstance(classID, 

 130:                           NULL, 

 131:                           CLSCTX_ALL, 

 132:                           IID_IVMVirtualPC, 

 133:                           (LPVOID*)ppIVPC);

 134:  

 135:     // test connection

 136:     if (SUCCEEDED(hr) && (*ppIVPC != NULL)) {

 137:         // Make a call to the interface and see if it works.

 138:         BSTR bVer;

 139:         hr = (*ppIVPC)->get_Version(&bVer);

 140:         ::SysFreeString(bVer);

 141:     }

 142:  

 143:     return hr;

 144: }

 145:  

The application begins by getting the interface handle to the virtual machine (line 36) on which the communication is to be done. The VM needs to be running before the StartCommuincationChannel COM call is made. Also, after VM starts execution, it takes time for communication mechanism to be up as it has to wait for the Virtual PC Integration Components Service (service name: 1-vmsrvc) to be started in the guest. Applications can determine when the channel is ready by calling WaitForChannelReady() function (described in detail later).

StartCommunicationChannel takes four arguments – two are end-point types (VMEndpointType), the name with which the named pipe server will be started in the Virtual PC Host Process (\\.\pipe\mynamedpipe in the sample) on the host and the port number on which the TCP server is running ins the guest.

StartCommunicationChannel call (line 63) results in the requested named pipe server starting up in the Virtual PC Host Process (vpc.exe). This can be viewed using Process Explorer as in the screenshot below (Figure 4).

Figure 4. Named pipe server starting up in the Virtual PC Host Process (vpc.exe)

The application then continues to connect (line 75) to the named pipe server it requested and writes out the byte stream (line 90) to be sent to the guest. Behind the scenes, the Virtual PC Host Process will transfer this data over to the Virtual PC Guest Service running in the guest. The guest service acts as a TCP client connecting to the TCP server in the guest and sends the data to it. You can see using TCPView the Virtual PC guest service (vmsrvc.exe) connected to the sample application TCP Server on port 6174 as shown in the screenshot below (Figure 5).

Figure 5. VPC guest service (vmsrvc.exe) connected to the sample TCP Server on port 6174

Host application then disconnects from the named pipe server (line 106). Disconnecting from the named pipe server also causes Virtual PC Host Process to stop this server instance.

Waiting for the Communication Mechanism

Virtual PC Host Process fires a well-known named event to indicate that the communication channel for a virtual machine is ready to be used. The event name is of the format “<vm_chassis_tag>_ChannelReady”. Applications can wait for this event in order to be certain that communication mechanism is up. Below is one way of implementing the wait routine. If StartCommunicationChannel COM call is made before this event is set the call fails with ERROR_NOT_READY.  

   1: HRESULT WaitForChannelReady(IVMVirtualMachine* vmObj)

   2: {

   3:     HRESULT hr = S_OK;

   4:     BSTR bChassisAssetTag = SysAllocStringByteLen(NULL, MAX_PATH);

   5:     WCHAR ChannelReadyEventName[MAX_PATH] = {0};

   6:     HANDLE hEvent = NULL;

   7:  

   8:     //

   9:     // Build the well known name for the named event. Format is:

  10:     // "Local\<ChassisTag>_ChannelReady"

  11:     //

  12:  

  13:     hr = vmObj->get_ChassisAssetTag(&bChassisAssetTag);

  14:     if (hr != S_OK) {

  15:         goto Cleanup;

  16:     }

  17:  

  18:     hr = StringCchCopy(ChannelReadyEventName, MAX_PATH, L"Local\\");

  19:     if (FAILED(hr)) {

  20:         goto Cleanup;

  21:     }

  22:  

  23:     hr = StringCchCat(ChannelReadyEventName, MAX_PATH, bChassisAssetTag);

  24:     if (FAILED(hr)) {

  25:         goto Cleanup;

  26:     }

  27:  

  28:     hr = StringCchCat(ChannelReadyEventName, MAX_PATH, L"_ChannelReady");

  29:     if (FAILED(hr)) {

  30:         goto Cleanup;

  31:     }

  32:  

  33:     hEvent = CreateEvent(NULL, TRUE, FALSE, ChannelReadyEventName);

  34:     if(hEvent == NULL) {

  35:         hr = HRESULT_FROM_WIN32(GetLastError());

  36:         goto Cleanup;

  37:     }

  38:  

  39:     if (WaitForSingleObject(hEvent, INFINITE) == WAIT_FAILED) {

  40:         hr = HRESULT_FROM_WIN32(GetLastError());

  41:         goto Cleanup;

  42:     }

  43:  

  44: Cleanup:

  45:  

  46:     if (hEvent != NULL) {

  47:         CloseHandle(hEvent);

  48:     }

  49:  

  50:     return hr;

  51: }

Sample TCP Server in Guest

The sample TCP Server below prints the data it receives from the host application on the console. The code for the server below is fairly typical and adapted from http://msdn.microsoft.com/en-us/library/ms737593(VS.85).aspx

   1: #include <windows.h>

   2: #include <winsock2.h>

   3: #include <ws2tcpip.h>

   4: #include <stdlib.h>

   5: #include <stdio.h>

   6:  

   7: // Need to link with Ws2_32.lib, Mswsock.lib, and Advapi32.lib

   8: #define DEFAULT_BUFLEN 512

   9: #define DEFAULT_PORT "6174"

  10:  

  11: int __cdecl main(void) 

  12: {

  13:     WSADATA wsaData;

  14:     SOCKET ListenSocket = INVALID_SOCKET,

  15:            ClientSocket = INVALID_SOCKET;

  16:     struct addrinfo *result = NULL,

  17:                     hints = {0};

  18:     CHAR recvbuf[DEFAULT_BUFLEN] = {0};

  19:     int iResult = 0;

  20:     int recvbuflen = DEFAULT_BUFLEN;

  21:  

  22:     // Initialize Winsock

  23:     iResult = WSAStartup(MAKEWORD(2,2), &wsaData);

  24:     if (iResult != 0) {

  25:         wprintf(L"WSAStartup failed: %d\n", iResult);

  26:         return 1;

  27:     }

  28:  

  29:     ZeroMemory(&hints, sizeof(hints));

  30:     hints.ai_family = AF_INET;

  31:     hints.ai_socktype = SOCK_STREAM;

  32:     hints.ai_protocol = IPPROTO_TCP;

  33:     hints.ai_flags = AI_PASSIVE;

  34:  

  35:     // Resolve the server address and port

  36:     iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);

  37:     if ( iResult != 0 ) {

  38:         wprintf(L"getaddrinfo failed: %d\n", iResult);

  39:         WSACleanup();

  40:         return 1;

  41:     }

  42:  

  43:     // Create a SOCKET for connecting to server

  44:     ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);

  45:     if (ListenSocket == INVALID_SOCKET) {

  46:         wprintf(L"socket failed: %ld\n", WSAGetLastError());

  47:         freeaddrinfo(result);

  48:         WSACleanup();

  49:         return 1;

  50:     }

  51:  

  52:     // Setup the TCP listening socket

  53:     iResult = bind( ListenSocket, result->ai_addr, (int)result->ai_addrlen);

  54:     if (iResult == SOCKET_ERROR) {

  55:         wprintf(L"bind failed: %d\n", WSAGetLastError());

  56:         freeaddrinfo(result);

  57:         closesocket(ListenSocket);

  58:         WSACleanup();

  59:         return 1;

  60:     }

  61:  

  62:     freeaddrinfo(result);

  63:  

  64:     wprintf(L"Waiting for message from host...\n");

  65:  

  66:     iResult = listen(ListenSocket, SOMAXCONN);

  67:     if (iResult == SOCKET_ERROR) {

  68:         wprintf(L"listen failed: %d\n", WSAGetLastError());

  69:         closesocket(ListenSocket);

  70:         WSACleanup();

  71:         return 1;

  72:     }

  73:  

  74:     // Accept a client socket

  75:     ClientSocket = accept(ListenSocket, NULL, NULL);

  76:     if (ClientSocket == INVALID_SOCKET) {

  77:         wprintf(L"accept failed: %d\n", WSAGetLastError());

  78:         closesocket(ListenSocket);

  79:         WSACleanup();

  80:         return 1;

  81:     }

  82:  

  83:     // No longer need server socket

  84:     closesocket(ListenSocket);

  85:  

  86:     iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);

  87:     if (iResult > 0) {

  88:         wprintf(L"Bytes received: %d\n", iResult);

  89:         wprintf(L"Message received from host is '%s'\n", recvbuf);

  90:     }

  91:     else if (iResult == 0)

  92:         wprintf(L"Connection closing...\n");

  93:     else  {

  94:         wprintf(L"recv failed: %d\n", WSAGetLastError());

  95:         closesocket(ClientSocket);

  96:         WSACleanup();

  97:         return 1;

  98:     }

  99:  

 100:  

 101:     // shutdown the connection since we're done

 102:     iResult = shutdown(ClientSocket, SD_SEND);

 103:     if (iResult == SOCKET_ERROR) {

 104:         wprintf(L"shutdown failed: %d\n", WSAGetLastError());

 105:         closesocket(ClientSocket);

 106:         WSACleanup();

 107:         return 1;

 108:     }

 109:  

 110:     // cleanup

 111:     closesocket(ClientSocket);

 112:     WSACleanup();

 113:  

 114:     return 0;

 115: }

StartCommunicationChannel and Event Logging

To help debug situations around host-guest communication mechanism, WVPC logs events in the event log. Here is an entry for a failure case:

Figure 6. Example Event Log for a Guest Host Communication Failure Case

Conclusion

Guest-Host communication in WVPC is built as a fast, efficient and extensible client-server style communication mechanism. Further, WVPC has leveraged RDP technology on top of this channel, to enable efficient graphics rendering, drive sharing, seamless virtual applications and other guest-host integration features such as clipboard sharing. Its proximity to the client server architecture and usage of named pipe and TCP interfaces will help enable several communication scenarios between host and guest. With the help of the sample applications presented above, we hope that you can build your own applications making use of the Host-Guest communication mechanism provided in Windows Virtual PC.  Check out WVPC and Windows XP Mode today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Yadnyesh Joshi and Gaurav Sinha

Software Development Engineers

Microsoft Virtualization Team

Networking and Using Windows XP Mode

First Time Use of Windows XP Mode

Windows® XP Mode is a Virtual Machine (VM) created by Windows Virtual PC on Windows 7 host. Just as with any new PC you acquire, you would want to connect it to the network, maintain it securely, connect and use USB devices such as printers, storage devices and smartcards. When you launch the Windows XP Mode VM from Windows 7® Start menu for the first time after setup, you will notice that the VM is already connected to the network and is ready to use:

• You can domain join the VM same way you would join a physical Windows XP host to a domain.
• You can install applications which require network connection, such as Internet Explorer for example, and use them right away, both in a full VM and as virtual applications.
• Similarly, you can easily attach USB devices to the VM and use them.
• Maintenance of a Windows XP Mode VM which is connected to the network is similar to maintaining a physical Windows XP desktop, using Windows Updates.

In this article, we will look at the usage of these features in more detail.

Networking a Windows XP Mode VM

The default network setting of Windows XP Mode is NAT (Network Address Translation), but you can change it. NAT allows the host machine to act as an agent between the external network (e. g. Corpnet or Internet) and the VMs running on that host. The network will use the host's IP address itself, which represents the group of VMs on that host, to communicate with the VMs. The host can resolve the network packets to the specific VM they are intended for, using port numbers. This is why, the Windows XP Mode VM, using NAT as the default configuration, is ready to connect to the network upon first launch. However, note that the network communication has to be initiated first by the NAT configured VM. In VM settings in Windows XP Mode (Fig. 1), you can specify up to four emulated network adapter options, which can be assigned to any network card installed on the physical computer.

To change this configuration, the Settings dialog box shown in Fig. 1 can be accessed using ‘Settings’ option under ‘Tools’ element from the VM Window’s toolbar. When you click on the ‘Networking’ setting, you will find the following four options to choose from:

1. Shared Networking (NAT) option shown in Figure 1 (Left) refers to a virtual NAT (Network Address Translation) which allows the VM to leverage the external TCP/IP network connected to the host. This is very useful if you regularly move the host computer between different network configurations. NAT is the preferred networking option when there is a shortage of IP addresses, a need to ensure the VM’s IP address is not targetable from an external network, or a need for connecting using WWAN.
2. In contrast, Bridge mode uses the network adapter on the host. This option appears in the drop down menu as the name of the adapter. In Figure 1 (Right), it is shown as Intel® 82566DM-2 Gigabit Network Connection under Adapter 1. The VM is connected directly to the selected network connection of the Windows 7 host, and will behave like a separate physical computer on the same network. If the host has a wireless adapter, its name will appear in the dropdown list. In Bridge mode, Virtual Machine Network Services driver helps redirect the incoming network traffic to the correct VM and associate the correct MAC address in all outbound network traffic. In scenarios using VPN, Bridge mode is the preferred option.
3. Choosing the option ‘Not connected’ disables the VM’s networking ability and completely isolates it from the network.
4. ‘Internal Network’ option enables networking among only the VMs on the single Windows 7 host.

Figure 1. Settings dialog box to configure a VM’s networking adapters as (a) Shared Networking (NAT) on the Left, or (b) Bridged mode on the Right

Windows Virtual PC (WVPC) emulates up to 4 DEC/Intel 21140A-based Ethernet cards per VM, each with its own unique MAC address. WVPC translates the instructions executed by the Windows XP network driver into network activity. Because the packets are handled as Ethernet packets, WVPC is protocol agnostic and can support protocols other than TCP/IP. All VMs connected to a specific virtual network can access traffic sent from and received by any other VM on that same virtual network.

Maintaining a Windows XP Mode VM

Network connection is necessary to properly patch a Windows XP Mode VM with latest security patches etc. Just as a physical machine with Windows XP OS on the network, the Windows XP Mode VM has the capability to contact the WU (Windows Updates) server, find out the available updates, and install the required ones. You can configure the Windows Updates during the initial setup of Windows XP Mode (Figure 2). It is recommended that Automatic Update option is selected. The VM will get serviced based on the selection (Automatic Updates, Only download, Only Notify, or No updates). This capability should be used to service VM for regular Windows XP updates, which requires that the VM is running and has network connectivity.

Figure 2. Selecting Automatic Update option during Windows XP Mode setup and connecting the VM to network are recommended

If you are running only virtual applications, then any notification from WU (e. g. reboot required, updates downloaded and ready for installation, or updates available) will be relayed to the Windows 7 host machine. You will then be able to take the necessary action, such as closing all virtual applications, opening the Windows XP Mode as a full VM, downloading and installing the updates etc.

Other security best practices, including installing an anti-virus software, are essential to the healthy maintenance of Windows XP Mode VM as well. For example, consider running an application based on Internet Explorer® 6 (IE 6) as a virtual application in Windows XP Mode. In this case, it is necessary to install anti-virus software in the Windows XP Mode VM, to prevent, detect, and remove malware, such as computer viruses, worms, and trojan horses, adware and spyware.

Using USB and other Devices in Windows XP Mode

Printers, flash memory sticks, external hard disks and backup disks, followed by digital cameras and smartcards are USB devices important to business users. In a Windows XP Mode VM, USB devices can be used in two different ways: Sharing and Redirection. In the default mode with all integration features enabled (explained in the previous article), Storage devices, Printers and Smart cards can be used without having to redirect the device manually, by simply sharing it with the host. This requires that the device driver is available both in the Windows XP VM and on the host. If the driver is not available on Windows 7, the device can be redirected to the VM, using these steps (Figure 3A):

1. Plug in the USB device to the system, and click on the USB icon of the virtual machine toolbar. The device is then listed in the drop down menu.
2. Install the device driver inside the VM when prompted, and start using the device in Windows XP Mode.

In the above scenario, clicking on the device name redirects it to the VM. When the device is redirected to the VM, it is available to the VM but not to the host; when the device is released, it becomes available to the host again. Thus, at any point in time, the device is available either to the VM or the host but not both, as shown in Figure 3A. Here, a USB pen drive plugged into the PC is shown (as USB 2.0 in VM Tool Bar under USB option) attached to the VM, and appears as ‘Removable Disk (E:)’ in the VM’s ‘My Computer folder’. Note that this device does not appear in the host’s ‘Computer’ folder (shown to the left) anymore. After selecting the ‘Release’ option for this USB device in the VM Tool Bar, it is not exclusively attached to the VM anymore (Figure 3B), but becomes shared between the host and the VM. In Figure 3B, the same pen drive can be seen shared as drive letter F:\ in the VM, and as a USB device on the host as well. Sharing option is available only for Storage devices, Printers and Smart cards, whereas a variety of USB devices can be used in the VM via Redirection.

Figure 3A. USB Option Menu on the VM Tool Bar showing a USB pen drive exclusively attached to the VM

Figure 3B. USB Option Menu on the VM Tool Bar showing a USB pen drive shared between the VM and the host

Users can also attach USB devices to virtual applications directly from the Windows 7 task bar. This means USB devices, such as printers and flash drives, are available to applications running in Windows XP Mode, without the need to go into a full VM mode. In Figure 4, to attach a USB pen drive to a virtual application (Microsoft Project®), user right clicks on the VM icon on the Windows 7 task bar, and selects the ‘Manage USB Devices’ option, which displays the shared device as ‘USB 2.0’. User can access the necessary data from the USB device from within the virtual application in this manner.

Figure 4. Using a USB device from within a Windows XP Mode virtual application

Windows XP Mode also supports up to two communication ports, for COM port devices. Each of these ports (listed in Settings as COM1 and COM2; Figure 1) can support a physical serial device such as a modem, a named pipe as a means to transmit information using shared memory with another process, or log the output of the specified I/O communication to a text file. Parallel port devices are not supported, as they are relatively rare today.

In Closing…

Using the Networking and USB device features of Windows XP Mode and WVPC is simple. Maintenance of Windows XP Mode VM works the same way as the maintenance of any computer connected on a network. Check out Windows XP Mode RC Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Prasad Saripalli

Principal Program Manager

Microsoft Virtualization Team

Three Modes of Windows XP Mode

Enhanced Mode and Basic Mode

Windows® XP Mode provides seamless integration of the VM (guest) with the Windows 7 host desktop, by means of Integration Components (ICs). ICs are a set of binaries which run inside the VM and communicate directly with the host OS. They enable Integration Features like clipboard sharing, printer sharing, file system and drive sharing, Start menu integration and file association with virtual apps. This allows the user to switch freely between the XP VM and Windows 7 desktops and applications. You can run Windows XP Mode as a full Windows XP desktop in two different ways: Enhanced Mode and Basic Mode. 

1. Enhanced Mode is the default mode in which the Windows XP Mode VM starts. Majority of users will prefer this mode, as it is easy to use and provides the complete set of integration features described above. For example, saved credentials feature is provided in Enhanced Mode, so that users don’t have to login each time they launch Windows XP Mode, whereas this is not available in Basic Mode. Enhanced Mode is implemented using a connection channel based on the Microsoft® Remote Desktop Services RDP protocol. One of the options on the VM Toolbar under Tools is ‘Disable Integration Features’ (Figure 1). Clicking on this option switches the Windows XP VM to Basic Mode.
2. Basic Mode provides basic integration features such as mouse and keyboard integration, USB support, time sync and heartbeat parity between the VM and the host. Integration features such as clipboard sharing, drive sharing and printer redirection are not available in this mode. This mode is useful for power users in software dev/test scenarios, where explicitly displaying the system level settings and BIOS messages as the VM boots up is important.   Apart from these differences, using the Windows XP desktop environment in Basic Mode is similar to using the Enhanced Mode.

Figure 1. Using XP Mode VM Tool Bar to switch between Basic and Enhanced Modes

Virtual Applications: The ‘Invisible’ Third Mode

Virtual Applications Mode is the third mode – a completely seamless solution to application compatibility. This is the most likely and preferable way to launch and run your virtual applications, as they are seamlessly integrated with the Windows 7 desktop and Start menu. When an application is installed in the Windows XP Mode VM, a shortcut is automatically published to the Start menu of Windows 7, as explained in the previous blog. The key features of using virtual applications are:

• Users can launch and run the legacy apps from Windows 7 Start menu and save the files created using virtual apps to their Windows 7 folders (My Documents, for example).
• Files created using such applications have their file association enabled, which means that, clicking the file’s icon shortcut will also launch the required virtual application and open the file.
• Virtual applications’ icons can be integrated with Windows 7 Super bar and the System Tray as well. In Figure 2, Microsoft Forefront™ Security running as a virtual application is shown in System Tray (within a brick red color outline on the Super bar).
• Language bar support is provided for virtual applications. Users can launch a virtual app in their preferred language, and the Language bar would appear on the host desktop (Figure 2), enabling the user to start using the app in the chosen language. You can see the German language bar outlined in a brick red color rectangle in Figure 2, which enabled the use of Internet Explorer® German version as a virtual application.

Figure 2. Language bar use and System tray integration of virtual applications

• Virtual applications running in the VM have the ability to access the host folders such as My Documents.
• Users can also configure the XP Mode VM to access only specified drives on the host.
• A user can simultaneously use multiple virtual applications. They run in the same RemoteApp session started by the first one. As such, opening the second and subsequent applications is very fast.
• Integration features are also available for virtual applications, enabled by the RDP protocol. USB devices can be attached and used from within a virtual application.
• Users can also configure any virtual application to automatically start upon host start-up, by simply adding the virtual application’s published shortcut to the host’s start-up folder.  Microsoft Outlook® shown in Figure 3 would start automatically upon Windows 7 start-up.  Microsoft Excel® installed as a virtual application is shown in Figure 3 (among a number of virtual apps), as a short cut published under Windows XP Mode Applications.  Using this shortcut user can launch the virtual application.

Figure 3. Adding a Virtual App (MS Outlook) to the Windows 7 Startup Folder

Engineering Overview:

Here is an overview of how Virtual Applications work, with a reference to the RemoteApp technology. Diagrams presented below are only a logical abstraction:

• When a legacy application is installed in the VM, it gets added to a list of virtual applications (called the Allow list) whose shortcuts will be published to the Windows 7 Start menu. A Publisher object in the VM retrieves this list of applications from the VM’s Start menu (All user profile). This list changes only when new applications are installed or uninstalled in the VM.
• The VM also maintains another list which should not be auto published (called the Exclude list). This is a static list.
• Windows Remote Desktop Services RDP and RemoteApp technology is adapted to achieve seamless integration of virtual applications with Windows 7. Windows XP Mode VM functions as an RDP remote ‘server’, whereas the Windows 7 desktop serves as the RDP ‘client’ (Figure 4).
• In case of Windows XP Mode, both the Windows XP Mode VM and the Windows 7 desktop co-exist on the same single machine, and are connected to communicate by a guest host communication channel based on RDP (Figure 4; Right). The VM itself is running in the background and is never visible to the user while using virtual applications.
• Application’s GUI from the RemoteApp session is ‘remoted’ and presented to the Windows 7 desktop. Users see and use the virtual application in the same way as they would see a native Windows application. RemoteApp packages the graphics generated in response to user’s keystrokes and mouse clicks and sends them to the Windows 7 desktop where they are displayed.
• Instead of using the RDP file to launch a remote application, user would be clicking on a virtual application of file icon/short cut to launch the virtual application (shown as Excel icon in Figure 4). Vmsal.exe, a WVPC component, mediates the launching of the virtual application. Since there is no actual network involved, this communication is fast and efficient.
• When the user launches a virtual application, Vmsal.exe first starts the XP Mode VM and then establishes a connection to the VM and starts a RemoteApp session. RDP stack components are started in this session. An RDP virtual channel establishes a handshake between the host and the VM. Requests from the host to the VM, initiated via user’s mouse and keyboard inputs, are executed in the VM, similar to how they are executed in case of RemoteApp.
• The RemoteApp logic checks against the allow list and launches the application in the VM.
• Application in the VM creates a window. The window hook notifications are sent to the Windows 7 desktop. A plug-in creates the corresponding proxy window on Windows 7 desktop, and displays the application UI.
• User’s input events are kept forwarded to the VM. When the user closes the virtual application window, the app exits in the VM. The VM is hibernated within 5 minutes after the last virtual application is closed, to conserve host resources. This time is configurable.

Figure 4. Architecture of XP Mode Virtual Applications (Right) compared to RemoteApp Architecture (Left)

In Closing…

There are three ways of using a Windows XP Mode VM. Virtual Apps and Enhanced Mode typically are preferred for business desktops. Windows XP Mode is prepared such that its configuration and setup are easy for the user and IT Admin. Joining the XP Mode VM to a network domain and using USB devices also is very easy. We will cover these aspects in the next article. Check out Windows XP Mode RC Build today, and let us know what you think, either via the comments section here, or sharing your feedback on the WVPC and Windows XP Mode Forum on Technet here.

Prasad Saripalli

Principal Program Manager

Microsoft Virtualization Team

Windows Virtual PC

Windows® Virtual PC (WVPC) is a client virtualization software, which can be used on Windows 7 to create multiple Virtual Machines (VMs), each running a different operating system (OS). WVPC can be obtained as a free download from Windows Virtual PC website. WVPC is the engine which supports Windows XP Mode, a preconfigured VM running Windows XP SP3 provided by Microsoft on Windows Professional, Ultimate and Enterprise SKUs.

A VM functions as an additional PC on your Windows 7 desktop, complete with its own Start menu, applications, folders such as My Documents, access to the network for email and Internet, and access to USB and serial devices. Installing WVPC creates a short-cut named “Windows Virtual PC” on Windows 7 Start menu (Figure 1). Clicking on the shortcut opens the Virtual Machines folder, with a command bar that has an option to create a new VM. You can create a new VM using a guest OS image (e.g. Windows XP SP3 DVD or ISO image, or a VHD containing the OS image).

Figure 1. Start menu integration of Windows Virtual PC, VMs and virtual applications

WVPC supports Windows XP SP3, Windows Vista SP2 and Windows 7 as the guest OS. To the guest OS running in the VM, WVPC presents a virtual hardware, complete with disk, CPU, memory, I/O and other devices. Virtual Machine Monitor (VMM), a kernel-level component running on the host OS, manages the instructions from the VM for all the guest VM operations such as CPU, disk and I/O access, device and network access.

Key Features in Windows Virtual PC

• WVPC is seamlessly integrated into the Windows desktop. This enables you to launch and use a full VM or a virtual application as if it is just another native Windows 7 application, and navigate between the host and guest environments and applications freely. This is provided via features such as clipboard sharing, printer sharing, Start menu integration, file system and drive sharing, and file association with host.
• WVPC comes with a new UI including a full VM Console, Settings interface and a WVPC Wizards interface to create new VMs, and advanced management of VMs using diff disks. 
• Windows XP Mode, a preconfigured Windows XP SP3 VM, is provided with WVPC on Business SKUs, to easily create and setup a virtual XP desktop which gets integrated with the Start menu.
• WVPC can run in two modes: a Virtual Applications mode to run legacy applications seamlessly, and a full desktop mode that gives the user a full desktop experience of the guest operating system. 
• Printers, flash memory sticks, external hard disks and backup disks, digital cameras and smartcards are USB devices important to the Enterprise and SMB users, which can be used easily in WVPC VMs.
• WVPC provides extensive networking capabilities to a virtual machine. You can configure network connections between a VM and the host, among multiple VMs, and between VMs and the external network. 
• COM scripting support and headless VM support are provided, with an SDK for developers and IT Pros to extend the basic WVPC functionality to enable their unique scenarios.
• WVPC takes advantage of Hardware Assisted Virtualization (HAV) feature (Intel® VT and AMD-V™) which improves the performance and robustness of VMs on HAV-capable hardware. HAV is required to use WVPC on Windows 7.

In the upcoming blog articles, we will dive into how each feature and component of WVPC was engineered and how to use them in different scenarios. In this first article, we will focus on seamless application compatibility, which is the key scenario WVPC enables.

Seamless Application Compatibility

Windows 7 is built to effectively address the application compatibility need, using the Application Compatibility features provided in-box. Windows XP Mode is an additional solution specifically targeting Windows XP application compatibility. It is a preconfigured VM, created using a pre-activated and sys-prepped copy of Windows XP SP3 in VHD file format. It will be made available on the Download Center as a separate EXE package containing a VHD (with XP SP3) for installing on Windows 7.

Using a VM as a Full Desktop on Windows 7

In Figure 1, clicking on the shortcut to Windows XP Mode launches a full XP desktop in a VM (Fig. 2). User is able to run Internet Explorer® 6 and Excel® 2003, two LOB (Line of Business) applications, in XP Mode in this way. Notice the XP Taskbar within the VM right above the Windows 7 super bar, on which Excel and IE6 icons are shown. The full VM also provides a toolbar (at window top) with different options to interact with the VM. For example, expanding the ‘Action’ dropdown menu item presents options to view the same VM in full screen mode, to restart, sleep or close the VM. The Tools menu item presents a shortcut to VM Settings. Clicking on it launches the Settings dialog where user can specify any changes in VM memory, networking options, logon credentials and other settings. The Ctr+Alt+Del option is necessary to shutdown the VM, whereas clicking on the (X) icon on the far right would close the VM as per the user’s preference specified in Settings (i.e., hibernate, logoff or shutdown). These features and scenarios will be discussed in detail, in future blog articles.

Figure 2. A VM created using an XP guest OS running on a Windows 7 desktop

Virtual Applications: Running your Windows XP Applications seamlessly on Windows 7

In the above full VM scenario, to run an LOB app (Excel 2003), user has to launch the XP VM first and then start the application within the VM. WVPC offers a much more seamless solution to application compatibility, via the Virtual Applications and Windows XP Mode features. Virtual applications are seamlessly integrated with the Windows 7 desktop and Start menu. When an application is installed in the XP Mode VM, a shortcut gets automatically created on the Start menu of Windows 7 (Figure 3). Notice the shortcut link to Internet Explorer 6 and Excel 2003 – two virtual applications. Clicking on the Excel shortcut will launch that application. Virtual applications icons can also be integrated with Windows 7 notification area (Systray). Files created using such applications have their file association enabled, which means that, clicking the file’s icon shortcut will also launch the required virtual application and open the file. Book1.xls, an Excel 2003 file, has its shortcut placed on Windows 7 desktop. Such virtual application files can be saved in the host My Documents folder or the Desktop.

Launching the first virtual application starts the underlying VM, automatically logging the user in. Launching of subsequent applications is much faster. Notice the shortcuts to Excel and IE6 pinned to the Windows 7 super bar, and appear in a jump list as well. Such seamless integration with Windows 7 Shell is designed to facilitate a simple, delightful experience using legacy apps.

Figure 3. A virtual application, Excel 2003, running in seamless mode on a Windows 7 desktop

In Closing…

The central vision of WVPC is to drive the overall adoption of Windows 7 by addressing the legacy application compatibility needs of enterprise and small business users with a very simple, readily accessible and seamless presentation of applications and virtual desktops. We will blog about these features and scenarios in detail soon. Watch this space, and welcome to the Windows Virtual PC and Windows XP Mode experience on Windows 7!

Prasad Saripalli

Principal Program Manager

Microsoft Virtualization Team