Using a cost management analysis to manage change in a Windows shop

Russell Olsen

An effective Windows change management process can be the difference between life and death in any organization. Windows managers who understand that are worth their weight in gold.

Whether managing a simple Windows security update or a full-scale migration to Windows Vista or Windows Server 2008, knowing what changed and when it changed makes a big difference – especially when something goes wrong. If this is so clear, why do so many of us struggle to implement or maintain an adequate change control process?

The answer is simple – it takes time and resources. A robust change management process includes committees, request systems, pre-approvals, approvals and post-approvals. I've seen some companies with entire departments that do nothing but manage the change process. However, most of us just don't have the resources or can't afford to slow down enough to deal with the overhead.

So how do you implement effective change management on a budget? Use these three basic steps:

• Evaluate
• Establish the process and commit to it
• Lockdown and audit

Evaluate — Whether you are starting from scratch or trying to revive an old process, the first step is the same: You need to evaluate what you are trying to do. The idea here is to align resources with things that keep you up at night.

You can't solve every problem in the world if you have limited resources, but you should at least know if someone wants to upgrade your production server from Windows 2000 Server to Windows Server 2008. Clearly defining what will and will not be included in your change management process will help deliver the biggest bang for your buck in your cost management analysis. Depending on your organization, this could be as simple as a server list or as detailed as configuration settings for different users or applications.

Establish the process and commit to it — Effective change control processes might be implemented in different ways and with different tools, but they can all be boiled down to three steps:

1. Every change must be authorized. The process needs a gatekeeper to prioritize and weed out the unnecessary requests.
2. Every change must be tested. Test every change prior to deploying it into production.
3. Every change must be approved. Get formal approval for deploying it into production. This approval is sometimes shared between IT and the business owner affected by the change.

The implementation of these steps can be as simple or complex as you need them to be. In a small company, most likely one or two individuals will handle this process, while larger companies typically devote entire departments to the cause.

Also remember if it isn't documented it didn't happen. When implementing the process, take advantage of existing software like Microsoft SharePoint or Public Folders in Microsoft Exchange to facilitate the request and approval processes.

Lockdown and audit — What is the kiss of death to any change management process? It's the change that didn't follow the process. A change that was never authorized, tested or approved poses a threat to the stability and integrity of your system and gives users the idea that they don't have to follow the process.

Preventing the breakdown of the process occurs in two steps:

1. Lockdown. Using the scope defined in the evaluation process, remove all unnecessary access to the systems, services or configurations that have been identified.

2. Audit. Establish a process to create a baseline and monitor for changes. This could be the time stamp on a configuration file or the version and patch level of an application.

Active Directory queries, WMI scripts and Microsoft's Systems Management Server, or SMS, can all be used to monitor access and to audit for changes. By removing unnecessary access and monitoring for changes outside the process, Windows managers can feel comfortable knowing that any holes in the process will be plugged quickly.

Let's walk though a quick example of how to bring this all together:

Upon review of your environment you determine that Server A — running Windows Server 2003 with a third-party billing application — is mission critical and that all changes to that system will go through your change management process. However, Server B, also running Windows Server 2003, is not mission critical and therefore does not need to be monitored.

Using SMS, your Windows administrator alerts you that Server A and Server B are in need of the latest security patches. Updates to Server B occur at will, but Server A security patches require more notification — and a change request is submitted to the IT manager, who communicates with the billing manager that Server A needs security patches.

Authorization is granted for Server A changes as well as instructions about what needs to be tested on the application to verify functionality. In the Server A test environment, the patches are applied, the IT staff and/or end-users of the billing application execute the test scripts and confirm that the patches didn't adversely affect the application. Both the IT manager and the billing manager approve the Server A change for production.

The next weekly report for Server A shows an alert that a change occurred. The alert is disregarded because the IT manager was expecting the change.

Russell Olsen is the CIO of a healthcare technology company. He has worked for a Big Four accounting firm performing technology risk assessments and Sarbanes-Oxley audits. Olsen is a CISA, GSNA, and MCP.