This week I spent a day looking at P2V-ing NT4 Terminal Services Edition (Service Pack 6) with Citrix MetaFrame...
1.8 with remapped drives.
I was pleasantly surprised, as I wasn’t expecting to see this work. Firstly, NT4 TSE isn’t officially supported with VMware’s P2V product. Additionally, NT4 TSE isn’t officially supported on ESX 2.x.x.
Anyway, I tried first the VMware P2V Boot CD and it correctly detected my hardware and I cloned the physical machines disk to the virtual machine disk, using the “Direct-to-Device” method. The most important thing was remembering to engage the option X Attempt to preserve drive on the letter to volume assignment. This allowed the P2V’d virtual machine to carry on using the M: drive assignments.
Many people find the VMware P2V Boot CD doesn’t recognize their hardware, so they are forced to go down the route of using Symantec Ghost (or something similar) usually using BartPE as a boot-CD with the appropriate drivers and plug-ins. The key thing to mention here is if you're using VMware’s P2V Assistant to perform the “system reconfiguration”, the option for X Attempt to preserve drive letter to volume assignments will NOT be available.
So during the cloning process with Symantec Ghost be sure to engage the “Force Disk Signature Preserve” Switch (this is usually -FDSP in Symantec Ghost). This will ensure that the driver letter assignment remains the same (M:) rather than being reset (C:)
The same applies to those of you using “Ultimate P2V” (called by some UP2V).
During the cloning process, I noticed that whatever the method, other partitions (apart from the OS) do get reset to C: D: and so on. This is relatively easy to fix by opening “Disk Administrator” and reseting them back to the original drive letters of N: O and so on. Also, I noticed that the CD-ROM drive letter remained unchanged. This is strange, but true. The main thing is that the OS partition remains the same, otherwise broken shortcuts and applications will ensue.