Do I need a test server for my Citrix environment?

Subtitle : A guide to justifying the expense of a test server.

Now that Client-Server computing seems to be coming around full circle, and more businesses are buying into Citrix MetaFrame for the reduced Total Cost of Ownership, many IT managers are seeing large sums of money departing from their budgets at a rapid speed into a black hole called Citrix.


Why is this, when it was supposed to save money?

Well, one answer I'm commonly confronted with is that there is no such thing as a test environment for many companies. This can be viewed as a very bad thing.

The main argument I hear against a test environment is the sheer cost of another MetaFrame server and the licensing.

The argument to counter this is to watch an environment without a test server struggle with new printers, fight unruly applications, grapple with policies, profiles, and permissions, and get strangled by tendrilous network connectivity issues. Feel familiar?

Those are just the main three areas that I see causing unnecessary user downtime (= lots of money) and the eventual calling in of highly-paid consultants - who often do little more than rebuild the servers.

This tells me that things may not have been done correctly in the first place. An easy statement to make, with retrospect, but just how does an administrator avoid these issues?

The answer costs $5,000 and comes shrink-wrapped from Citrix. It's another server license. Double that and add $3,000, if you want to perform meaningful tests in a load-balanced environment.

You can pool the licenses out to your live environment, so that will save a little, but the savings come as you re-create your live environment and experiment with it.

On the surface, this looks like a luxury or even a waste of time.


Re-consider.

If you had installed that DeskJet 860C onto a test server first and simply used it, you would have found the problem before your users did. You would have given yourself, as an administrator, the luxury of having some time to find out that this printer doesn't work, get the user one that does, and make the IT department look more efficient.

Instead, you gave the user the printer, found it didn't work, wasted hours of your time trying to figure it out - and hours of their time while they couldn't print. Probably making you and the entire IT team look inefficient - not to mention making accountants wonder why they waste money on such a poor service.

I'm not being unnecessarily harsh here - I've seen it too many times. Eventually the poor administrator gets so fed up he/she leaves and takes away all her/his skills, leaving the company more bills as they get temporary skilled staff, who generally don't understand all of the previous guy's reasons for configuring the system the way he/she did, and waste more money rebuilding the system.



The answer is to build a test environment.

All that is needed is a PC with a reasonable processor, 500Mhz will do, plenty of memory (at least 256Mb; 512Mb or more preferred), a 100MB/sec NIC and a SCSI disk.

If your existing environment is complex, recreate it step by step. Test it at each step - ie after installing a given application - until field issues appear. Solving issues in a test environment is less stressful (and generally more successful as a result) than "doing it live", and has little or no impact on the user community.

You can also indulge in a little benchmarking. Deliberately and maliciously stress your test server, with performance monitoring tools running, and try to break it. A perfect way to spend a quiet Thursday afternoon, and worthy of another essay.

A good way I have found to test the test environment is to schedule in pilot programs:

If a group of users require a new application, it can be installed onto the test server, and selected members of this group can use the application, once you are happy that you have tested it as far as you can. This can be done as a Published Application directly into Program Neighborhood, assuming that the test server is linked to the main network. Thus it is totally seamless to the users.

Advantage 1. If the new application brings the server to a halt under test, it doesn't impact anyone, including the testers. They can still use the apps in the live environment while you investigate the issue. Note: The pilot users need to be under the full understanding that they are the ones priveleged enough to test the application for their colleagues.

Advantage 2. If it works, and your test server is identical to the live ones in terms of software build, there is a much higher chance that you can confidently plan a roll-out date that will not only be actually met, but without much trouble. The managers of the test group will appreciate knowing exactly when they can have their new software, and that by getting a few to test the application first, training needs will be reduced since, by testing, these users will become experts in the new software and can help their colleagues.

Eventually, your managers will wonder how you can single-handedly support so many users - and maybe give you a pay-rise!

A bit too much to ask, I would regretfully suggest.

Tip : If you want to prove that a test server really can make a difference, you can build one for the cost of the hardware by using the 35-day grace period allowed by Citrix on the MetaFrame product. The Microsoft licenses can be catered for by using the demo of Terminal Services that comes with Microsoft's Terminal Server Technical Reference book ($49.99, Microsoft Press).



CitrixEngineer, Tek-Tips Forum 11th January 2001.

Update, 8th February 2001.

MetaFrame XP addresses the expense issue very nicely, with the new licensing model. Citrix are now essentially giving the server software away.

All you pay for now (with XP) is connection licenses. You can install the server software on as many servers as you like.

Since this could be installed on an *old* Pentium II PC, and memory is very cheap (as I write 256Mb can be obtained for less than $100), there is now no excuse for not having a test environment.



Source for Citrix licensing model information and pricing:
http://www.citrix.com/csn/skus.htm