Tip

Implementing change management in the Windows server environment

I have always been a big proponent of change management and change logging on servers. Keeping track of the changes made to servers -- including what was installed and why -- can help Windows server administrators in many ways. It can help troubleshoot and diagnose system errors by providing a means to see what, if anything was changed just prior to problem occurrence. Change management logging can also help pinpoint potential security vulnerabilities because you can see what patches were installed and whether these patches are current.

And while there are many wonderful benefits of change management, it tends to be a lot of work and tedious to keep up with, and few organizations use or keep up with it. That being the case, there are some steps administrators can take to reduce the amount of work involved with change management.

Requires Free Membership to View

More on change management
A disciplined approach to the Windows change management process

Keeping your change management process honest

 First things first. To help implement change management, admins should have a consistent server configuration for their environment.

Don't get me wrong. I realize that, in fact, there is really no such thing as a consistent configuration. Differences in hardware and in application sets prevent you from making all of your server's configurations identical. Even so, here are some things that you can do to standardize your servers:

  • First, perform a full blown hardware and software inventory on all servers. This information helps determine which parts of the configuration can be standardized. You may come up with a standard configuration for Windows, for SQL Server, for your drivers and so forth.
  • Next, start testing. Set up a few lab servers to thoroughly test your proposed standards. Sure the standards you set today may not be the standards forever, but if you are going to be using them, you'd better be sure that the configuration works.
  • Pass the test? Then it's time to make backups of all of your servers just in case anything goes wrong. After that, do whatever is necessary to implement the approved standard configuration on all of your servers. This may involve installing service packs, updating drivers or things like that.
  • Once the server configuration is up and running, it's time to thoroughly document each server configuration. It is equally important to hold off on making any other changes to your servers for a few weeks, as waiting will help determine whether the base configuration is stable and error free. If updates are applied soon after your servers have been standardized and problems occur, it could be difficult to determine whether the problems are related to a flaw in your baseline configuration or to the most recent set of updates.

Having a baseline server configuration helps implement change management in your Windows server environment. But, since the baseline may change, here are three other best practices I recommend for keeping up with change management:

  1. Create a change management policy. This document would outline what and if changes are allowed and what the procedures should be for making the changes. For example, Microsoft routinely releases security updates, driver updates, Windows updates and other types of patches. Some organizations may choose to apply updated drivers when they are made available, while others adopt the "if it ain't broke don't fix it" approach and never replace a driver if it's working.

  2. Document test update procedures before they are applied to production servers. The testing procedure typically varies by patch type. If a virus wreaks havoc on all Windows servers, and Microsoft releases a new patch to mitigate this threat, you won't want to spend six months testing the patch. On the other hand, since service packs usually make major changes to the product, they should undergo longer and more thorough testing than they would for a small patch that addresses a critical issue.

  3. Enforce change management policies. If you don't enforce the policies, it undermines the goals because the IT staff never knows when changes have been made to servers. Also remember that the rules apply to all, so don't be afraid to enforce a rule that your boss may have broken.

Just as the IT industry evolves, don't forget that your change management policy will evolve over time too. As it does, make sure that everyone who is responsible for maintaining the company's servers is on board with the changes to the policy and that the policy changes are formally documented. Otherwise, it's only a matter of time before server maintenance becomes haphazard and inconsistent.

ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal website at www.brienposey.com.

This was first published in February 2009

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.