by
Michael Burke
Most IT Professionals agree that having a lab for proper testing and staging is crucial to a stable, successful Citrix environment. However, some may argue that labs are complicated, costly and seemingly unjustified. Although these may seem like valid points, the risk of having your production environment come crashing down due to an untested patch or software upgrade proves that it's well worth the time and cost of setting up a lab.
A lab is a great tool to have at your disposal. You can use it to test a new software release or security patch or possibly a new printer driver that a client is requesting. Perhaps you just want an environment where you can learn more about the inner workings of Citrix, Web Interface or Secure Gateway. If you'll be faced with upgrading your production environment to MetaFrame Presentation Server 3.0, it’s best to do a “dry run” in a lab before victimizing your production environment and possibly causing serious downtime.
Many times, people don't build labs because there is no spare hardware, no space available, or simply no time to commit to assembling a lab. However, with the advent of server virtualization, building a lab can be accomplished with significantly less hardware and in a much shorter amount of time.
The Benefits of Virtualization
The term “virtualization” refers to the method of disconnecting the operating system from the physical server hardware and inserting a “virtualization layer” between the two. The virtualization layer presents a defined collection of virtual hardware to the virtual machine’s operating system and acts as mediator between the virtual “guest” operating system and the host computer running the virtualization software.
The virtualization industry is currently dominated by two main players: VMware, who has been in the virtualization market since 1998, and Microsoft, who purchased Connectix and as a result has released VirtualPC and Virtual Server products. Although products from both Microsoft and VMware will work well in a lab, this article will focus on the VMWare Workstation product for the sake of simplicity.
Virtualization provides many possibilities in your lab that physical machines cannot offer. For instance, you can use VMware you can create “snapshots” of your virtual servers, essentially preserving a point-in-time that you can revert back to later. In addition, VMware you can run multiple virtual machines on a single piece of hardware. Instead of a lab containing six machines performing various roles, you may need only one or two pieces of hardware to support the entire lab in a virtual environment.
VMware is available in several versions including VMware Workstation, GSX Server and ESX Server. VMWare Workstation is their least expensive product, costing less than $200. It's intended for training and testing purposes and is well suited for lab environments. VMware GSX Server is very similar to VMware Workstation, but it includes additional features to support a production environment such as automatic startup and shutdown of virtual machines based on the host server’s actions. GSX can run on either Windows or various versions of UNIX and Linux. Virtual machines can also be managed remotely with the GSX Server Virtual Machine Console, while VMware Workstation only allows the virtual machines to be managed at the console of the host computer itself.
VMware ESX Server is VMware’s enterprise-class product and is well suited for any environment serious about virtualization. The most notable difference between ESX Server and GSX Server/Workstation is that ESX Server does not run on a standard “hosted” operating system. (Both GSX Server and Workstation are “Hosted” solutions in that they require a host operating system to be installed on the hardware prior to loading the VMWare product.) ESX Server is loaded directly onto the hardware and has its own microkernel operating system. VMware GSX Server and ESX Server are licensed based on the number of processors in the host server computer and typically run $2500 and $3800, respectively, for a 2-processor license.
Determining What Needs to be in the Lab
When creating a lab, you first need to define its role and how you anticipate using it. For example, the lab might only need to serve as a place to test new software releases and/or security patches. Another possibility might be the need to duplicate the production environment as closely as possible, even to the point of creating a completely autonomous testing environment that’s isolated from the production network.
When deciding what to include in the lab, consider what it would take to reasonably replicate the production Citrix environment. In its simplest form, this would include at least one Citrix servers (preferably at least two so you can test load-managed scenarios), but could also include the Web Interface, Secure Gateway, or back-end servers (such as database servers, workflow processes, etc.). If the lab is going to be completely isolated from your production network, you'll also need to include a domain controller for user authentication or a file server for storage.
MetaFrame Servers
The MetaFrame servers will obviously be at the core of the lab, however, they don’t need to be as high-powered as your production servers. Remember, their purpose is to test changes and updates, so you will only need to maintain a few connections to the servers. The real decision here is whether or not these servers will be part of your existing Citrix farm or if you will need a separate farm just for the lab.
It is perfectly acceptable to add the lab servers to your production Citrix server farm. If you do this, keep in mind that the connections used for testing will be taken from the pool of available licenses on the license server which will decrease the number of concurrent connections available to the production servers. Also, be careful that you don’t unintentionally include the lab Citrix servers when publishing production applications. One option may be to restrict access to the lab servers by setting permissions on the ICA-TCP Connector to a specific group of users responsible for testing.
Alternatively, you may want to create a completely isolated farm from the production server farm. In MetaFrame 3.0 environments you can create a completely separate server farm from the production environment and have the two farms share a single license server thanks to cross-farm licensing. Applications are published autonomously of each other--the only limitation is that connection licenses are still shared among users connecting to both the production and lab server farms.
Regardless of the farm setup choices, the Citrix labservers should mirror the production servers’ installed applications and configuration as closely possible since applications can sometimes interfere with one another. For example, if applications A, B and C are loaded on a particular server in the production environment, those same applications should be loaded on the lab server to emulate how the production environment might behave. You will want to pay close attention to this if you have any particularly sensitive applications.
Application / Back-End Servers
Back-end servers may be required for certain applications to work properly. It may be acceptable to use the production back-end servers to support the lab Citrix servers. However, if you typically patch and/or upgrade these back-end servers when you upgrade the application on the Citrix servers, you would most likely want to include a back-end lab server as well. This might also be the case with any database-driven applications--you wouldn’t want to risk a new patch or software update accidentally corrupting the production database. Also, having back-end machines duplicated in the lab typically allows you to perform all of your testing during work hours when users are using the production systems. If you need to do your testing using the production back-end servers, you more than likely will be spending more nights at work than at home.
Additional resources to consider for the lab might include a file server, print server, or domain controllers, depending on whether or not the lab is isolated from the production network.
Web Interface and Secure Gateway
The Web Interface is one of Citrix’s greatest free add-ons to MetaFrame. Not only does it simplify access to published applications, it’s an easy way to deploy the ICA client to your users. If you want to test a new version of the ICA client and its deployment or experiment with the Java client or Program Neighborhood Agent, the lab is the place to do it without adversely affecting the production environment.
Secure Gateway is another Citrix jewel. It tunnels your ICA connections over SSL and it acts as an “ICA relay” server, masking the Citrix servers behind it while exposing only a simple SSL connection to the Internet. There are three components to Secure Gateway: the Web Interface, the Secure Gateway, and the Secure Ticketing Authority (STA). The Web Interface presents the published application list to clients. The Secure Gateway server is responsible for encrypting the traffic between the Citrix server farm and the client devices, and the STA is responsible for generating authentication “tickets” to pass within the ICA files that the Web Interface generates. (This prevents the need to transmit actual usernames and passwords within these files.)
If you haven’t set this up, a lab is a great place to get started. Best of all, the Web Interface and Secure Gateway services can easily be combined on the same server. In fact, the Secure Ticketing Authority (STA) can also be combined with either the Web Interface/Secure Gateway or another machine in the lab such as a MetaFrame server. To consolidate these services, just ensure that each Secure Gateway component is assigned a separate TCP/IP port.
Setting up the Lab
For the sake of this article, we'll utilize VMware Workstation 4.5 to set up a lab that consists of one virtual Citrix MetaFrame 3.0 server in a new farm and configure it to use the production Citrix Licensing server. We'll then create a second virtual server to support the Web Interface and Secure Gateway services.
You'll need a machine (or multiple machines) to act as your virtual machine host system(s). Ideally, this would be server-class hardware, such as an hp DL380 or a Dell PowerEdge 2650. However, spare server hardware can be scarce, so PC-class hardware can be substituted as well. Remember that whatever machine you choose, the performance of your virtual machines will be determined by the host-server capabilities. You'll need a lot of RAM and fast hard disks. I prefer to have at least 2GB of memory to allow plenty of room for virtual machines to grow. Considering the price of RAM these days, a minimum of 1 GB in your host system should not be too difficult. As for the hard disks, a perfect world have a server-class machine with a nice, fat RAID 5 or RAID 10 array with plenty of free space. However, one or two 7200 RPM (or faster) hard disks and an inexpensive ATA RAID card would do very nicely.
For portability, if you have a laptop with at least 1 GB of RAM, there's nothing better than being able to take the lab with you. With VMware you can have many different configurations loaded and available at any time. It's always impressive to show up at a client's site with a fully functional lab in your bag.
Once the hardware is chosen, load the operating system and install VMware Workstation. VMware Workstation can be installed on either workstation or server-class operating systems, so if licensing costs are an issue the host OS can be Windows 2000 Professional or Windows XP. The version of the host operating system has no bearing on the virtual machine operating systems; a Windows 2000 Professional host system can easily support Windows Server 2003 guest operating systems.
The VMWare installation is very simple--just launch the installation and follow the on-screen prompts. Once completed, you'll be ready to install the virtual machines, but first let’s quickly review what makes up a virtual machine.
The Virtual Machine
Virtual machines (referred to as “guests”) consist of a set of files including a virtual hard disk file, a virtual machine configuration file, an NVRAM file (that contains the virtual machine BIOS information), and a log file. It may also include various other files to hold snapshot data, lock files, etc.
The two main files are the virtual disk file and the configuration file. The virtual machine configuration file is a .VMX file that is similar to an .INI file and contains all information about the virtual machine, such as the name, amount of RAM, virtual disk location, etc. The virtual disk file is the largest file in the group and is basically a flat file that contains all data on the virtual disk.
A virtual disk can be configured to either dynamically increase the size of the virtual disk file as needed or allocate all disk space to the file at the time of creation. The optimal choice is to allocate all virtual disk space at the time the virtual disk is created as this will prevent fragmentation of the virtual disk file. This contiguous virtual disk is actually made up of two files: the virtual disk flat file and the virtual disk configuration file. Both files have a .VMDK extension, however one file is the actual virtual disk and the other is simply a configuration file that identifies the name, location, geometry, adapter and version information for the virtual disk flat file.
Creating a New Virtual Machine
Open the VMware Workstation Console and run the New Virtual Machine Wizard to create the first virtual machine. Although there are many options that can be configured when setting up a virtual machine, the details of a virtual machine setup are beyond the scope of this article and since VMware is intuitive, I'll leave this up to the masses to get in and tinker with all the options and settings.
Step through the wizard to configure the virtual machine operating system type, the amount of RAM, networking options, and virtual disk type and size. Remember that for better virtual machine performance, it is best to use the “Allocate all disk space now” option when creating your virtual disk to prevent .VMDK file fragmentation. Also, keep in mind that you don’t need to create unnecessarily large virtual disks. As a best practice, keep the virtual disk small, typically 4GB and 6GB for Windows 2000 and Server 2003 respectively. When building your virtual machines, partition the entire virtual disk as a single logical drive for the operating system. If you need additional disk space for applications or other requirements (i.e. D:, E:, etc.) you can create additional virtual disks. As you will see in a moment, this method works best for creating template virtual machines.
Once you complete the wizard, you'll now have a new virtual machine with a blank hard disk. Insert the appropriate operating system media into the host CD-ROM drive or map the CD-ROM to the appropriate ISO image (more on this feature later) and boot the virtual machine.
The installation will proceed just as if this were a physical machine. When the virtual system boots, you'll see the virtual BIOS POST and the system will begin loading the Windows setup program from the CD-ROM. Once you complete what should be an otherwise uneventful Windows installation, you'll have a working virtual machine that you can log onto and interact with. Be sure to complete the installation of any default software and security patches, which might include service packs, Windows Update patches, and other software such as WinZip or Adobe Acrobat Reader. Also, remember to install the VMWare tools by clicking on the VM menu and selecting "Install VMWare Tools..." VMWare Tools load the proper drivers for the virtual hardware and provide improved management and use of the virtual machine. Once the virtual machine set up is complete, it’s advised that you to create template. Using templates will make creating new or replacement virtual machines a snap.
From the appropriate installation media (Windows 2000, 2003, etc.) open the \SUPPORT folder and locate the DEPLOY.CAB file. In this file you will find the SYSPERP and SETUPCL utilities. Copy/extract these files to a temporary folder on the virtual machine hard disk. Once you're ready to create the template, run the SYSPREP.EXE program which will remove all machine-specific information such as its name, registration, and SID information, and then shut the virtual machine down. You now have a virtual machine template that you can duplicate to create new virtual machines. If you plan on using more than one operating system version in your VMWare environment, you'll want to create a template virtual machine for each OS.
Building the Lab Virtual Machines
To create a new virtual machine from the template, run through the wizard to create a new virtual machine, but this time create a virtual disk that doesn’t allocate the entire disk size at once. After the machine has been created, go to the template machine and copy the virtual hard disk files to the new virtual machine location. Next, using the VMWare Workstation Management Interface, modify the virtual machine to use the virtual disk you just copied. When you boot the virtual machine, it should enter the Microsoft “Mini-Setup” wizard allowing you to set up the time zone, machine name and networking configuration. It will also generate new SIDs (Security Identifiers) for the machine. Once the new virtual machine setup is completed, you can delete the original virtual disk that you created during the virtual machine setup wizard, as you will not need this file. (Note: The virtual disk that you can delete from the virtual machine directory should be less than 1MB.)
You now have a new virtual machine that you can set up as a Citrix Server, Web Interface Server, etc. To create additional virtual machines, just repeat the process outlined above.
Citrix MetaFrame Server Virtual Machines
Using the virtual machine template, create a new virtual machine for the MetaFrame server. We will need to add basic IIS services to support the Secure Ticketing Authority (STA) module of Secure Gateway. Although the Web Interface will be running on another virtual machine, you could choose to load it on the MetaFrame server as well. If you do, remember that you need to support .ASP on IIS, so you will need to load those components.
Installing Citrix MetaFrame 3.0 Presentation Server on a virtual server is just like installing it on a physical box. The first step is to ensure that Terminal Services is loaded and can connect to a valid Terminal Services License server on the network. If not, Terminal Services will stop accepting connections after 120 days. (90 days for Windows 2000.) You will also need to load the Microsoft .NET framework 1.1, Visual J# .NET 1.1 and Java Runtime Environment (JRE), Version 1.4.1_02 (or later), all of which can be found on the Citrix MetaFrame 3.0 media in the \Support directory.
Next, install Citrix MetaFrame 3.0 and create a new farm, pointing it to your existing Citrix licensing server on the production network. If you have not yet set up MetaFrame 3.0 in production, you will need to load the MetaFrame License service first. Once installed and rebooted, test connectivity to ensure that MetaFrame is working correctly.
The entire Secure Gateway package is on a separate CD that shipped as part of the Citrix MetaFrame media pack. Secure Gateway version 2.0 is the latest version at the time of this writing, and if you don’t already have it you can download it from the MyCitrix web site provided you have maintained your Subscription Advantage.
Although it doesn't really matter in which order the three components are installed, the STA service needs to be the first component configured, so for simplicity we will install that first. Locate the CSG_STA.msi file on the Secure Gateway media and run it to install the STA software which will automatically launch the configuration wizard when complete. The wizard is basically a single screen that allows you to specify the STA identifier, ticket timeout and maximum number of tickets. The defaults usually work fine--the most important piece of information to remember is the STA identifier, as you will need to know this later.
The STA is really just an ISAPI filter located in the scripts directory of IIS. Because of this, IIS governs the ports that are used to listen for STA traffic. If you wish to alter the communication port used for the STA, modify the default web site properties to change the port from 80 to one of your choosing.
Web Interface / Secure Gateway Server
Next, you need an additional virtual server for the Web Interface / Secure Gateway services. Copy the template virtual machine to create a new virtual machine and run through the quick setup wizard when booted. Once complete, ensure that you load IIS with .ASP enabled.
In order for the Web Interface and Secure Gateway to coexist on the same server, you need to change one of the default ports that IIS uses. Using Internet Information Services (IIS) Manager, go to the properties of the default web site and remove the default SSL port (443) from the Default Web Site’s “Web Site” tab. This is done to free up port 443 for the Secure Gateway service which will be configured to redirect SSL web requests to the Web Interface running on the default web site. This allows you to run two otherwise conflicting services on the same server.
When installing the Web Interface and Secure Gateway services on the same computer, Citrix recommends that you install the Web Interface software first, so locate the WebInterface-IIS.msi installer file in the \Web Interface directory on the Citrix MetaFrame 3.0 media and run it to load the Web Interface software. The default options will be sufficient for most people.Next, you'll install the Secure Gateway service;. However you first need to load a digital certificate. You should preferably use the same digital certificate as the one loaded on the production Secure Gateway server; however, if for some reason you cannot use that certificate or if you don’t have a Secure Gateway server in production, there are a few options. ou could purchase one for the lab. GoDaddy.com offers 128-bit digital certificates for under $70.00 per year. You could also opt to use any digital certificate from a production web server since a digital certificate is issued to a fully-qualified domain name (FQDN), not a physical machine or IP address. You could simply install that digital certificate and then have that FQDN translated to any IP address you want through the creative use of local HOSTS files or your lab DNS space.
As another option, you could create your own Certificate Authority (CA) for the lab using Microsoft Certificate Services, although this has a few caveats. First, and most importantly, the CA that you build (and that subsequently issues your digital certificates) is not a trusted Certificate Authority. Many of the main players in the CA realm are considered trusted authorities, such as VeriSign, Equifax, etc. Their CA root certificate (the certificate that digitally “signed” the web site’s digital certificate) is already loaded into most PC/web browsers. When you encounter a digital certificate that has been issued by a company like VeriSign, your PC considers that digital certificate “trusted” because the PC knows that it has been signed by an authority that it trusts. However, when you create your own CA, there is no trusted root certificate in your browser that identifies that CA as a trusted authority. You can get around this by installing your private CA’s root certificate on the PC, thereby telling the PC that your private Certificate Authority is now “trusted”.
Whichever option you choose, you will need to load the digital certificate on the server. The simplest way to do this is to use the Certificates MMC snap-in to import the digital certificate into the proper Certificate Store. Once successfully loaded, the certificate will be available for you to select during the Secure Gateway configuration wizard.
Next, run the CSG_GWY.msi installer which is located on the Secure Gateway media. As with the STA installation, the Setup Wizard should launch automatically when finished. The wizard will ask you what you would like to secure; select MetaFrame Presentation Server only. For most people, selecting the "Typical" configuration level will do fine. However, if you changed the port that IIS listens on for the STA, then you will need to select "Advanced" in order to specify a different port.
Next, select the digital certificate that you will use for the Secure Gateway. Continue to accept the default settings until you get to the STA selection screen. Click Add, and then enter the FQDN (or IP address) for the server hosting the STA services. If you can resolve the name correctly and the server is listening, it should display the STA identifier next to the FQDN name that you configured during the STA Configuration Wizard.
If it responds with an error stating that it could not communicate with the STA, make sure of two things: First, be sure the STA software is installed and the server is listening on the proper port. Remember that if you changed the default port on the STA, you need to select "Advanced" when you begin the Secure Gateway configuration wizard. Second, if you're using an FQDN in the configuration, be sure you can resolve the name correctly. Remember that the Secure Gateway / Web Interface must be able to resolve this name using either DNS or a local HOSTS file.
Continue to step through the wizard, accepting the defaults. When you get to the screen asking you where the Web Interface is running, select “Installed on this computer”. When you click Finish, the Secure Gateway service will restart and you will be ready to go.
Testing the Lab
Now that the Secure Gateway components are installed, it’s time to do some testing and final configuration. Before we change the configuration of the Web Interface to use the Secure Gateway, we'll want to make sure the Web Interface works. Publish an application on the MetaFrame server and verify that you can run that application using the Web Interface.
Once successfully tested, open the Web Interface Management Console to configure the Secure Gateway settings. Under Server Settings, click DMZ Settings, then Secure Gateway Support. In the Secure Gateway FQDN field, enter the NAME THAT IS REGISTERED to the digital certificate. It is extremely important that this name matches correctly or else you won’t be able to connect to the Secure Gateway. If you're reusing a digital certificate from a production web server, such as www.mydomain.com, then enter that name. You can address any name resolution issues later.
In the Secure Ticket Authorities section, replace the <server> text with either a resolvable FQDN or an IP address. If you changed the port used for the STA, place the port number after the FQDN/IP address, separated be a colon. For instance, if the STA’s IP address is 192.168.1.20 and you have change the default STA port to 8080, then the URL for the STA should look like “http://192.168.1.20:8080/scripts/CtxSTA.dll”. Click Add and then save and apply your configuration.
We now have to tell the Web Interface to use the Secure Gateway for ICA connections. Click on Network Address Translation under DMZ Settings. If you want to use the Secure Gateway for all connections, select Secure Gateway under Default Address Translation Settings. If you only want the Secure Gateway used for a select set of clients, leave the Default Address Translation Settings set to Normal Address and set Specific Address Translation Settings to use the Secure Gateway. Type the specific SOURCE IP ADDRESS/NETWORK into the Client Subnet fields that should use the Secure Gateway and click Add. This is a good choice if you have a specific subnet for your lab and want to only have the Secure Gateway used for the lab source IP addresses. Once you've made your selections, save and apply the changes.
Lastly, you need to resolve the FQDN of the digital certificate you installed to the IP address of the Secure Gateway server. The easiest way to do this in a lab is to use a HOSTS file. On the client, browse to the SYSTEM32\DRIVERS\ETC directory and open the HOSTS file (no extension) in Notepad. At the end of the file, enter the IP address of the Secure Gateway server followed by the FQDN registered to the digital certificate installed on the CSG server, separated be a tab (tab key). Once finished, save and close the file. Note that failing to perform this step will prevent you from connecting to the Secure Gateway properly.
To test the Secure Gateway, open the Web Interface, log in, and launch any published application. If you successfully connect, check the Connection Center in the System Tray. If you're using the Secure Gateway, the connection details should indicate you are connected using 128-bit SSL. If not, go back review the settings in the Web Interface Management Console to be sure everything is configured correctly. If you begin to launch the application and receive no response or you get an SSL error, chances are you're not resolving the digital certificate FQDN properly to the IP address of the Secure Gateway server.
For full details on configuring the Secure Gateway and Web Interface, please refer to the documentation that accompanies both products on their respective media.
Getting the Most from your Lab
Testing a new application that was never deployed to production or deleting files and/or making test configuration changes can render a traditional lab server useless since it wouldn't mirror the production environment. On a physical machine, undoing these changes would involve either rebuilding the machine or restoring it to a previous state from backup or a Ghost image.
However, when using virtual machines, you have the ability to create “snapshots” at any given point in time. By using snapshots, you can revert a virtual machine to the pre-snapshot state with a simple click of a button. Let’s say there is a new untested application that you want to install on your virtual Citrix server. You can create a snapshot while the virtual machine is running, install the software, and test it. If something goes wrong (i.e. the virtual machine crashes, the new application breaks an existing application, etc.), all you need to do is “revert” to the snapshot to roll the virtual machine back to the state it was in before you installed the application.
Snapshots work by creating a set of “redo” disk files in conjunction with the normal virtual disk files. New information is no longer written to the existing virtual disk file for that virtual machine; instead it is written to the redo files. If you choose to keep the changes, VMware will roll the redo files into the virtual disk files. If you choose to revert the virtual machine to the snapshot, then VMware discards the existing redo file, rolls the machine back to the previous state, and creates a new redo file.
If you've created a snapshot and want to take another snapshot, doing so will save the existing virtual machine state by rolling the redo file into the virtual disk file, and then creating a new redo file. Keep in mind that you can only have one snapshot at a time. Each time you take a new snapshot, the virtual machine’s current state (including any existing redo files) is saved permanently.
You may also choose to completely remove the snapshot, which will revert the machine back to the previous state and delete all redo files. However the virtual machine must be powered off in order to do this.
If you want to leave your existing virtual Citrix server as it is and test with a completely separate one, you can make an exact copy of the virtual Citrix server simply by copying the virtual machine files to another directory on the VMware host and powering it on. Just remember to change the virtual disk path in the new virtual machine configuration to point to the new directory, otherwise the configuration file will still be pointing at the virtual disk in the old directory instead of the new one you copied it to.
If when using your virtual machine you find that you need additional hardware resources, you can easily reconfigure the virtual machine. For example, to change the amount of RAM from 256MB to 512MB, just power down the virtual machine, modify the RAM configuration, and power it back up--you now have 512MB of RAM running in your virtual machine. Need another network interface? No problem. Just run through the Add Hardware wizard to add an additional NIC and restart the virtual machine. How about an additional disk drive? Add it to the configuration, power up the virtual machine and use Disk Management to format the new disk. Changing your virtual machine configuration is as simple as shutting down the virtual machine, making the changes in the VMWare Workstation Management Interface and powering it back up.
Other Suggestions
- Build your first guest operating system as a template, and use Microsoft’s SysPrep utility to “roll it back.” You can then use this system as a template virtual machine to create new virtual machines. This way you don’t have to build each virtual machine separately.
- If you have made the move to virtual machines in your production Citrix environment, you can copy the Virtual Machine files to your lab to get exact duplicates of your production virtual servers.
- You can boot and install virtual machines from .ISO images rather than needing to have installation media handy. Most CD burning programs can take a CD, such as a Windows Server 2003 CD, and rip it to an .ISO image. If your CD burning software can’t do this, an inexpensive third-party program like WinISO will allow you to do the same. The ISO images can then be placed on the network and used when either installing a new virtual machine or when files are needed from the original media. To use them, change the Virtual Machine configuration to use the ISO file for the CD-ROM device rather than the host CD-ROM drive. This change can even be made while the virtual machine is running.
- If using Windows Server 2003 or Windows XP in your lab, make use of Remote Desktop to manage the machines remotely, including the host computer. This way you aren’t physically tied to the lab when you need to test something.
- You can easily duplicate any virtual machine by copying the virtual machine files to another location on the virtual server host, renaming the virtual machine and booting it. This will give you an exact copy of the virtual machine.
As you can see, setting up a lab can be accomplished easily in a relatively short amount of time. A good lab can save you from a world of trouble when you are testing new patches or applications. It can also be an indispensable learning tool to gain hands-on experience and a better understanding of a particular product or technology. By utilizing the benefits of virtualization the lab can take on many roles and change easily to suit your needs.
