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
/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
In the control panel of your base OS open the Add Hardware applet.
Tell your PC you have already added the new device.
Scroll to the bottom and click next.
Choose advanced, next.
Click N to help you find "Network adapters".
Select Microsoft and Loopback Adapter.
The following addresses are suggested settings but you can adapt as
Go to the Network Panel and select the new loopback adapter.
Press F2 and rename it loopback(10.0.0.10).
the same address to the NIC via it's settings, skipping DNS and gateway.
into the Virtual PC settings for the intended OS and adjust for three adapters.
the first adapter to the Microsoft Loopback Adapter.
your Virtual OS and change the settings to 10.0.0.20 for one of the adapters.
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.
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
Figure 3: Scenario 1 - A view of the Host OS
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.