The Virtual PC team is thrilled to announce the availability of KB977206 which allows our customers to use Windows Virtual PC and Windows XP Mode on non-HAV (Hardware-Assisted Virtualization) machines. Windows XP Mode continues to use hardware virtualization such as Intel Virtualization Technology (Intel® VT) or the AMD-V™ chipset when available but it no longer requires them. A number of our customers and partners have been asking us to support a wider range of PC’s including those without HAV capability and we have delivered this software patch to address their needs. We believe that this change simplifies the customer experience and makes this benefit accessible to many more PCs.
Download the software update for 32-bit host operating systems from here and for 64-bit host operating systems from here.
The KB article describes the various scenarios under which the software update must be installed. Ensure that Windows Virtual PC is installed before applying this fix.
Some FAQ’s around this update:
Q: How do I check the HAV capability of my machine?
A: Download and run the Microsoft Hardware-Assisted Virtualization Detection Tool. Go through the user guide for detailed description of the result.
Q: I have a machine with a HAV enabled processor, which has Windows Virtual PC and Windows XP Mode running. Do I need to apply this fix?
A: Short Answer – No
Long Answer – The fix is primarily targeted for non-HAV machines. If you have a functioning setup, then you can opt to not apply this fix. However please note that this update contains the fix for the power state issue seen (with Windows Virtual PC installed) on Intel® Clarkdale/Arrandale processor (http://support.microsoft.com/kb/977632) and it is recommended that you apply this update on that specific hardware. If you are an IT Administrator with a heterogeneous mixture of machines (HAV plus non-HAV machines), you can deploy this fix on all the machines. The user experience and performance on a HAV enabled machine before and after applying this fix will continue to be the same.
Q: I have a machine with a HAV capable processor (i.e the HAV setting is not enabled in the BIOS yet). Do I need to apply this fix?
A: For Windows XP Mode (or any Windows XP SP3 guest OS) users, we expect the performance to be comparable on HAV and non-HAV processors, however if you are planning to use any other guest OS we recommend that you enable the HAV setting in the BIOS rather than applying the patch.
Q: I have a non-HAV box and I wish to use a Windows Vista/Windows 7 VM using Windows Virtual PC. Is it possible?
A: This fix is primarily targeted towards users who need to run their productivity applications in Windows XP Mode (or any Windows XP SP3 virtual machine) on non-HAV machines. Hence you would need a HAV capable processor if you need to run a Windows Vista or Windows 7 virtual machine on Windows Virtual PC with acceptable performance.
Praveen Vijayaraghavan
Program Manager, Microsoft Virtualization Team
Virtual PC 2007® SP1 allowed users to share a particular folder with the Virtual Machine (VM). In Windows® Virtual PC, users can enable sharing at drive level only.
To share a particular folder with the VM, follow steps as below
This is all you need to do to share a particular folder between host and VM. To remove the virtual drive use subst S: /d command.
Let’s add little more fun by making it easier to send files to Windows7 host from a VM.
It is that simple and now by using right click menu for any file or folder you can use “Send To” menu to easily copy files to the Windows 7 desktop (Figure 3).
Vinod Atal
SDE
Microsoft Virtualization Team
Some old legacy devices may not have driver support for newer operating systems (Windows® Vista and beyond). Windows® Virtual PC (WVPC) makes it possible to use these devices in Windows® 7, using Windows® XP Mode. Users can, at the same time, utilize the benefits of newer and secure features of Windows® 7. In this article, we will describe the USB architecture in WVPC. Typical USB devices used in a Virtual Machine (VM) are:
Details on using these devices with the VM can be found in an earlier post.
WVPC uses the Redirection Policy Manager (RPM) of the Windows to provide the USB redirection in a Virtual Machine. It loads an alternate driver in the lieu of the original driver to redirect the device to a Virtual machine. WVPC creates a virtualized host controller in the Virtual Machine that is being offered using a VPCBus Channel. For more details, please refer to earlier post.
The overall USB architecture is shown in Figure 2.
USB architecture consists of a server side component running in Host OS and a client side component running in Virtual Machine. The server side involves a Connector driver to manage USB devices and a Stub instance for every USB Device. The client side implements a VPCBus enumerated virtual host controller that supports the subset of the USB driver interfaces that are necessary for compatibility with the supported devices. The redirection process also triggers the connector driver to send commands to the guest to create the PDO for the redirected device. After this the Stub driver, Connector driver and the Virtual bus/hub driver work in unison to enable communication of commands, responses and data between physical USB device and the redirected USB device. Component details are described below:
A channel is created by Virtual PC host process (VPC.exe) through the Connector Driver using VPCBus whenever a VM boots up. Also, a server side hub instance is created internally by the Connector with this channel for every VM. There are two drivers on the server side as below:
A total of up to 8 USB devices can be assigned to a VM at a time. HID and Hub Class Devices cannot be assigned to the VM. The USB devices in VM can be safely removed just like in Host OS whenever the USB device driver supports.
The virtual host controller is a VPCBus enumerated bus driver (USB Virtualization Bus Driver) that takes the place of normal host controller driver. It is exposed to the system as two devices – a host controller and a root-hub device.
The virtual hub (USB Virtualization Hub Driver) creates the PDOs that mirror virtualized devices in the parent partition. The PNP manager loads the Client USB device drivers (or stacks of drivers) for the device. The virtual hub driver handles the IOCTLs either locally or sends the same to the USB device using Connector Driver. Please refer Figure 3 showing the Device Manager of Guest and Host.
USB Device assigned to a Virtual Machine reacts to the power state changes of the host OS as well as Virtual Machine. The changes are described below:
A USB device gets automatically assigned to host OS whenever a Virtual machine is shutdown, restarted, turned off or saved. The device remains within the VM whenever a VM is put to ‘Sleep’ state.
USB Device gets assigned to host OS on host restart/shutdown/logoff. It remains within the VM on host sleep/hibernate.
Devices like printers, smart cards and USB external/flash drives are shared with Virtual Machine in Integration Features Enabled mode by the (Remote Desktop Protocol) RDP. These devices can be used with host OS as well as the Virtual Machine(s) at the same time. More details about this can be found in an earlier post.
Assigning a USB Device to a VM removes the device from host OS. It is only visible to the Virtual machine it is attached to and an application running on the host OS cannot access the device.
Group policy can be used to prevent the redirection of selected USB devices to a Virtual Machine, for security or compliance reasons for example. This can be done at per device/device-class level. Also, all USB devices can be prevented to be used inside a VM. These settings are helpful in an organization where users are not allowed to use these devices in the physical machine as well.
These Group policy settings can be found under Computer Configuration -> Administrative Templates -> System->Device Redirection -> Device Redirection Restrictions as shown below (Figure 4).
There are two group policy settings for the Device Redirection Restrictions as described below:
Enabling this policy setting will prevent the redirection of specific USB devices on a machine that matches the criteria specified in the Value field. For example, to block all USB Audio class devices (USB Class Code 01) for the redirection, the policy needs to be configured with Class_01 as shown below (Figure 5).
Enabling this policy setting will prevent the redirection of all USB devices on a machine.
More details about these policy settings can be found on MSDN here.
WVPC provides COM support to manage USB devices. The APIs are documented on MSDN at http://msdn.microsoft.com/en-us/library/dd796758(VS.85).aspx. Let’s take a look few scenarios for using these APIs to manage USB devices. A user wants to assign a USB Device whenever a VM is started. Another scenario is that an IT admin wants to restrict the USB Device Redirection feature due to some piracy/security concerns. In these scenarios, a developer can write scripts in VB/powershell or a code in any COM capable language to achieve this. Some samples are provided below:
A developer can use AttachUSBDevice method of IVMVirtualMachine interface to assign a USB device to the VM. A sample C++ code is shown below:
1: // Steps to Assign a Device
2: // Step 1: Get the Virtual PC object
3: // Step 2: Get the Virtual Machine Object
4: // Step 3: Start the Virtual Machine if it's not running
5: // Step 3: Get the USB Device Collection
6: // Step 4: Get the USB Device Object to be assigned based on Device String
7: // Step 5: Assign the Device
8:
9:
10: #define CHECK_NULL_RELEASE(obj) if(obj) \
11: {\
12: obj->Release();\
13: obj = NULL;\
14: }
15:
16: int __cdecl main(int , char* )
17: {
18: IVMVirtualMachine* pVM = NULL;
19: IVMVirtualPC* pIVPC = NULL;
20: HRESULT hr = S_OK;
21: BSTR bName = NULL;
22: VMVMState vmState = vmVMState_Invalid;
23: IVMTask* pIVMTask = NULL;
24: IVMUSBDeviceCollection* pUSBDeviceCollection = NULL;
25: long usbDeviceCount = 0;
26: IVMUSBDevice* pUsbDevice = NULL;
27: long index = 0;
28: BSTR bDeviceString = NULL;
29: bool bDeviceFound = FALSE;
30:
31: // Change the VM name as needed
32: LPWSTR lVMNameToBeAssigned = L"Windows XP Mode";
33:
34: // Change the Device String as needed
35: LPWSTR lUsbDeviceString = L"Cruzer Micro"; //L"Mass Storage Device";
36:
37: // Initialize VPC COM interfaces.
38: hr = InitVPCComInterfaces(&pIVPC);
39: if (hr != S_OK)
40: {
41: goto Cleanup;
42: }
43:
44: // Allocate the Memory for the Virtual Machine Name
45: // on which Device needs to be assigned.
46: bName = SysAllocString(lVMNameToBeAssigned);
47: if (bName == NULL) // Unable to allocate the Memory for VM Name String
48: {
49: hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);
50: goto Cleanup;
51: }
52:
53: // Get the Virtual Machine object of the provided VMNAME
54: hr = pIVPC->FindVirtualMachine(bName, &pVM);
55: if (hr != S_OK)
56: {
57: goto Cleanup;
58: }
59:
60: // Start the Virtual Machine if it's not running
61: hr = pVM->get_State(&vmState);
62: if (hr != S_OK)
63: {
64: goto Cleanup;
65: }
66:
67: if(vmState == vmVMState_Running)
68: {
69: // VM is already Running
70: }
71: else
72: {
73: hr = pVM->Startup(&pIVMTask);
74: if (hr !=S_OK)
75: {
76: goto Cleanup;
77: }
78:
79: // Wait till the VM boots up
80: hr = pIVMTask->WaitForCompletion(-1);
81: if (hr != S_OK)
82: {
83: goto Cleanup;
84: }
85: }
86:
87: // Get the USB Device Collection
88: hr = pIVPC->get_USBDeviceCollection(&pUSBDeviceCollection);
89: if (hr != S_OK)
90: {
91: goto Cleanup;
92: }
93:
94: // Get the USB Device Collection Count
95: hr = pUSBDeviceCollection->get_Count(&usbDeviceCount);
96: if (hr != S_OK)
97: {
98: goto Cleanup;
99: }
100:
101: if (usbDeviceCount == 0)
102: goto Cleanup;
103:
104: // Iterate through the USB Device Collection for the Device to be Assigned
105: for ( index = 1; index <= usbDeviceCount; index++)
106: {
107: hr = pUSBDeviceCollection->get_Item(index, &pUsbDevice);
108: if (hr != S_OK)
109: goto Cleanup;
110:
111: // Get the Device Name or Manufacturer String
112: hr = pUsbDevice->get_DeviceString(&bDeviceString);
113: if (hr != S_OK)
114: goto Cleanup;
115:
116: // Check the Device String for the Match
117: if (_wcsicmp(bDeviceString, lUsbDeviceString) == 0 )
118: {
119: // Device is Found
120: bDeviceFound = TRUE;
121: break;
122: }
123: }
124:
125: if (bDeviceFound == TRUE)
126: {
127: // Device was found above.
128: // Assign the Device to the VM
129: hr = pVM->AttachUSBDevice(pUsbDevice);
130: if (hr != S_OK)
131: goto Cleanup;
132: }
133:
134: Cleanup:
135: CHECK_NULL_RELEASE(pIVPC);
136: CHECK_NULL_RELEASE(pVM);
137: CHECK_NULL_RELEASE(pUSBDeviceCollection);
138: CHECK_NULL_RELEASE(pUsbDevice);
139: CHECK_NULL_RELEASE(pIVMTask);
140: SysFreeString(bName);
141: SysFreeString(bDeviceString);
142:
143: return 0;
144: }
145:
146: HRESULT
147: InitVPCComInterfaces(
148: __inout IVMVirtualPC** ppIVPC
149: )
150: {
151: HRESULT hr = S_OK;
152: BSTR bVer = NULL;
153:
154: // Initialize COM
155:
156: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
157: if (hr != S_OK)
158: return hr;
159:
160: REFCLSID classID = _uuidof(VMVirtualPC);
161:
162: // Get the VPC object
163: hr = CoCreateInstance(classID,
164: NULL,
165: CLSCTX_ALL,
166: IID_IVMVirtualPC,
167: (LPVOID*)ppIVPC);
168:
169: if (SUCCEEDED(hr) && (*ppIVPC != NULL))
170: {
171: // Make a call to the VPC interface and see if it works.
172: hr = (*ppIVPC)->get_Version(&bVer);
173: }
174:
175: SysFreeString(bVer);
176: return hr;
177: }
Similarly, a developer can use DetachUSBDevice method of IVMVirtualMachine interface to release a USB device from the VM. A sample C++ code is shown below:
1: // Steps to Release a Device
4: // Step 3: Get the USB Device Collection
5: // Step 4: Get the USB Device Object to be assigned based on Device String
6: // Step 5: Verify the Device is attached to the VM
7: // Step 6: Release the USB Device
9: #define SAFE_RELEASE(obj) if(obj) \
10: {\
11: obj->Release();\
12: obj = NULL;\
13: }
14:
15: int __cdecl main(int , char* )
16: {
17: IVMVirtualMachine* pVM = NULL;
18: IVMVirtualPC* pIVPC = NULL;
19: HRESULT hr = S_OK;
20: BSTR bName = NULL;
21: BSTR bVmNameAttachedTo = NULL;
23: IVMUSBDeviceCollection* pUSBDeviceCollection = NULL;
24: long usbDeviceCount = 0;
25: IVMUSBDevice* pUsbDevice = NULL;
26: long index = 0;
27: BSTR bDeviceString = NULL;
28: bool bDeviceFound = FALSE;
29:
30: // Change the VM name as needed
31: LPWSTR lVMNameToBeAssigned = L"Windows XP Mode";
32:
33: // Change the Device String as needed
34: LPWSTR lUsbDeviceString = L"Mass Storage Device";
35:
36: // Initialize VPC COM interfaces.
37: hr = InitVPCComInterfaces(&pIVPC);
38: if (hr != S_OK)
39: {
40: goto Cleanup;
41: }
42:
43: // Allocate the Memory for the Virtual Machine Name
44: // on which Device needs to be assigned.
45: bName = SysAllocString(lVMNameToBeAssigned);
46: if (bName == NULL) // Unable to allocate the Memory for VM Name String
47: {
48: hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);
49: goto Cleanup;
50: }
51:
52: // Get the Virtual Machine object of the provided VMNAME
53: hr = pIVPC->FindVirtualMachine(bName, &pVM);
54: if (hr != S_OK)
55: {
56: goto Cleanup;
57: }
58:
59: // Check the Virtual Machine State for Running
60: hr = pVM->get_State(&vmState);
61: if (hr != S_OK)
62: {
63: goto Cleanup;
64: }
65:
66: if(vmState == vmVMState_Running)
67: {
68: // VM is Running
69: }
70: else
71: {
72: // VM is not Running
73: goto Cleanup;
74: }
75:
76: // Get the USB Device Collection
77: hr = pIVPC->get_USBDeviceCollection(&pUSBDeviceCollection);
78: if (hr != S_OK)
79: {
80: goto Cleanup;
81: }
82:
83: // Get the USB Device Collection Count
84: hr = pUSBDeviceCollection->get_Count(&usbDeviceCount);
85: if (hr != S_OK)
86: {
87: goto Cleanup;
88: }
89:
90: if (usbDeviceCount == 0) // No USB Devices Connected to the Machine
92:
93: // Iterate through the USB Device Collection for the Device to be Assigned
94: for ( index = 1; index <= usbDeviceCount; index++)
95: {
96: hr = pUSBDeviceCollection->get_Item(index, &pUsbDevice);
97: if (hr != S_OK)
99:
100: // Get the Device Name or Manufacturer String
101: hr = pUsbDevice->get_DeviceString(&bDeviceString);
102: if (hr != S_OK)
103: goto Cleanup;
104:
105: // Check the Device String for the Match
106: if (_wcsicmp(bDeviceString, lUsbDeviceString) == 0 )
107: {
108: // Verify that the Device is attached to this VM
109: hr = pUsbDevice->get_AttachedToVM(&bVmNameAttachedTo);
110: if (hr != S_OK)
111: goto Cleanup;
112:
113: if (_wcsicmp(bVmNameAttachedTo, bName) == 0 )
114: {
115: // Device is Found attached to this VM
116: bDeviceFound = TRUE;
117: break;
118: }
119: }
120: }
121:
122: if (bDeviceFound == TRUE)
123: {
124: // Device was found above.
125: // Assign the Device to the VM
126: hr = pVM->DetachUSBDevice(pUsbDevice);
127: if (hr != S_OK)
128: goto Cleanup;
129: }
130:
131: Cleanup:
132: SAFE_RELEASE(pIVPC);
133: SAFE_RELEASE(pVM);
134: SAFE_RELEASE(pUSBDeviceCollection);
135: SAFE_RELEASE(pUsbDevice);
136: SysFreeString(bName);
137: SysFreeString(bDeviceString);
138: SysFreeString(bVmNameAttachedTo);
139:
140: return 0;
141: }
143: HRESULT
144: InitVPCComInterfaces(
145: __inout IVMVirtualPC** ppIVPC
146: )
147: {
148: HRESULT hr = S_OK;
149: BSTR bVer = NULL;
150:
151: // Initialize COM
152:
153: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
154: if (hr != S_OK)
155: return hr;
156:
157: REFCLSID classID = _uuidof(VMVirtualPC);
158:
159: // Get the VPC object
160: hr = CoCreateInstance(classID,
161: NULL,
162: CLSCTX_ALL,
163: IID_IVMVirtualPC,
164: (LPVOID*)ppIVPC);
165:
166: if (SUCCEEDED(hr) && (*ppIVPC != NULL))
167: {
168: // Make a call to the VPC interface and see if it works.
169: hr = (*ppIVPC)->get_Version(&bVer);
170: }
171:
172: SysFreeString(bVer);
173: return hr;
174: }
In Windows 7, GP objects can be managed using Powershell or using COM scripts. These can be extended to restrict USB Devices in Virtual Machines.
A device gets assigned to host OS whenever the VM is hibernated, shutdown/restarted. WVPC doesn’t provide a direct option to assign a USB device automatically in these scenarios. However, a developer can create their own applications using the above APIs.
Managing USB devices of Windows XP Mode and WVPC is very simple and straightforward. USB devices can be shared or even assigned to a VM. COM APIs can be used to assign-release devices or even creating applications for their own customized scenarios. We hope this information is useful to you.
Rahul Rajwanshi
SDET
This article will briefly explain how Networking works and the configuration options for Networking in Windows® Virtual PC (WVPC).
The Virtual PC host application emulates Intel DEC 21140A network cards. Each Virtual Machine (VM) can have up to four such emulated network cards. The ‘Create Virtual Machine wizard’ in WVPC attaches by default one or two network adapters to connect to one wired and one wireless host network adapter (Fig. 1). Each emulated network adapter is assigned a unique MAC address in the range 00-03-ff-XX-XX-XX. The last three octets are calculated using the host network adapter MAC address. Each network card optionally connects to the various networking options described below.
Windows® XP Mode is by default connected to the Shared Networking or NAT, which is one of the four network connection options WVPC provides.
Each of the network adapters can be configured to connect to the virtual network as explained below. Fig. 1 shows the Setting dialog box and each network card can optionally connect to the network using the following options:
1. Not Connected: This option leaves the card unconnected to any network and will show that the network cable is disconnected inside the virtual machine.
2. Host Adapter: This option, called the ‘Bridge Mode’, is used to connect to the external network using the host network adapters. When the VM is connected using this option, the virtual card has a unique presence on the network. This option requires the Virtual PC Network Filter driver to be installed in the host networking stack. This driver gets installed during the WVPC installation and also binds to all the 802.3/802.11 based network adapters. In the diagram below you can see that Virtual PC Network filter driver is bound to one of the host adapter. To open this dialog, open Windows Start menu, type Network and Sharing Center. In the left click on Change Adapter settings. Select the required Adapter and right click to open properties which will show you this dialog.
This driver is a NDIS 6 Filter driver and sits above the miniport layer in the NDIS stack. It maintains a 1:1 mapping between the protocol and miniport layers of NDIS. It is designed to handle Ethernet packets which makes it protocol agnostic and thus can support protocols other than TCP/IP. The above diagram shows that the Virtual PC Network Filter driver is bound to the Host Ethernet adapter and Guests can use this adapter to connect to the external network.
Fig 3 shows the high level architecture of the bridge mode networking. In this diagram, the left side shows the host networking stack in which WVPC network driver vpcnfltr.sys is installed. The block on the right hand side represents the WVPC application which emulates the network card, connects it to the virtual network which in turn can connect to the vpcnfltr driver. This driver is a filter driver which intercepts the packets, inspects them and does basic level Ethernet switching to route it to its destination. When the packet is sent from the guest, it checks the MAC address destination and if it is meant for the host it injects into the higher level host NDIS stack. If the packet is meant for another guest, it indicates to them internally and remaining packets are sent to the external network through the host adapter.
The host Ethernet adapter generally accepts only those packets which are destined for its own MAC address. To receive other packets which could be destined for the guests, it puts the adapter in promiscuous mode (only for 802.3) which will make the host adapter start accepting all packets. The driver on receive from the adapter checks for the MAC address and if it matches for any of the guest registered with the driver, it sends it to the guest. Also if the packets are directed then it is not sent to the host upper layers. Similarly packets meant for the host are not sent to any other guest and is indicated to the higher level NDIS stack for further processing.
3. Shared Networking: Shared Networking or Network Address Translation (NAT) is another way that the guest can connect to the external network. The main difference between this and the bridge mode is that the guest is behind the NAT and it does not have a unique identity in the external network. It supports all connections which uses TCP/IP. Connecting using the bridge mode networking requires separate IP Address for the guest, thus in situations where there is a shortage of IP addresses, connecting using NAT is a valuable option. This option should also be used in cases when you don’t want to directly connect to an external network and remain behind this NAT. This acts as a strong firewall which protects the guest from outside attacks.
There are certain limitations while connecting using NAT. If the payload contains the source IP Address, then it may break as the IP address is replaced with the host but the payload will still contain the guest IP address. Also connecting via VPN from inside the guest is not supported. Some VPN requires raw sockets to be opened, which needs admin privileges to successfully open these sockets, whereas WVPC application runs in the user context. Applications using TCP/IP like Internet Browsing, messenger, shared access, etc. will work when connected using NAT. It is recommended to connect using the bridge mode when the guest needs to use VPN.
4. Internal Network: This option is used to connect two or more guests together for an isolated network. When the guest is using this option, it can only connect to the other guests on the same physical machine. WVPC application internally has a software switch which forwards the packets meant for the destination guest without connecting to the external world. This is useful for cases where you want to connect to two or more machines completely isolated from the network. The internal network also maintains the DHCP server and provides the DHCP addresses in the range of 169.254.0.16 to 169.254.10.254. If another guest is acting as DHCP Server, you would need to disable the DHCP server so that DHCP packets can reach to that guest.
There are multiple options to connect VMs created using WVPC to internal and external networks. We hope this information is useful to you. Check out 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.
Vrijesh Kothari
Following are the various file types registered on a user’s machine when Windows® Virtual PC is installed:
.VMC (Virtual Machine Configuration)
Contains Virtual Machine (VM) configuration like RAM, hard disk, network settings and undo disk settings. This file is associated with vmwindow.exe.
Yes
.VHD (Virtual Hard Disk)
This is the hard disk of VM and most important file to back up. This is a large file and it should be created on disk volume with enough free space. All data for the VM including the operating system data are stored in this file. Refer this article for more details for understanding disk types.
.VUD (Virtual Undo Disk)
Undo disk for the VM. When undo disk option is enabled all changes to VM are stored in this file. This file is generated at the same path as the .VMC file. So, if you keep undo disk enabled for long time, make sure there is enough free disk space in the volume.
.VSV (Virtual machine Saved-State)
Dump of virtual machine RAM. Helps to restore VM quickly. Size of this file is the same as amount of RAM assigned to the VM
No
.VFD (Virtual Floppy Disk)
Floppy disk image. There is no UI to attach VFD to VM since usage of floppy is obsolete. User can still use COM API to attach vfd to VM
.VMCX (vmc eXtended)
This is used by VPC for internal usage only. Explorer shell uses this file to display virtual machine information to the user
. vpcbackup
Internal use only. Keeps backed up .vmc file
Now with the understanding of various file types, it should be clear that .VHD is the most important file to save when you want to back up a VM. Follow the steps as below:
Let’s walk through an example for backing up a VM created in Windows® XP Mode:
Figure 1. Specifying the Hard Disk location in Windows XP Mode Settings UI
3. Check Undo disks settings. If this is enabled, open directory of .VHD as shown in hard disk page. Here you can find the .vud file
4. The .VMC file is stored at %localappdata%\Microsoft\Windows Virtual PC. You can find the path of .VMC file in “Virtual Machines” folder. Refer “Configuration file” column in this folder
5. Copy .VMC, .VHD, .VUD file to backup virtual machine. Make sure you keep the relative path same for diff disk VHD and parent VHD. A typical out of box installation of Windows XP Mode VM involves the following files to backup
There are various ways to back up the VM files. You may be using Windows® backup for complete system backup or making volume back up using VSS or you may use simple copy to save VM files. The important point is to backup all required files (.VHD, .VUD, .VMC) and restore them using same toolset.
Virtual Hard Disks (abbreviated to VHDs) are files on the physical machine that store the hard disk contents of a Virtual Machine (VM). Each VHD file is treated as a separate hard disk by Windows® Virtual PC (WVPC).
The Virtual Hard Disk file format is an open standard. For the curious, the specifications of VHD file format can be found here: http://technet.microsoft.com/en-us/virtualserver/bb676673.aspx. As can be seen, the format is quite straightforward and is completely agnostic to the virtualization technology in use and to the host and guest operating systems.
WVPC, Windows® XP Mode, Microsoft Hyper-V®, Virtual PC 2007® and other Microsoft’s virtualization solutions use the VHD format.
There are three types of Virtual Hard Disks: fixed disks, dynamically expanding disks and differencing disks.
Fixed disks take up all the space that the VHD is allowed to have up front. For instance, if you create a fixed disk of size 64GB, the VHD file will occupy 64GB of hard disk space right from the time of creation, and its size will never vary.
Dynamically expanding disks (also called sparse disks) increase in size to take up space as required. The size specified when creating a dynamically expanding disk indicates the maximum size that the disk is allowed to grow to. For instance, if you create a dynamically expanding disk of size 64GB, the VHD file might initially occupy only a few KB. It will slowly grow upon usage to occupy up to the maximum size specified (64GB). Note however, that the guest operating system will be made to believe it has the full 64GB right from the start.
Differencing disks are a little different. They merely save the changes to the VHD relative to a base disk. Differencing disks are always linked to a dynamically expanding disk or a fixed disk, either directly or through one or more other differencing disks. To understand differencing disks, let us say you create a fixed disk with Windows® XP installed on it. Now if you create a differencing disk and install Microsoft Office® on this, the differencing disk will contain mainly* the content of the hard disk locations changed by the installation of Microsoft Office®, which will be the locations containing the new files and any modifications to existing files.
* I say “mainly” since the operating system will make changes to the hard disk too, as part of its regular operation (writing to the page file, for instance).
To illustrate this point, take a look at the figure below. There are two VMs using two differencing disks that branch from the same base disk.
The changes made by VM#1 are saved in its differencing disk (depicted as orange blocks) and the changes made by VM#2 are saved in VM#2’s differencing disk (depicted as green blocks). Wherever there is no data in the differencing disk (i.e., a blank space between the orange blocks), the data will be automatically fetched from the base disk. Thus, VM#1 will see the resultant hard disk as a mix of orange and blue blocks. Neither VM#1 nor VM#2 will be able to see the changes made by the other since these changes are on different differencing disks, and both think they have their own copy of the base disk.
The base reference disk is called the “parent” of the differencing disk, and the differencing disk is called its “child”. As you might have guessed, a differencing disk is unusable without the parent disk. What’s more, any change made to the parent will potentially invalidate the child since the reference file is now different. This is why it is recommended to choose a base parent disk and mark it “read-only” for good.
And what’s the size of the differencing disk, you ask? Well, the differencing disk grows in size as required, and inherits the maximum size from its parent disk.
Needless to say, all types of VHDs will have the “.vhd” extension. The maximum size of the VHDs supported by Windows Virtual PC is 127GB.
Dynamically expanding disks and differencing disks are by far the most commonly used VHD types.
The biggest advantage of differencing disks is that you can have as many child disks as you like from a single parent disk. So if you need 5 virtual machines with Windows® XP with each configured differently, you can simply create a single sparse/fixed VHD with Windows® XP installed on it and then create 5 differencing disks from this. So that’s saving 4 times the space needed to install Windows® XP!
Indeed, this is the approach used in Windows® XP Mode! Well, let me explain that in detail.
When a user installs the Windows® XP Mode package, a dynamically expanding VHD is placed on the system. This is the base VHD, which contains a sys-prepped copy of Windows XP SP3®. The base VHD has already been marked read-only, and what’s more, it’s permissions have been set in such a way that only TrustedInstaller can make changes to it (and the only change TrustedInstaller will make is to remove the file on uninstall). This takes care of having a pristine base VHD that won’t be modified (Figure 2).
When you click on the “Windows XP Mode” link on the start menu after installing the VHD, VPC detects that the VHD has been installed and launches a wizard that takes basic information needed to create the VM. As you can see, this wizard is different from the wizard used to create a VM – for starters, this wizard has already decided to create a differencing disk with the Windows XP Mode VHD as the parent; it merely asks you where you want to place the differencing disk.
Each user on the computer will be shown this wizard and will have a new differencing disk created for them. This way, every user has access to their personal copy of Windows XP without taking up extra space for the Windows XP install.
This above example is a typical use-case for differencing disks. You can have a similar setup on your machine(s) with Windows® Vista and/or Windows® 7 VMs too. Of course, it is strongly advised that you optimize the base VHD before calling it pristine and marking it read-only. Ah, we haven’t discussed VHD optimizations yet, have we? Well, considering that topic is big enough to merit its own post, I’ll save that for another day. Stay tuned for more on VHDs!
Thayu Ramaiah
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®.
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: {
9: if ($vm.state -eq 5) # check for running state
10:
11: {
12:
13: echo "cannot delete a running VM"
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: }
31: if ($vm.undoable -eq $true)
33: {
34:
35: echo "discarding undo disks"
37: $vm.DiscardUndoDisks()
38:
39: }
40:
41: foreach ($hdc in $vm.HardDiskConnections)
43: {
44:
45: echo "deleting vhd file"
46:
47: $hd = $hdc.HardDisk ;
48:
49: $vm.RemoveHardDiskConnection($hdc) ;
50:
51: del $hd.File ;
53: }
54:
55: echo "deleting virtual machine"
56:
57: $vpc.DeleteVirtualMachine($vm)
59: }
60:
61: }
62:
63: else
64:
65: {
67: echo "VM does not exists"
68:
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”
5: $hd = $vpc.GetHardDisk("D:\VHDStore\parent.vhd")
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.
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.
5: $vm.SetConfigurationValue("hardware/bios/time_sync_at_boot",$false)
7: $guest = $vm.GuestOS
9: $guest.IsHostTimeSyncEnabled = $false
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
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.
1: Option Explicit ' Force explicit variable declaration.
3: Dim defaultVMTag, defaultVM, objArgs, objVPC, vmName
4: Set objArgs = WScript.Arguments
5: Set objVPC = CreateObject("VirtualPC.Application")
7: defaultVMTag = "default_vm"
8: defaultVM = objVPC.GetConfigurationValue(defaultVMTag)
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)
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
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.
18: WScript.Echo "Starting VM: """ + vmName + """"
19: StartHeadlessVM()
21: Sub StartHeadlessVM()
22: Dim objVM
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.
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.
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
Create a shortcut of script #2 under Windows® 7 start-up folder with the following target: cscript <pathoftheScript>\<scriptname>.vbs <”VMName”>
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.
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.
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.
18: PromptAtClose()
20: Sub PromptAtClose()
22: vmcTag = "ui_options/onclose_showmessage"
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"
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:
Note: In case of headless VM, Windows® 7 Host logoff/shutdown/restart will always initiate VM hibernate/save.
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.
19: SetValue()
21: Sub SetValue()
22: Dim vmcTag, objVM
23: vmcTag = "ui_options/seconds_to_save"
24: Set objVM = objVPC.FindVirtualMachine(vmName)
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)
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
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:
CTRL+ALT+Left Arrow
Release the mouse from the virtual machine’s (VM) window (required only when the integration features are not installed or are disabled). You can also use this shortcut to release the keyboard and move focus to the toolbar on the VM’s window.
CTRL+ALT+END
Send the CTRL+ALT+DEL command to a VM. This shortcut is also available while running virtual applications, when the focus is on such an application.
Windows logo key +UP Arrow
Switch from window mode to full-screen mode.
CTRL+ALT+PAUSE BREAK
Switch from full-screen mode to window mode.
ALT+F4
Close a VM.
CTRL+ALT +Plus key
Capture a print screen of the VM display output.
CTRL+ALT +Minus key
Capture a print screen of the window in the VM that has focus.
TAB + Right Arrow
Move to the Help menu from other menus on the VM toolbar. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
TAB + Left arrow
Move from the Help menu to other menus on the VM toolbar. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+B
Open the USB menu of the VM window. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+P
Make the VM to go to a Sleep state. Before you can use this shortcut, you would need to press CTRL+ALT+Left Arrow to bring the focus on to the VM’s window.
ALT+U
Wake up the VM from sleep state.
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
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.
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.
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
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).
Using this shortcut, now you can launch any application inside VM as remote app or install new applications.
Though auto-publishing works totally automatically, with virtually no user intervention required; there are ways in which publishing can be controlled.
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
2. Retrieve the full path of the application.
3. Add this path to the exclude list (remember to get rid of the quotes) and restart the guest.
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.
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.
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: '******************************************************
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)
17: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
18: Set objSWbemObject = objSWbemServices.Get("Win32_TSPublishedApplication")
19: Set objNewSWbemObject = objSWbemObject.SpawnInstance_()
21: '***************************************************************************************
22: 'Set the various properties for the application to be added
23: '***************************************************************************************
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"
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 .
Similarly, you can manually unpublish an application using the following script.
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:
7: strQuery = "Select * From Win32_TSPublishedApplication"
8: Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & strNamespace)
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
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:
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.
2. This opens the Windows Security window inside the VM. Click on the Shut Down button.
3. On the new window, choose the Shut Down option from the drop down.
1. On the VM Windows’s toolbar, click Tools menu item, and click Settings in the drop down menu.
2. This opens the VM’s settings window. On the left navigation pane, click on “Close” option.
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.
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.
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.
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:
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.
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.
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.
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.
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
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
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.
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:
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!!!
Akash Maheshwari
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:
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.
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
The typical sequence of actions for an application using the communication channel is as follows:
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";
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;
17: //
18: // Initialize VPC COM interfaces.
19: //
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: //
30: bName = SysAllocString(VMNAME);
31: if (bName == NULL) {
32: hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);
33: goto Cleanup;
34: }
36: hr = pIVPC->FindVirtualMachine(bName, &vmObj);
37: if (hr != S_OK) {
38: goto Cleanup;
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: //
47: hr = WaitForChannelReady(vmObj);
48: if (FAILED(hr)) {
52: bPipeName = SysAllocString(PIPE_NAME);
53: bPortNumber = SysAllocString(PORT_NUMBER);
54: if (bPipeName == NULL || bPortNumber == NULL) {
55: hr = HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY);
59: //
60: // Set up the communication channel to be used by host and guest.
61: //
63: hr = vmObj->StartCommunicationChannel(vmEndpoint_NamedPipe,
64: bPipeName,
65: vmEndpoint_TCPIP,
66: bPortNumber);
67: if (FAILED(hr)) {
68: goto Cleanup;
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);
90: if (WriteFile(hPipe,
91: pszWriteThis,
92: sizeof(pszWriteThis),
93: &bytesWritten,
94: NULL) == FALSE) {
95: goto Cleanup;
96: }
97:
98: Cleanup:
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;
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);
143: return hr;
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.
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: //
13: hr = vmObj->get_ChassisAssetTag(&bChassisAssetTag);
14: if (hr != S_OK) {
15: goto Cleanup;
16: }
18: hr = StringCchCopy(ChannelReadyEventName, MAX_PATH, L"Local\\");
19: if (FAILED(hr)) {
20: goto Cleanup;
21: }
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: }
33: hEvent = CreateEvent(NULL, TRUE, FALSE, ChannelReadyEventName);
34: if(hEvent == NULL) {
35: hr = HRESULT_FROM_WIN32(GetLastError());
36: goto Cleanup;
37: }
39: if (WaitForSingleObject(hEvent, INFINITE) == WAIT_FAILED) {
40: hr = HRESULT_FROM_WIN32(GetLastError());
44: Cleanup:
45:
46: if (hEvent != NULL) {
47: CloseHandle(hEvent);
48: }
49:
50: return hr;
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>
7: // Need to link with Ws2_32.lib, Mswsock.lib, and Advapi32.lib
8: #define DEFAULT_BUFLEN 512
9: #define DEFAULT_PORT "6174"
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: }
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;
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;
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;
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");
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;
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: }
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: }
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
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
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:
In this article, we will look at the usage of these features in more detail.
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:
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.
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.
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):
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.
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
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.
Figure 1. Using XP Mode VM Tool Bar to switch between Basic and Enhanced Modes
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:
Figure 2. Language bar use and System tray integration of virtual applications
Figure 3. Adding a Virtual App (MS Outlook) to the Windows 7 Startup Folder
Here is an overview of how Virtual Applications work, with a reference to the RemoteApp technology. Diagrams presented below are only a logical abstraction:
Figure 4. Architecture of XP Mode Virtual Applications (Right) compared to RemoteApp Architecture (Left)
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.
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.
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.
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.
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
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
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!