You can of course choose to start your Virtual OS and press Alt+Enter to cause the image to take up the whole screen. One problem with this method is that people have been known to become unsatisfied with the visual performance of the Microsoft Virtual PC product. It just has problems. You do have the option to drag and drop a file into the Virtual PC window as well as setup a Virtual PC to share folders, I personally have had several issues with both of these pieces of functionality, and I'll take a good old LAN configuration every time. As such I have always opted to configure Virtual PC to share network cards with the base OS. Virtual PC does this by adding an IP address to the base OS adapter and assigning it to the Virtual OS, just like adding multiple IP addresses to any Windows LAN adapter. By doing this you get all of the advantages of any other LAN connected PC. I feel that the best advantage is the fact that you can then Remote Desktop into the Virtual OS. Your experiences may vary but I have never had the use of a desktop expanded Virtual PC image react as well as using RDP.

Connecting to the image via mstsc

MSTSC stands for Microsoft Terminal Server Client, which uses the RDP, Remote Desktop Protocol. There are a few ways that you can connect to an OS via RDP, for example:

mstsc /v:<server>:<port> /console /full /span

This command can be run from the Start | Run line and where Windows will cache it for future use by default. Or you can put it in a command file (say connectServer.cmd). If you have not loaded the latest version of the RDP client I highly suggest you do so. One advantage is that it will allow you to cause your security administrator a nightmare by caching your credentials, thus not having to provide the login and password each time. But it has other features as well. For example:

mstsc is of course the command line to execute, Microsoft Terminal Server Client

/v: is the switch that tells the command what OS to connect to, by IP, NetBIOS name or host name

:<port> is a feature I use a lot. You can change the port that an OS listens on, although I don‘t suggest it. But if you have a single IP on your firewall that you want to stack exposed ports (for example having the external NIC port 44444 point to server1 port 3389, or port 44445 on the outside point to server2 port 3389 and so on), this feature can be very useful, or even required in some circumstances

/console is not required but is very helpful. When you connect to a server generally you’ll get one of the two admin consoles. With this switch you can get the main desktop, just like windows XP, which only allows one inbound RDP connection to the console session. This is a great trick to get a “third” console when the others are taken up. It is unlikely that a human will be logged into the physical desktop of a server at all times. As a side note I just read that Microsoft changed the /console switch to /admin on Vista and Windows Server 2008

/full is a switch that tells your client to take up the full screen as seen by one video card or panel on the initiating side

/span while not required it is a good way to cover multiple panels on your client pc. I used to use the /h:<height-in-pixels> /w:<two-panels-width-in-pixels>, and still do in some cases, until this trick came out

And of course before you connect to the server via mstsc you can set all of the available options and save. When you adjust and save, it will adjust the default settings, and then the command options seen above over-ride them. You will also find that if you want to connect to your image remotely while it’s running under Microsoft Virtual PC on a desktop you have to do it this way, since Virtual PC as a program does not you to remotely connect to another running instance of Virtual PC.

Setting your adapters: reasons and some suggestions

As you know, you can configure a Virtual OS adapter to bind to a Host OS adapter. Yet I have been in places where I was surprised to find that an admin had loaded XP, Virtual PC, and an imaged OS, just to assume the users will be happy to use Virtual PC expanded mode. Not only is Virtual PC quirky in its video presentation, but at this point the Virtual OS cannot get to the internet, much less other LAN resources. The answer from some people seems to be that configuring one or more NICs is troublesome, or at least for the short term. Personally, no matter the time length, I cannot stand to work on an imaged PC that cannot get to the outside world. Having to drop all resources in to a Virtual OS window, much less copy and paste internet web page text or any remote files is also a bother.

Connection number one… NAT

In later steps I will show you how to connect your Virtual OS to the LAN like any other device. But for this instance let's assume that you don't want to go through the steps, or, quite likely, your Virtual OS is an image that is used in more than one place. This second issue would cause multiple copies of Windows with the same name to shut its adapter connection down so it will not cause conflicts. But by using NAT, and hiding your Virtual OS from the LAN, just like your router hides your LAN from the internet, you can get around this problem. Virtual PC allows the use of Network Address Translation, NAT, just like a home Linksys router. I have found that there are times I am likely to use Virtual PC hosted NAT and other times I may not need it. But because Microsoft allows NAT to be used on only one adapter, Virtual PC adapter slot #1, I set it that way.

As you step through the other configurations you will find that there is almost always a Virtual OS adapter bound to a Host adapter by way of the Virtual PC settings. This is one of the exceptions. When you use NAT you will find that the Virtual OS needs to bind an adapter, but the Host OS does not. At least that is the way it appears in the Virtual PC settings. In reality Virtual PC is binding the first Virtual OS adapter to the primary Host OS adapter, as well as providing DHCP services. The IP address most often given to the Virtual OS adapter is 192.168.131.65. Then, as the Virtual OS pings out to the LAN from behind NAT, returning packets come back to the Host OS primary adapter. It is important to note that the primary adapter is defined as the main adapter used by the Host as NAT was engaged. If you move your laptop from a wired to a wireless connection while the Virtual OS is running, and all adapters are loaded, it's likely that Virtual PC will not keep up, and your Virtual OS will lose connectivity. You should then disable and re-enable the adapters in question. In any event, once this configuration is running as expected, the Virtual OS can get out, but no one can get in, including RDP to control the Virtual OS.

Loopback and main connections

Probably the first thing many people will do is setup a basic connection but I submit the consideration of using a loopback adapter on adapter slot two. Due to the Microsoft media sensing feature an adapter will generally drop its address once the media is not longer sensed. I’ve had this happen when a switch goes down, even though the NIC is still connected via a CAT5 cable. Or you are using a wireless connection, your laptop for example, and you need to hibernate and go home… same result. This has the nasty side effect of dropping your RDP connection to the imaged OS. You can of course open the Virtual PC console, but there is a better way.

Disabling media sensing

Before I continue, there is a way to disable media sensing in the networking configuration. Media sensing is the act of Windows turning on or off an adapter based on whether it can sense a physical connection. Sometimes I would prefer that a connection stay live even if I remove the CAT5 cable. Thus (one example) I can still ping from a Virtual OS adapter, through a binding like NAT, to another laptop adapter, even when it’s not connected to a media. I will warn you ahead of time thought that you may get "hardware error" messages at times, so it's not perfect. To do this, follow the instructions at http://support.microsoft.com/kb/239924

Set up a loopback adapter

Using the second adapter in the Virtual OS and a loop back adapter on the host OS, we can configure an unbreakable connection between your host and virtual OSs. That way when your LAN connection breaks, your RDP session does not.

1.    In the control panel of your base OS open the Add Hardware applet.

2.    Tell your PC you have already added the new device.

3.    Scroll to the bottom and click next.

4.    Choose advanced, next.

5.    Click N to help you find "Network adapters".

6.    Select Microsoft and Loopback Adapter.

7.    The following addresses are suggested settings but you can adapt as needed.

8.    Go to the Network Panel and select the new loopback adapter.

9.    Press F2 and rename it loopback(10.0.0.10).

10. Add the same address to the NIC via it's settings, skipping DNS and gateway.

11. Go into the Virtual PC settings for the intended OS and adjust for three adapters.

12. Bind the first adapter to the Microsoft Loopback Adapter.

13. Start your Virtual OS and change the settings to 10.0.0.20 for one of the adapters.

14. Now from both sides ping around until they can see each other. You should now have an unbreakable connection between your Oss by way of the loopback adapter on the Host connecting to the second adapter on the Virtual OS.

The following screen shots may assist.

Figure 1: Scenario 1 - This view shows the NAT adapter (and loopback adapter for RDP on the Virtual OS) enabled on the Virtual OS. Notice the adapter numbers correlate with the adapter slots in Virtual PC

Figure 2: Scenario 1 - A Virtual PC software binding view showing NAT and loopback bindings. Notice that adapter #1 is bound to NAT

Figure 3: Scenario 1 - A view of the Host OS configuration

If you find that you cannot ping out from the Virtual OS, start by disabling all adapters on the Host and Virtual OS, as well as the bindings in Virtual PC. Then, in this order, enable the Host adapter, the Virtual PC adapter bindings, and lastly the Virtual OS adapter, which should then get a DHCP address and the settings of the adapters upstream.

Setup the next adapters: wired and wireless

If on the other hand you do not want or need NAT, you can bind other Virtual OS adapters to Host OS adapters so that the Virtual OS acts like any other OS on the LAN. In this case you have the choice to assign a static or LAN enabled DHCP address to the Virtual OS. It is common for me to assign the Virtual OS adapter #3 to an onboard wireless LAN adapter via Virtual PC's binding settings, and setting the last one to a wired adapter. As I move from place to place I use CAT5 when I can, otherwise the wireless picks up.