HowTo: Build a Complete Citrix MetaFrame Lab with VMware Workstation

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.

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. 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, 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 and you have change the default STA port to 8080, then the URL for the STA should look like “”. 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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by an anonymous visitor on November 1, 2004
I like this article, it is focused, well-written, and techinically accurate. Mike great job! Thank you.
This message was originally posted by ALEX on October 31, 2004
Brian, I do not doubt that Mike knows the subject matter. My comment was emphasizing the fact that secure Gateway is responsible for SSL “envelope” of ICA traffic between the client and CSG, however ICA traffic itself is established between the client and Citrix farm. Thus only Citrix farm (which CSG is not a part of) and the ICA client are maintaining ICA encryption (passing through CSG) at the time when SSL encryption is controlled between the two parties -- the client (the same ICA-client exe) and CSG.
This message was originally posted by Brian Madden on October 31, 2004
I think when Mike says Secure Gateway encrypts the traffic between the Citrix farm and the client, he is correct, because he's talking about when Secure Gateway is doing in general. This is why he said "Citrix farm" instead of "Citrix server," so I don't read it like you do. Of course you are correct in that the traffic is only encrypted between the client and the gateway, but I think that's what he was saying.
This message was originally posted by ALEX on October 31, 2004
"Secure Gateway server is responsible for encrypting the traffic between the Citrix server farm and the client" statement is inaccurate. Being reverse proxy, Secure Gateway does not control traffic encryption after it strips SSL encapsulation and passes ICA traffic to the farm. After CSG (between CSG and MetaFrame farm) ICA encryption will depend on ICA-native settings (128-bit encryption is usually recommended).
This message was originally posted by an anonymous visitor on November 1, 2004
OK..We get your point Alex. Nuff Said
This message was originally posted by an anonymous visitor on November 1, 2004
I've tried to push virtualization in my environment, but every time I do, someone says "But how do you know that if you test Application X on a Virtual PC that it will run the same on a REAL PC?" I've had a hard enough time convincing them to let me test workstation applications on a virtual PC. Any suggestions on how to help convince them to let me set up a whole virtual Citrix farm?
This message was originally posted by an anonymous visitor on November 1, 2004
Attend a free VM seminar. They have the answer down to a science. Use the info in Doc#:267 my advantages listed. BTW, looking forward to more posts on designing Citrix farms on VM ESX.
This message was originally posted by Joe Deller on November 2, 2004
Introducing virtualistation is often an uphill struggle. Try explaining to people that the VM platform is just a hardware platform like a Dell, IBM or HP box. You could argue that just because an app runs on a Dell, you've got no guarantee it runs on an IBM - occasionally this might even be true for one reason or another (not to single out IBM). The arguments the doubters will put up against you can are the same ones you can apply to running a VM vs a "real" PC. Lots of people are running Citrix farms under VMware, including Citrix :-) However as mentioned, VMware themselves are well versed in helping out with this problem.

I've just come back from the VMWorld conference, which was pretty amazing, but one clear message was that vendors /developers should expect their applications to be running under VMs as the norm, not the exception.
This message was originally posted by Alex on November 1, 2004
This message was originally posted by Leo van der Mee on November 9, 2004
Yeah another nitpicker: you cannot encrypt the traffic between the CSG and the Citrix Farm with the SSLRelay. CSG and SSLRelay cannot co-exist. So you use either the SSLRelay (which gives you end-to-end encryption) or you use CSG which means you will have to rely on RC5-128 ICA encryption for security or setup IPSEC between the CSG and your CTX servers.
This message was originally posted by Michael Burke on November 8, 2004
This article was geared towards VMWare Workstation simply because of its low cost. Many IT organizations are faced with reduced budgets, so I wanted to present this as cost-effective for any organization. Aside from any specific information pertaining to the VMWare Workstation product itself, you could easily use this information in this article to port this to GSX or ESX Server, or even Microsoft VirtualPC or VS2005.
This message was originally posted by Michael Burke on November 8, 2004
Thank you, everyone, for you comments and feedback. I was on vacation last week and somewhat disconnected from the technical world, so I wanted to get back to those who had qhestions/comments.

ALEX - you are correct in you posting - CSG does not encrypt traffic to the Citrix farm itself. My intention was simply to state generally that CSG is a mechanism for encrypting traffic between the end user and the farm, as opposed to sending that traffic in an insecure form. To clarify (as you stated) it only encrypts that reaffic between the client device and the CSG server. Traffic that is sent between the CSG server and the Citrix farm is not encrypted by default, although it can be by using SSL Relay. I probably should have chosen to word that differently. Thank you for the comment.
This message was originally posted by Leo van der Mee on November 8, 2004
Apart from the CSG mistake grinnn the primary purpose of the STA is not storing username/password but to store the IP-address of your Presentation Servers. There are many scenarios (e.g. smartcard) where the STA does not store any user credentials at all.
This message was originally posted by Michael Burke on November 8, 2004
Some comments expressed troubles with getting management to "buy-in" to virtualization technology. I have to admit - this can be difficult. The biggest obsticle here is that management needs to have a certain comfort level with virtualization before the green light goes up. Typically, they fear what they don't understand. Once they gain confidence in the technology, they will be more open to it. As Joe said, it is an uphill battle. The old way of thinking is "more is better" (as in more servers). My suggestion would be to simply keep "plugging" away at them - as they read more about it and talk to their other golfing buddies that are alreay using it, they will be more open to it.

Also, if you have a disaster recovery project in the works, bring that up as a virtualization possibility. We have a cold DR site (not connected live to our production network). We included virtualization in our solution for Active Directory integrity - we virtualized one of our DCs. Each night, we perform an encapsulated backup of the virtual DC (encapsulated backups are when you back up the VM files themselves, instead of performing a backup from within the Virtual Machine). We then simply restore the VM from tape onto our GSX Server in the colocation facility and we instantly have a working AD.
This message was originally posted by Michael Burke on November 9, 2004
@Leo - I agree. It would be nice if you could use SSLRelay with CSG (although it could get quite expensive to maintain in large environments). Generally, I explain to my clients that using CSG alone is "secure enough" without adding more encryption overhead of RC5 (ICA). If they insist on another layer of security, I tend to suggest adding a secure gateway proxy in a second DMZ, or just simply use MSAM (don't get me started on that product, though)...
This message was originally posted by Leo van der Mee on November 12, 2004
@Michael - You have no idea... SSLRelay can't be installed unattended... and we need to do it perhaps 300 times... dont ask me the details... Citrix confirmed it cant be done without them revealing security sensitive information. They did promiss a tool for unattended installs for MPS4.0 though.
They even said that with an upgrade of SSLRelay to a newer version you will have to do the whole manual install all over again...

And then to think that is the one of the suggested solutions by Citrix themselves... scenario B in the "Citrix MetaFrame XP Security Standards and Deployment" guide.

About RC5-128 bits. You can safely add that. With modern day processor both on client and server it adds little overhead. It provides you with a secure connection from the DMZ to your secure network. Same what SSLRelay does for your XML traffic from WI to your Data Collector.
This message was originally posted by Michael Burke on November 12, 2004
@Leo - "About RC5-128 bits. You can safely add that. With modern day processor both on client and server it adds little overhead."... I stand corrected - I guess these days the overhead is probably of little consequence. I have to admit that I have never had the need to do unattended installs of SSLRelay, but it does seem somewhat short-sighted to not have a way to set this up unattended. And the idea that you need to manually reinstall for an upgrade... Ugh!
Why separate Production from QA servers?

Can't we use the same servers for both Production and QA?
is this part of another post? can you please clarify your question.
cheap cheap... includes...
VMware Workstation
VMware GSX Server
VMware ESX Server
VMware Virtual SMP
VMware P2V Assistant
Technical Support
Updates & Upgrades
I don't understand why you would want to separate them either?...
VMs built on Workstation can be moved to GSX Server or ESX Server and vice versa. There are some caveats that relate to the version of "Virtual Infrastructure" and the SCSI Driver selection. This is all discussed in VMware's "Mobility" document (among the downloadable documentation), so best to read this before diving in. It will save you wasting time by picking build choices that will not migrate.

In Workstation, you must choose "Custom" then buld a "Legacy VM", as Workstation 5 / 5.5 is the next generation Virtual Infrastructure to that of GSX 3 and ESX 2, which are the same generation.

Once you understand the choices, moving between Workstation, GSX and ESX is easy. Moving cross geraration, you encounter the same issues as if you change physical server hardware. Some OSes can adapt to some changes.