I have my test server, now what do I do with it?

You've persuaded your boss to let you have the CEO's old PII, "found" some extra memory and a SCSI disk setup for it, installed all the applications your users will ever execute and it's great.

Actually, it's not. It's a mess. Did you document everything you did on that server?

Neither did I.

OK, rebuild time.

Every two or three months I would suggest is a good time to rebuild the test server. To make this less of a bind, I do the following:

1) Install the base operating system (Windows NT4 TSE or W2k). Update with all necessary Service Packs.

2) Create an image and burn it to a CD. With Windows products, Norton's Ghost is probably the imaging product of choice.

3) Install MetaFrame, update similarly and burn this image.

4) Install base applications, such as an Internet Browser and plug-ins, multimedia updates and so on.

5) Test thoroughly and create an image.

Hopefully a pattern is emerging. Feel free to document all procedures as the imaging takes place - but remember where you stored the documents!


Why burn so many images?

This procedure makes it possible to roll back to a known working level, and, when new Service Packs or hotfixes are released, these can safely be tested in the test environment by rolling right back, installing the update, and following the image procedure.

With bargain CD multipacks flooding the Auction sites, your main issue will be effective storage of the images.


I would suggest that this is a less painful issue than finding a particularly nasty bug in a production environment, and less tedious than rebuilding a server from scratch.


For individual applications, it would be better to store the image on a network drive, or a second hard disk in the test server. Now, if an application causes too many woes you can roll back to the last working version you had.

In the application testing scenario, it would be best to adpot the "grandfather, father, son" approach, rather than store dozens of images. In this case, grandfather would be the initial installation, son would comprise the latest bugfix, and father would be a rollback from son.


At any point in time between installations it is good to benchmark your server.

A series of benchmarks performed at different stages (O/S, MetaFrame, base applications, app1, app2, etc) will give a picture of what is causing a performance hit and where.

Benchmarking can range from simple perfmon recording to professional benchmarking tools.

Stress testing with scripts is another thing to hit your test environment with. Try using scripts that emulate what users do - open Word, create 10 documents, etc.


Testing is one of the most productive ways of troubleshooting a production environment, since you are unemcumbered with the stress that a thousand users at once can bring on.

Remember - if it ain't broke, you haven't stressed it enough.


CitrixEngineer, Tek-Tips forum 8th February 2001