Using Virtual Server 2005 in Desktop Deployment
By Jerry Honeycutt
.jpg)
Microsoft is trying to change your life-again. Once in a while, the company produces a technology or product that I consider life changing. A subtle example is Microsoft Office Outlook 2003. The product forever changed not only how I manage e-mail but how I manage my time. Microsoft Virtual Server 2005 is a more recent and far less subtle example, however, especially when it comes to developing and testing desktop deployment projects.
My first article for this community is about Virtual Server 2005. Many of the columns you'll see in this community will be based on techniques that were developed and tested using Virtual Server 2005, which is all the more reason to start with this topic. This column should leave you convinced that using the product to develop and test your next project is an easy decision.
Dump the Old Labs
Think back to your last deployment project. You built a deployment lab, which involved a lot of hardware and a more-than-reasonable amount of patience. Depending on the size of your project, you had to build separate work areas for each deployment team, and you provided the infrastructure the teams needed to work together.Maintaining the whole lab was more than a little messy. Resetting configurations (which happens often when developing and testing desktop deployment projects) took a good deal of time. Of course, this is true of most other technology projects, such as testing application compatibility and developing fixes, verifying security updates before deployment, and so on.
You can use Virtual Server 2005 to address these challenges, like I have. Virtual Server 2005 makes setting up a complex lab environment straightforward, and reconfiguring the lab is painless in comparison to live labs. For example, it used to take me a few hours to install, configure, and break down a lab for compatibility testing. Using Virtual Server 2005, I accomplish the same tests in minutes. In addition, you can easily coordinate virtual lab use between various teams, and you don't even have to get up from your desk to do it.
Get Started with Virtual Server
For information about buying Virtual Server 2005, see Virtual Server 2005 Pricing and Licensing. MSDN Universal subscribers currently have access to the product through a special offer. In any case, Virtual Server 2005 is a bargain even at full price given the value it provides.
When you create a virtual lab using Virtual Server 2005, monitor licensing. You must ensure proper software licensing for your virtual lab, just as you do for your live lab.
.gif)
I recommend that you dedicate hardware to the project team for Virtual Server 2005. Minimum hardware requirements for Virtual Server 2005 are documented in the Virtual Server 2005 Administrator's Guide. Installing the product on hardware that just meets these minimum requirements isn't useful, though, particularly in shared-use scenarios. The general rule of thumb is, the more, the merrier. The number of virtual machines (VMs) you can run simultaneously is primarily limited by the memory and muscle contained in the physical hardware. Virtual Server 2005, Standard Edition runs on computers with up to four processors, while the Enterprise Edition runs on computers with up to 32 processors. The product can use up to 64 GB of memory, and it supports up to 3.6 GB of memory per VM.
The test team for Microsoft Solution Accelerator for Business Desktop Deployment (BDD) version 2.0 used four-processor servers, allocating one processor for each of three guest operating systems and one processor for the host operating system. The test team found that 512 MB of memory per operating system was a good balance, and they configured the host server with a minimum of 2 GB of memory. Of course, the guest operating systems provided every kind of role you can imagine, including the Microsoft Active Directory directory service, Web server, Microsoft Systems Management Server, and Microsoft Operations Manager.
After you've acquired Virtual Server 2005 and configured the hardware to run it, installation is simple. In a nutshell, you must first install Microsoft Internet Information Services (IIS), then install the Virtual Server 2005 package. (For complete step-by-step installation and configuration guidance, see the Virtual Server 2005 Administrator's Guide.) Note that you can install the Virtual Machine Remote Control (VMRC) client on any computer, even if that computer isn't running Virtual Server 2005, by customizing feature-installation states during installation.
It took me a little more than an hour to install Microsoft Windows Server 2003 and configure it as an application server. Installing Virtual Server 2005 took only a few short minutes, and there really aren't many design choices you must make for a straightforward configuration. I do have a couple of recommendations based on my own experience, however:
For best performance, add a separate, high-speed drive to host the virtual hard disks. Don't store virtual hard disks on the partition containing the operating system or any other partition that is heavily used.
Configure your antivirus software to exclude .iso, .vfd, .vhd, .vud, and .vsv file types. Excluding these files from real-time virus scanning improves performance.
Limit the number of services and applications running in the background. The idea is to make as much memory and processor cycles as possible available for VMs.
Make sure Virtual Server 2005, the administration website, and VMs are secure. For more information about security, see the Virtual Server 2005 Administrator Guide.
Install Virtual Server 2005 to run the administration website using the local System account. Doing so allows you to use constrained delegation, which is required for accessing resource files (ISO, VFD, and so on) on other computers. For more information, see Configuring constrained delegation in the Virtual Server 2005 Administrator Guide.
Frequently defragment the disk containing the virtual hard disks as well as the virtual hard disks in the VMs. Doing so improves performance, particularly when you're using dynamically expanding virtual hard disks.
Configuring for Desktop Deployment
The following list describes some of the best practices and tips I've assembled while using Virtual Server 2005 to develop and test desktop-deployment projects:
Create a library of VMs and virtual hard disks that contain desktop configurations typically found in the production environment. You can quickly load and start these VMs to test the project. Include in this library VMs and unformatted virtual hard disks that you can quickly copy to test bare-metal deployment. Also include frequently used virtual floppy and hard disks, such as a Remote Installation Service (RIS) boot disk and a Microsoft Windows Preinstallation Environment (Windows PE) boot CD.
Use undo disks liberally to make resetting a configuration or starting a test over fast. For example, you can test deployment to a VM running Microsoft Windows 98. Then, to delete your changes and restore Windows 98 to the computer, discard the undo disk (a process that takes only a few seconds).
Isolate the virtual lab by creating an internal virtual network. Simulate production servers-including domain controllers, servers, and desktop computers-in the virtual network. Wherever possible, simulate every detail ? even the server names ? so that your tests are more representative and keeping track of the results is easier.
Provide Internet access to a virtual network by installing a loopback adapter on the host server and then connecting a virtual network to it. On the host computer, you can use Internet Connection Sharing or Routing and Remote Access Service (RRAS is more flexible) to provide Internet access to the loopback adapter. For more information about using loopback adapters with Virtual Server 2005, see Using Microsoft Loopback Adapter in the Virtual Server 2005 Administrators Guide.
Use Virtual Private Network (VPN) connections to share files on the production network. Virtual Server 2005 doesn't allow the host and VMs to share folders. If you installed a loopback adapter and connected it to the virtual network (see the previous bullet), you can create a VPN connection to the production network, then exchange files with it. This is a simple way to move test files in and out of an isolated virtual network.
Install the Virtual Machine Additions. This isn't really a tip as much as it is a reminder. Installing the additions enhances the experience enough to make this step a necessity. For that matter, add the additions to your disk images so that they're installed automatically. You can remove them when you're ready to deploy the project to a production environment.
Change Development Forever
Virtual Server 2005 has changed how I develop and test desktop-deployment projects. I'd certainly say that Virtual Server 2005 is a life-changing product.Ashish Java, Project Manager, Infosys Technologies Ltd., used Virtual Server 2005 to test the Solution Accelerator for BDD 2.0. According to Ashish, he "benefited most from the undo disks features, which came in handy as I jumped from version to version of the code. The code sometimes changed two or three times a day, and undo disks was a huge blessing because manual installs could take as long as an hour." Virtual Server 2005 helped streamline testing.
It has also changed how I learn new technology, test applications for compatibility, test security updates, and so on. When all I have to do to test a product or configuration is start a VM and run the test, nothing is standing in my way. (I would often forego testing a product or technology because I didn't have time.) And if things don't go my way, I can simply discard the undo disk and start over. A process that used to take hours often takes little more than minutes by using Virtual Server 2005.
The columns you will see in this community will describe numerous products and technologies. Keep in mind that most of them will have been developed and tested by using Virtual Server 2005. And when the opportunity arises, we'll give you tips for working with ideas and technologies in a virtual environment.
For More Information
Discussions in Desktop Deployment
Ask your desktop deployment questions here. Discuss deployment tips and best practices with your peers, and give feedback on articles that are featured in the Desktop Deployment Center.
About the Author
Jerry Honeycutt is a writer, speaker, and technologist. He has written more than 25 books, including Microsoft Windows Desktop Deployment Resource Kit (Microsoft Press, 2004). Jerry's consulting practice is in the Dallas area, but he travels frequently. For more information about Jerry, see his complete bio, visit https://www.honeycutt.com, or contact him at jerry@honeycutt.com.
.gif)
.gif)