You might want to create a “base” virtual machine with an operating system and applications, and then copy its .vhd file to use for other virtual machines. Before you make copies of the .vhd, however, it’s important to run Sysprep in the guest operating system. This way, the first time you start a virtual machine that uses a copy of the base virtual machine’s .vhd file, the guest operating system will be assigned a new SID and other identifiers, so you won’t end up with network conflicts between different virtual machines that use the same copied .vhd file.

Read all about it in the article I just posted in the "Deployment" category at http://blogs.technet.com/megand/articles/357570.aspx.

Please note that Microsoft does not support using a tool other than Sysprep for cloning virtual machines. For more information, see this Knowledge Base article: http://support.microsoft.com/Default.aspx?id=162001.

I learned how to do this at TechEd 2004 in a lab led by Robert Larson, one of our resident Virtual Server gurus.

You can create a “base” virtual machine with the operating system and applications you want, and then copy its .vhd file to use for other virtual machines. When you do this, it’s important to run a tool called Sysprep on the base virtual machine. That way, when you start a virtual machine that uses a copy of the base virtual machine’s .vhd file, the guest operating system will be assigned a new SID, GUID, MAC address, and so forth when it starts up. This way you won’t end up with network conflicts between different virtual machines that use the same copied .vhd file.

Important Notes:

• Do not perform this procedure on the host computer!! Perform it only within the guest operating system of the virtual machine you want to clone.
• Microsoft does not support using a tool other than Sysprep for cloning virtual machines. For more information, see this Knowledge Base article: http://support.microsoft.com/Default.aspx?id=162001.

Step 1: Install the Setup Manager files in your guest operating system

1. Set up a base virtual machine by installing the operating system, service pack, patches, applications, and so forth that you want to clone.
2. Start the guest operating system and log on as a local administrator.
3. From the guest operating system, go to the Microsoft Web site and download the appropriate Sysprep version. Extract the files to a folder such as C:\Tools on the guest hard disk. You can obtain the SysPrep files from the following locations:
   Windows 2000:  http://www.microsoft.com/windows2000/downloads/tools/sysprep/default.asp
   Windows XP:  http://www.microsoft.com/downloads/details.aspx?FamilyID=7a83123d-507b-4095-9d9d-0a195f7b5f69&DisplayLang=en
   Windows XP SP2 and Windows Server 2003:  http://www.microsoft.com/downloads/details.aspx?FamilyID=3e90dc91-ac56-4665-949b-beda3080e0f6&displaylang=en&Hash=RWRPDM9

Step 2: Create an answer file

Note: This procedure applies to the Sysprep version for Windows Server 2003. You’ll need to modify the steps for other versions of Sysprep. The files that you extracted from the Microsoft Web site include a help file named Deploy.chm that has specific information for your version. It's a good idea to read the help file and become familiar with this tool and figure out how to customize the following steps for your own environment and purposes.

1. In the Tools folder on the local disk of the guest operating system, double click Setupmgr.exe to start the Setup Manager wizard.
2. Click "Next."
3. Select "Create New" and click "Next."
4. Select "Sysprep Setup" and click "Next."
5. Select the type of guest operating system and click "Next."
6. Select "Yes – Fully automate the installation" and click "Next."
7. Type a name and organization, click "Next."
8. Accept the default display settings by clicking "Next."
9. Select your home time zone and click "Next."
10. In Product Key type the product key and click "Next."
11. In licensing, select the type of license for the guest operating system, and click "Next."
12. Type a computer name for the guest operating system and click "Next."
13. Set the administrator password and click "Next."
14. To ensure that the password will be set, the machine’s password must be blank.  Press Right-ALT + DEL and click "Change Password." Type the old password and leave the new password blank. Click "OK."
15. Select "Typical Settings" and click "Next."
16. Leave the machine in a workgroup and click "Next."
17. Customize the next few screens of additional settings as necessary. If you don't know what they're for, accept the defaults.
18. In "Identification String" type the computer name and click "Finish."
19. Specify C:\Tools\Sysprep\sysprep.inf for the location for the .inf file.
20. Click "Cancel" to close the Setup Manager wizard.
21. You now have a C:\sysprep folder with your sysprep file and copy stored at C:\tools\sysprep\sysprep.inf.  
    Copy Sysprep.exe and Setupcl.exe from C:\Tools\Sysprep to C:\Sysprep.

Step 3 – Sysprep the guest operating system

1. Close all windows in the guest operating system.
2. Click "Start" and then "Run."
3. Type C:\sysprep\sysprep.exe and press Enter. 
4. This starts the Sysprep process. Click "OK" to clear the warning dialog.
5. Select "Do not reset grace period for activation."
6. Make sure that the shutdown mode is "Shutdown."
7. Click "Reseal."
8. When prompted about regenerating SIDS, click "OK." The guest operating system will be Sysprepd and will automatically shut down.
9. Remove the base .vhd file from the virtual machine, and in the file system, make the base.vhd file read-only. You need to do this because you do not want to start a virtual machine by using this base .vhd file. If you do, it will undo the whole process that you just went through.

You can now make copies of this .vhd file and attach them to different virtual machines. After you copy the .vhd file, you need to remove the copy’s read-only attribute. When you start a virtual machine with a copied .vhd file, it will receive a unique SID and other identifiers. You can also use the base .vhd file as the parent drive image for several differencing drives. The unique identifiers for each guest operating system built in this way will thus be written into the differencing drives, and not the parent.

Note: The fourth time you run Sysprep on the same media, you receive the message, "Your grace period limit has been reached and will not be reset." For more information, see http://support.microsoft.com/default.aspx?scid=299840.

I know this is slightly off topic, but Windows Server User Assistance has a number of openings for technical writers, and if we fill the positions, I'll have more time to write in this blog. To qualify, you need to have a strong background and preferably hands-on experience in IT, in addition to excellent writing skills. The positions are all located in Redmond. For more information, go to the Career Center on the Microsoft Web site.

Using virtual machines for software development, software testing, and patch testing is really catching on at Microsoft – and for good reason:

• Hardware goes farther: Using virtual machines instead of physical hardware allows you to do more testing with fewer resources. Note that this isn’t a universal panacea because some testing scenarios must be performed on physical hardware.
• Test scenarios are quick to deploy: If you create a library of .iso images and/or .vhd files to use as base configurations, virtual machines are quick to deploy. Note that you need to run SysPrep on the operating systems that you want to clone so that the guest operating systems receive a unique GUID and MAC address when they start up. Otherwise, you’ll end up with conflicts.
• Virtual machine memory state can be retained when turned off: By saving its state, you can “stop” a virtual machine and reclaim the CPU and memory resources it was using on the host, while preserving your test scenario. You can then quickly restore the virtual machine from its saved state when you need it again, and continue your test. Note that disk space is required to store the virtual machine’s memory contents. Also, you can’t transfer a virtual machine in a saved state between two computers that have different CPU architectures, such as Pentium and AMD. To transfer the virtual machine in this scenario, you have to restore it from the saved state and then shut it down.
• It’s easy to roll back changes: Using undo disks, you can create a complete environment and then quickly roll back any changes you make to it. Your options are to keep your changes, commit the changes back to the parent disk, or discard your changes. Note that it isn’t a good idea to use undo disks with domain controllers because this rolls them back in time :( - not to mention that it isn’t supported by Microsoft.
• You can create multiple configurations with a single base image: You can configure your base image and then create differencing disks that use it as a parent. On the differencing disks, you can install additional software, upgrade the operating system, install patches, and so forth, without affecting the base image. You can also chain differencing disks to set up complex scenarios, for example Windows Server 2003 (base), Windows Server 2003 SomePatch 1 (differencing disk), and Windows Server 2003 SomePatch 2 (second-level differencing disk). As appropriate, you can then merge the differencing disks either back into the parent disk or into a new .vhd. Note that when you use differencing disks, it’s VERY important to mark the parent disk as read-only. If you don’t and anyone makes a change to it, all of the child disks become invalid, and you have to start over. Also remember that if you want to clone a disk, you need to run SysPrep on it first.
• You can configure named pipes for your virtual machine COM ports for use with debugging tools.

Here are some tips for testers and developers:

• Always install Virtual Machine Additions. This is a basic step for every virtual machine deployment, and not just for testing, but I bring it up because it’s so easy to forget.
• Patch your virtual machines. Virtual machines are just like real machines and will catch viruses. Treat all virtual machines as separate computers for security and patches. Our Virtual Server test team uses the following approaches for patching their virtual machines: Load the patch management system on the host and have it patch the virtual machines, load the patch management system on the virtual machines and dual home them on public and isolated segments, or use Internet Connection Sharing (ICS) to create a virtual Network Address Translation (NAT) environment with Loopback adapter, and have the virtual machines patch themselves.
• Use SysPrep on guest operating systems you want to clone. For more information, see my article at http://blogs.msdn.com/megand/articles/357570.aspx.
• Use the COM API to automate your test environment deployment, as described in this MSDN article by Ben Waldron: http://msdn.microsoft.com/msdnmag/issues/04/08/VirtualServer2005/.
• Use at least two network adapters: one for the host and one dedicated to the virtual machines for public network traffic. Add more network cards to support more network traffic.
  Use Loopback adapter to isolate virtual machine traffic from the host or create isolated subnets. Use Windows Server 2003’s Routing and Remote Access Service (RRAS) in a virtual machine for routing between virtual networks.
• For some basic background on using virtual machines for testing, read this article about testing with Virtual PC: http://www.windowsecurity.com/articles/Microsoft-Virtual-PC.html.
• Read the documentation. :)  It has loads of helpful stuff in it.
  

You probably already know that Virtual Server provides a complete set of COM interfaces for programmatic management (see Start > All Programs > Microsoft Virtual Server > Virtual Server Programmer's Guide). But did you know about the Virtual Server script repository on TechNet? It contains sample scripts for tasks such as managing virtual hard disks, configuring Virtual Server and virtual machines, configuring security, and managing virtual networks.You can find the repository at http://www.microsoft.com/technet/scriptcenter/scripts/vs/default.mspx.

Here's what Kurt Schmucker, the program manager for Virtual Server 2005 Service Pack 1 says about the release:

"As with typical service packs from Microsoft, Virtual Server 2005 Service Pack 1 will be primarily a rollup of fixes we have seen since the product was released to improve performance and increase scalability. In addition, with Service Pack 1, Virtual Server 2005 will have host support for Windows Server 2003 Service Pack 1 x64 Edition (note that this does not include IA64), provide PXE support, qualify Windows XP SP2 as a host and as a guest, and include the Virtual Disk Precompactor, a utility that is designed to "zero out" — that is, overwrite with zeros — any available blank space on a virtual hard disk. A public beta is slated for the end of first quarter 2005, with product release planned for the second half of calendar year 2005."

You can attach each virtual machine running under the same instance of  Virtual Server to a separate physical network and also isolate the virtual machine network traffic from the host, as follows:

1. On the network adapters (NICs) to which you will attach your virtual machines, unbind all services except the Virtual Machine Network Service. Instructions are below.
2. On the NIC that you will use for the host, unbind the Virtual Machine Network Service.
3. Connect each NIC to a separate physical network.
4. Connect each NIC (except the one used by the host) to a separate virtual network.
5. Connect each virtual machine to the appropriate virtual network.
6. In the guest operating systems, configure the network settings, such as IP address, submask, gateway, DNS, etc.

To bind or unbind the Virtual Machine Network Service from a NIC:

1. On the host computer, click "Start," click "Control Panel," and then click "Network Connections."
2. Right-click the connection that uses the NIC you want to configure and click "Properties."
3. On the "General" tab, select or clear the check box for the service to bind or unbind, and then click "OK."

Note: You can isolate virtual machine network traffic from the host at any time by unbinding Virtual Machine Network Services from the NIC used by the host. For more information about network isolation, see "Virtual network architecture" in the Virtual Server 2005 Administrator's Guide.

For general information about configuring networks for virtual machines, see "Accessing virtual networks from a virtual machine" and "Creating a virtual network" in the Virtual Server 2005 Administrator's Guide.

HP is delivering a live Webinar on January 14, 2005 on Virtual Machine Management. Here's the description from HP: "Learn the advantages of virtual machine technology and understand how the Virtual Machine Management Pack allows you to manage and control the VMWare and Microsoft Virtual Server resources in your environment." To register, go to http://www.hpbroadband.com/program.cfm?key=Q91MTB88Y.

John Howard has posted a series of blogcasts (e.g., video clips published on a blog) that walk you through the process of using VSMT to migrate a Windows NT 4.0 server into a virtual machine running under Virtual Server 2005. You can find them on his blog at http://blogs.msdn.com/jhoward. The first blogcast of the series is at http://blogs.msdn.com/jhoward/archive/2005/01/04/346147.aspx.

Great job, John. Thanks!

Although there are high-level instructions on performing a migration in the VSMT whitepaper (http://www.microsoft.com/windowsserversystem/virtualserver/overview/vsmtwhitepaper.mspx), if you're going to do a serious migration, you need to follow the detailed documentation in the "Virtual Server 2005 Migration Toolkit User's Guide." You'll find it at %ProgramFiles%\Microsoft VSMT\Help\VSMT.chm. This documentation will get you reliably from here to there, and if you have problems, the issue is very likely covered in the Troubleshooting topic. If it isn't, please let me know. 

Also, for some guidance with planning a migration and capacity planning, be sure to read the "Solution Accelerator for Consolidating and Migrating LOB Applications," available at http://www.microsoft.com/technet/itsolutions/ucs/lob/lobsa/default.mspx.