After experiencing intermittent network issues with his VPC, one of my work colleagues was forced to contact our helpdesk extraordinaire to resolve the issue. We use a base VPC (.vmc + .vhd) as the foundation for our individual developer environments and the problem was traced back to the same MAC address being used by multiple VPCs. By repeatedly copying the same .vmc file, a number of us ended up with VPCs sharing a common MAC address.
A MAC address uniquely identifies a NIC at the hardware level (right down at the bottom of the network stack) and is set in the factory. The VPC world in which we live, however, means we're no longer dealing with physical hardware all the time and, as you probably know, multiple software NICs can be added to a VPC quite easily.
As a result, Microsoft Virtual PC generates a new MAC address whenever a new VPC is created and a software NIC is assigned. A VPC's MAC address is stored in the .vmc file, which is actually a valid XML file (open the file in Notepad or an XML editor). Once generated, the VPC's MAC address is stored in an element called "ethernet_card_address" and stays that way until it's either manually changed or the .vmc file is replaced.
Until we encountered this issue, we were saving both the .vmc and .vhd files as part of our development environment "base image"; had we stored only the .vhd file(s), we'd be forced to create a new .vmc file when creating a new environment. Creating a new .vmc file is a simple task and doing so would have avoided the problem encountered by my colleague. The alternative to deleting the .vmc file is to simply delete the value contained in the ethernet_card_address element of the .vmc file. Virtual PC will generate a new MAC address the next time the VPC is started.
It should be noted that while our individual VPCs now employ NICs with unique MAC addresses, the base machine was part of a workgroup and was therefore not sysprep'd. We join our VPCs to our dev domain after copying the base image.