The Basics of Change Management

Managing changes in your environment, from the initial build through deployment and future upgrades, does not have to be a complex task. Change management is really about testing changes, documenting changes, and having a way to back out of unsuccessful changes. If you can accomplish those three now then you have a basic change control plan.

Let's examine some specifics of change control for Terminal Server environments.

The Initial Build

The change control process begins with the initial build of your servers. You should create documentation showing how each server (or the server image) was built and any late additions or modifications made to the build.

It's rare for your server's first build to be the one that is put into production. In most cases, issues will crop up during testing that will cause changes to your server build process. Each of these changes should be documented and logged as additions to the base build document. In this manner you create a repeatable process for building an identical server, and you have the ability to backtrack and back out changes as they are made.

If you're using imaging for server deployment, it's generally a good idea to store checkpoint images along the way. Read through the following procedure to understand how a "check point" imaging process works.

1. Install the operating system.

2. Install any service packs.

3. Install any hot fixes.

4. Prepare the operating system for imaging (using sysprep, etc.).

5. Take image of server. (This will be Image 1.)

6. Update the operating system application components needed (i.e. MDAC, Oracle client, etc.).

7. Install third-party software for Terminal Server (such as Citrix Meta-Frame or Tarantella Canaveral iQ).

8. Tweak the operating system performance settings.

9. Prepare the operating system and third-party software for imaging.

10. Take an image (Image 2)

11. If you're planning to deploy your servers with all applications installed, install your applications.

12. Verify that all applications function properly.

13. Prepare the server for imaging.

14. Take an image (Image 3).

This process affords you three server images, and the option to revert back to a prior image should problems arise. Each image serves a specific purpose:

• Image 1 gives you a base operating system (fully updated and patched) for any purpose. This image acts as a checkpoint prior to the installation of any third-party software and can be used as a base build if the third-party software is updated. If you don't have this image, you'll have to build a new image from scratch next time there is a software update.

• Image 2 gives you a base image that can be used across all your servers, clusters and silos. While this image has no applications on it, it's ready for production. If you deploy your applications via script or some other automated process, then this image will be your base server build. If not, then this image gives you a clean build with no applications for use in creating different cluster images without having to hand-build each one.

• Image 3 is your production image used to deploy servers into your cluster.

Remember that you should be logging all the changes that are made to any of the builds. This change log should be created whenever a new build is created or a new cluster is deployed. It can be as simple as a spreadsheet with the changes entered linearly or as complex as a dedicated change management database. Either way, the end result is that everything in the image and every single change has been documented for the entire life of the server.

Post Rollout

In many ways, a good change management system really starts to shine after your servers are deployed. Ideally, you'll be able to log changes to production servers and tie these changes back to your build process so that it incorporates the most recent changes. Figure 15.1 shows the typical lifecycle of a change control process.

Figure 15.1: The change management lifecycle

After the initial deployment, changes to the servers will be constant. The trick is to ensure that all servers are managed as one. When a change is made on one server in the group, all servers should receive the same change. Every change applied to production servers should be documented in the change log so you could build a new server identical to your production servers.

Periodically review your change logs and add all of the changes into your image to keep the number of changes required post build to a minimum and make it simpler to build a server.