I was recently working on an issue where after performing a successful P2V conversion, we would experience intermittent timeouts while trying to connect to or ping the new VM. We verified the IP address of the new VM, checked the DNS records, cleared the ARP cache and everything looked the way it was supposed to but yet we would intermittently timeout while trying to connect to or ping the new VM. Further investigation uncovered the fact that the new VM had the same MAC address and SID as the source computer. This could be problematic if the source computer remains on the network after the P2V conversion.
Changing the MAC address is easy enough in either the Hyper-V management console or the SCVMM admin console, but the SID is an entirely different story. Microsoft does not support changing a computers SID outside of a new deployment scenario using the Sysprep tool. Although there are third party utilities that will change a computers SID, use them at your own risk. Microsoft does not support a machine that has had the SID changed by using any such tool or utility, including the NewSID utility.
This means that the implied intent of a P2V conversion is that the source computer be re-provisioned immediately upon completion of the P2V process or at the very least taken off the network. While this may be obvious to most people you would be surprised at how many people continue to keep their source machines active and on the network after completing the P2V process.
Sr. Support Escalation Engineer
Enterprise Platforms Support | SCVMM | Cluster
I was recently working on an issue where after performing a successful P2V conversion, we would experience