After you configure the new VM, you just need to turn it on—click the Master Status link, then put the cursor over the name of your newly created VM and select Power On to start the new VM. To control the live VM, click the VM's thumbnail on the Master Status page. To simulate the Ctrl+Alt+Del keystroke sequence, press the right Alt key, then press the Del key. To exit the VM, press the right Alt key on your keyboard (you can change this default key, if desired).
At this point, you need to install an OS for the VM, just as you would need to do for any physical system. During the OS installation, make sure you configure the network interface to use an IP address on the VM host's virtual network. For the first VM on the virtual network, I assigned it an IP address of 10.1.0.2/24 and listed its default gateway as 10.1.0.1. The 10.1.0.1 address was assigned to the Microsoft Loopback Adapter, which will act as the gateway for all VMs on the 10.1.0.0/24 network. Because my NT 4.0 VM was replacing a physical production NT server called BSOD, I assigned the name BSOD to the VM.
After you install a base OS, you might want to consider using Sysprep on the system, then running the DuplicateVM.js script to create a new base image VM. You can then use the cloned sysprepped VM as a baseline for any additional virtual NT servers that you need to set up.
Migrating Applications
Now that the OS is running, you can move on to migrating the applications. Note that we haven't yet joined the VM to the production domain—doing so while the production server is still online would lock out the production server's computer account because joining a computer to a domain automatically regenerates a new computer account password for that system object. As a result, the production system's computer account password would no longer match the password stored on the DCs. This mismatch would cause authentication between the production system and DCs to fail until the production system is rejoined to the domain, which in turn would lock out the VM. To migrate an application, I prefer to perform a clean installation of the application on the new VM. Following the installation, you can then copy any data saved by the application onto one of the VM's hard disks. If the application data is locked, you can alternatively use backup software to back up the application data on the production server, then restore the data to the VM.
After you transfer the application and data to the new VM, you can test the VM to ensure that it performs as expected. When you're satisfied that everything is working properly, you can join the VM to the domain, update your DNS records, and ensure that all clients can successfully route to the VM. At this point, your virtual transition is finished. You can now use the DuplicateVM.js script to create and store a backup copy of the VM. Then, if a system crash occurs, you can just start the backup VM and restore any recently backed up application data. (For more information about backing up files to a VM, see the sidebar "Integration with Backup and Recovery.")
Keep in mind, however, that you can run into problems when working with two instances of the same virtual system. For example, if a domain controller (DC) changes the computer account password for one version of the VM, you'll have to manually rejoin the backup VM to the domain. To prevent the periodic reset of your VMs' computer account passwords, open a registry editor on each VM, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey, and change the DisablePasswordChange entry value to 1.
Migration Made Easy
If you simply want to clone a production system to a VM, you can use the Physical to Virtual Wizard to do so. The wizard will let you clone a physical system to a VM and test it as a VM during the migration process, removing any negative effects on production. When you're satisfied with the performance of the VM, you can decommission the production server. Another excellent use for the Physical to Virtual Wizard is to clone NT servers before you upgrade them. This way, if a server crashes during the upgrade process, you can bring its cloned VM online as a temporary replacement until you repair the physical server.
Microsoft is making sure that the Physical to Virtual Wizard solution successfully clones Microsoft applications. However, you'll want to carefully evaluate other cloned applications running on the new virtual server before you remove the production system.
Microsoft also plans to include a Virtual to Physical Wizard and a Virtual to Virtual Wizard in Virtual Server. The Virtual to Physical Wizard will be ideal for testing a new server before you place it on a physical production server, and the Virtual to Virtual Wizard will let you easily clone VMs. For example, you'll be able to set up a default VM, run Sysprep, then use the Virtual to Virtual Wizard to copy the VM to a new VM and have a clean virtual OS within minutes.
Prev. page
1
2
[3]
4
next page 
