Chapter 3 - Change and Configuration Management

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : October 11, 2001

Microsoft® Exchange 2000 Server

This chapter is part of the Exchange 2000 Server Operations Guide.

This chapter presents many of the processes for managing the changes you make in your Microsoft® Exchange 2000 Server environment. These processes help you to evaluate, control, and document change and configuration within your organization.

Introduction

Microsoft® Exchange 2000 Server is highly configurable and has the potential for huge variation in hardware and software configuration. It is also likely to be one of the most important elements of your IT environment. For Exchange to run as smoothly as you hope, providing the best possible service to users, you need to make sure that your environment is carefully managed. In particular, you need to ensure that any changes to the environment are considered in detail before implementation and that good records are kept of all elements of the IT environment.

The goal of the change management process is to introduce change into the IT environment quickly, with minimal disruption. All businesses are subject to change, and IT is a business area which is subject to more change than most. A fundamental part of good IT operations is to accept change and control it appropriately. A good change management process also includes a method for quickly implementing urgent changes required to quickly restore IT services. Change management should be a core and constant part of your IT operations, not just something you visit when there is a major upgrade.

Change management is closely related to configuration management, which is the process responsible for identifying, controlling, and tracking all of the elements of the IT environment. Good configuration management ensures that only authorized components are used in the IT environment and that all changes are recorded in a configuration management database.

This chapter discusses both change and configuration management, with particular reference to Exchange 2000 Server.

Prerequisites

By now you have defined a set of acceptable service level agreements for your Exchange environment and you understand the concepts of availability management that were discussed in Chapter 2, "Capacity and Availability Management."

Chapter Sections

This chapter covers the following procedures:

Change management
Configuration management

Change Management

Effective change management allows you to introduce change into your IT environment quickly and with minimal service disruption. Change management is responsible for changes in technology, systems, applications, hardware, tools, documentation, and processes, as well as changes in roles and responsibilities.

A key goal of the change management process is to ensure that all parties affected by a particular change understand the impact of the impending change. Because most systems are heavily interrelated, any change made in one part of a system can have major impacts on others. Change management attempts to identify all affected systems and processes before the change is implemented so that adverse effects can be minimized.

As with many areas of management, you can measure how effective your change management is by how boring it is. Providing a smooth running change management process is one of the most challenging aspects of IT management because of the very nature of what you are managing—change. With the proper processes in place however, your environment should run very smoothly.

You can find more information about change management at:

https://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx

Defining Change Type

To most effectively manage change within your organization, you need to categorize the types of changes that could occur. In Exchange, these changes could include the following:

Applying Service Packs.
Adding new servers.
Adding new users.
Adding new administrative groups.
Changing routing group topology.
Changing backup and restore procedures.
Modifying and applying policies.
Changing other existing settings.
Changing a process or script used to administer servers.

Change can be broadly categorized into four groups, each requiring its own style of management. The groups are:

Major change. Significantly impacts the IT environment, and requires major resources to plan, build, and implement (for example, upgrading all Exchange 2000 Server hardware).
Significant change. Requires substantial resources to plan, build and implement (for example, upgrading to a new Service Pack).
Minor change. Requires no significant resources and doesn't significantly impact the IT environment (for example, modifying certain Exchange system policy settings).
Standard change. Follows a standard documented procedure, which should not affect the IT environment at all (for example creating new mailboxes).

Of course, the more changes that you can successfully fit into the latter two categories, the less likely there will be a significant disruptive impact upon your organization. This does not mean that you should avoid significant or major change. Indeed, major or significant change can often prevent problems with availability management later on. For example, deploying a new Service Pack throughout your organization may enable you to avoid encountering problems with your environment.

By thoroughly documenting as much of the Exchange environment as possible, including how changes should be made, you can maximize the number of changes that are categorized as minor or standard, thereby significantly decreasing the costs associated with change.

Change management involves the following five activities:

A change is requested.
The impacts (technical and business) of making the change are assessed (this includes testing in a lab environment).
The change is authorized.
The change is handed to Release Management for implementation.
The change is verified.

Numerous parties should be involved in Exchange change management. To see how these parties would typically interact, examine the following major change, upgrading all servers running Exchange to new hardware.

Step 1 – Request for Change Is Submitted to Change Manager

Everybody in your organization should be authorized to submit a request for change (RFC). In this scenario, the likelihood is that the RFC has come from a member of your IT staff.

Other change sources include IT staff responsible for problem management (for example, root cause analysis), service level managers who are planning to sell new kinds of service or upgraded levels of existing service, and so on.

Step 2 – Change Manager Assesses the RFC

The change manager receives the RFC and records it in the change management log. The manager examines the RFC, checking to see if it is a complete and practical proposal. If in any way the proposal is deemed unsatisfactory, it is handed back to the person who submitted the RFC (known as the change initiator) with appropriate red marks, or even if it is approved, the change manager may pass it back to the change initiator for further analysis

After the change is determined to be satisfactory, and appropriate information is gathered, the change manager prioritizes the change. Change is prioritized as urgent, high, medium, or low, which determines how soon the change will be made:

Urgent. Changes that must be performed immediately and are quickly transferred to the urgent change process.
High priority. Changes that must be performed quickly to maintain Exchange availability to a significant number of users.
Medium priority. Changes that are necessary to resolve problems, but are not of immediate importance, or only affect a small number of users.
Low priority. Changes that can typically wait till the next major release of Exchange to resolve the problem

In this case, upgrading server hardware is usually categorized as medium priority.

Now the change needs to be categorized. In this case, as already mentioned, it would be judged as major change. The change manager will make a note of this prioritization and categorization in the change management log.

At this stage, if the RFC is assessed as a minor or standard change, the change manager would probably pass the RFC directly to the change owner responsible for implementing the change. If the RFC is considered to be a significant or major change, it will be passed to a delegated team that will prepare implementation options for consideration in the next stage.

Step 3 - Change Is Passed to IT Executive Committee for Approval

The IT executive committee has the responsibility of approving major change in the organization. It will typically consist of senior members of the IT staff in your organization. It will judge if the hardware upgrade should proceed or not.

Step 4 - Change Is Passed to the Change Advisory Board for Scheduling

The change advisory board consists of a core group of individuals, people who are familiar with business requirements, the user community, IT system technology, and the organization's application development, testing, and support staffs. Typically the change advisory board includes the release, capacity, configuration, network, security, and systems administration managers. In addition, the change manager appoints others who have expertise relevant to the particular RFC and representatives from the group affected by the change. In this case, expertise with Exchange and hardware is very important. In fact, the change manager may decide to appoint an OEM vendor representative to the change advisory board.

The change advisory board determines the hardware upgrade schedule, according to IT executive committee recommendations. The change advisory board is also responsible for monitoring the change and it ensures that all authorized changes are coordinated and scheduled to eliminate the possibility of one change negatively affecting another change.

Step 5 – Change Is Passed to the Change Owner

The change owner is responsible for planning and implementing the hardware upgrade once it has been approved and scheduled by the change management process. The change owner will provide feedback to the change advisory board, the change manager and perhaps the change initiator during the implementation. However, the change manager remains involved at this stage, monitoring what the change owner is doing.

After the upgrade is complete, the change owner will help the change manager and change initiator assess the impact of the change.

All of this may seem to be a deeply complicated process, but remember this describes a major change to the environment. Minor changes would pass through a significantly simpler path, involving the change owner.

Step 6 – Change Process Evaluation

After the change is implemented, the entire change management process from receipt of RFCs through implementation must be evaluated. This is done by conducting personnel interviews and reviewing documentation. The main objective is to assess the effectiveness of the change process. Unsuccessfully implemented changes should also be evaluated so that problems can be identified and corrected before further changes are initiated.

Figure 3.1 illustrates the change management process, with the parties responsible for each stage. (For the sake of clarity, this diagram largely ignores inter-related areas of management such as configuration and availability management.)

Figure 3.1: The Change Management Process

Minor and Standard Changes

The advantage of minor and standard changes is that individuals with less authority can be pre-assigned the permissions to perform them. This is perfectly fine, because the changes themselves are not likely to cause significant problems when implemented. Of course, the change manager, and perhaps the change advisory board will, at some point, have determined whether a particular change is minor or standard. However, once this is done and the nature of the change is documented, the change owner can be pre-authorized to either perform the change in person or to delegate that authority to another person.

A classic example of a standard change is the addition of a user. This type of change should have been anticipated, so the change manager will have already pre-authorized the change owner to be responsible for this change. The change should be thoroughly documented with standard settings for items such as mailbox size limits and deleted item retention time.

Scripting Minor and Standard Changes

Although minor and standard changes do not take very long, they are among the most repetitive of tasks and therefore the ones most likely to benefit from automation.

To further reduce the amount of time spent on these tasks, you may want to consider using automated tools. Using the example of mailbox creation, the change advisory board may have previously categorized users according to job role. There would be a series of pre-defined settings for each type of user. Administrators could then use a Web-based tool to create the users, specifying the job role. Scripts would run against Microsoft Active Directory™ service to place the user in the appropriate Microsoft Windows® 2000 groups and create the Exchange 2000 mailbox with the appropriate settings for that user.

Over time, your team will build a set of custom tools that are used frequently to administer standard changes. Those tools and others will likely be used for implementing larger changes. Treating these tools and procedures as configuration items and managing their evolution over time is another example of the close relationship of change management and configuration management.

Security

A very important part of effective change management is your security infrastructure. If you do not carefully control who is capable of making which change, you can end up with undocumented and unauthorized change occurring in your organization. You should always ensure that your administrators only have rights to perform tasks that they have been specifically pre-authorized to perform. In Exchange 2000 Server, administrators require View Only Administrator rights over the Exchange 2000 organization if they are to create and modify user accounts.

Software Control and Distribution

Updating software represents significant change. It can have a major impact on users, and as such it should be planned very carefully to ensure that the update has minimal impact on users. (Occasionally such a change may be urgent, and under those circumstances you will not have time for thorough planning, but you should still plan as much as possible).

In a multi-national company with distributed administration, one of the challenges can be to ensure that software updates are distributed as smoothly as possible. One solution to this is Microsoft Systems Management Server, while another is to use the software assigning and publishing functionality of Windows 2000.

Documentation

Linking all of the change management process together is the very strong need for up-to-date, complete, and accurate documentation. Without thorough documentation, many of the benefits of change management will be lost for your organization.

Thorough documentation is invaluable when implementing recurring changes. One of the main benefits of thorough documentation is that it can turn major or significant change into minor or standard change. Many changes are major or significant simply because you have never made them before. But if you have, and you have documented standard procedures that allow you to avoid downtime and periods of poor performance for users, it may allow your IT executive committee or change advisory board to pre-authorize that change for the future, significantly reducing the number of steps required to make the change the next time.

You should ensure that entire process of change is properly documented in the change management log. The log contains information about the change, including RFC status, schedule information, and work orders. It is the responsibility of the change initiator, change manager, and change owner to ensure that you have appropriate documentation about the change. Change management should also work closely with configuration management to ensure that all changes to IT components are properly documented in the configuration management database, which is a repository used to track the status of all components of the IT environment. (For more information, see the "Configuration Management" section later in this chapter.)

Of course it is not enough just having the data available, it needs to be easily accessible by those who need it, easily searchable, and of a standard form. This allows others to get to and understand the data when they see it. If you have a good knowledge management system in your organization, you are able to ensure that the documentation is available to the appropriate people where and when they need it. By implementing Exchange 2000, you will already have many of the tools to create a good knowledge management system! RFCs can be easily submitted via Microsoft Outlook® messaging and collaboration client forms and the change management log stored in public folders, indexed using full text indexing.

Configuration Management

You cannot accurately know where you want to go today, or indeed how to get there, unless you know where you already are. Configuration management is a process which determines and records exactly that.

Configuration management is responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other components of the IT environment under the control of change management. These items are referred to as configuration items and all changes to them are recorded and tracked throughout the component lifecycle.

Central to configuration management is the configuration management database. The configuration item data controlled by configuration management is stored in the configuration management database, which is a relational database used to track configuration items in the IT environment.

What makes configuration management so useful to your organization is that the relationships and dependencies between configuration items are recorded. As a simple example, imagine that an RFC is submitted to the change manager, requesting a memory upgrade on all of your domain controllers. Assuming that the request is approved, the configuration management database can be checked to see which users and which applications will be affected when that server is taken offline. In this case, because Exchange depends upon domain controllers for its functionality, the configuration management database would indicate how Exchange 2000 Server functionality would be affected and the resultant impact on the users. The users can then be forewarned of the impending problems so that they can plan their activities around it.

Another example is hardware tracking. Imagine that your hardware vendor releases a new firmware version for the standard network adapter that you use in some or all of your servers. If you track firmware versions of each network adapter, and the relationship of each network adapter to a system, and the relationship of a system to a rack location, it is straightforward to identify the physical location of each network adapter requiring the firmware upgrade.

Tools for Configuration Management

There are numerous good tools for performing configuration management. It is not necessary to write your own tools in most cases, especially because the existing tools are very configurable. Before you spend much time on defining the exact form of your configuration management, examine the capabilities and limitations of each tool. This allows you to determine how your configuration management process may need to be modified to accommodate the vagaries of your chosen tool.

Configuration Management and Change Management

Configuration management is intrinsically linked to change management. In fact, only items that come under the control of change management are entered into the configuration management database. Configuration items are initially entered into the configuration management database when RFCs are approved for implementation by the change advisory board or the IT advisory committee. From this point on, changes to and status of the configuration items are recorded in the configuration management database.

Therefore, the configuration management database acts as a historical record of changes to the environment and maintains a "picture" of the existing IT environment. After they are logged into the configuration management database no changes to configuration items in the IT environment should be made without authorization from change management by following the RFC process as discussed in the change management process. Change and configuration management work closely together to ensure that a clear and complete "picture" of the environment is always available.

Configuration Items

Configuration items are objects that fall under the category of change management, and are therefore subject to change. In Exchange 2000, configuration items include the following:

Exchange Server hardware
Domain controller hardware
Hardware vendor
Server role (that is, a server running Exchange or domain controller)
Windows 2000 software
Exchange 2000 Server software
Service Packs
Hot fixes
Anti-virus software
Fax/voice mail Gateways
Monitoring software
Backup software
Network equipment connecting the servers
Processes and procedures
Documentation
Exchange users
RFCs

Each configuration item will have attributes associated with it. Take as an example the Exchange software. It will have the following attributes associated with it:

A software identifier
The RFC identifier that led to the current software version
The name of the application (for example, Exchange 2000 or Exchange 2000 Server Enterprise Edition)
The version number of the software
The date the current version was installed
The latest Service Pack installed
The latest hot fix installed
The vendor who supplied the current software (for example, Microsoft Corporation)
The documentation required to support the current version of the software

The number of configuration items depends on the level of granularity you choose when defining them. It is, of course pointless to store configuration items that you will never use. A simple configuration management database will give you much less data to store and so will be much less work to store. However, if you do not have data at a sufficiently granular level, you will limit the effectiveness of the configuration management database.

You can always add more detailed information at a later date, if you want. However, despite the initial pain, you will generally find it better to set your granularity of configuration items at the level of the lowest replaceable unit. In terms of servers running Exchange, this would be, for example at the RAID Controller, or network adapter level. For example, this allows you to change every network adapter in every server running Exchange in your organization, and effectively monitor and manage that change.

Configuration Management Relationships

Many of the main benefits of configuration management come from the relationships between the configuration items that are defined in the structure of the configuration management database. Getting these relationships correct is vital for successful configuration management.

The relationships grow more complex the more configuration items you have. To see the principle, take a very simple example, with only six configuration items, showing a simple relationship between Exchange hardware and software, as illustrated in Figure 3.2.

Figure 3.2: Six Configuration Items and Relationships Between Them

Figure 3.2: Six Configuration Items and Relationships Between Them

Here the server itself is obviously hardware, but it also represents the software that is to installed on it. These elements depend on each other. If there was no hardware, Exchange would have nothing to be installed on, and if there is no Exchange 2000 software, there is little point in having the hardware.

Here, the printer is related to the server because it is connected to it. Exchange 2000 Server is licensed to the server hardware. The hot fix is another configuration item, but one that clearly has a relationship to the server running Exchange on which it is installed.

Of course with more configuration items, this process is significantly more complicated. To see this, take a look at a slightly more complex example. Figure 3.3 illustrates nine types of configuration items, with suggested relationships between them.

Figure 3.3: Nine Configuration Items with Relationships Between Them

Figure 3.3: Nine Configuration Items with Relationships Between Them

As you can see, there is still a fairly small number of configuration item types at this stage, although the configuration items themselves will differ in a substantial way (for example, anti-virus software will have significant differences from Exchange 2000 hot fixes).

Defining Configuration Items

When defining configuration items you need to decide how deeply you want to go in recording the them. Too many configuration items makes the relationships too difficult to manage and costs start to increase. There are strong benefits to making the configuration management database as simple as possible to actively reflect the environment in which it is working, then adding in additional configuration items as and when they are required.

Configuration Management and Exchange

One of the main barriers to implementing configuration management in an organization is the perception that it must be implemented throughout the organization or not at all. This is by no means true. Configuration management can effectively apply to one part of the organization without touching other parts of it. It is true, of course, that the more widespread configuration management is in a company, the more cost-effective it becomes, but this does not preclude you from implementing configuration management cost-effectively in your company, even if it affects only Exchange.

In many cases, setting up configuration management for Exchange proves to be a pre-cursor to setting it up elsewhere. You should not be afraid of starting with Exchange for the configuration management process if it has not been implemented before in your company.

In the example of upgrading the servers running Exchange shown previously, you can see from the simple set of relationships, that upgrading the hardware affects a series of related areas:

At the very least, new hardware may affect the following elements of the configuration management database:

User roles. All users who have their mailboxes located on the server may have service interrupted and after the upgrade should expect better service. Consulting the configuration management database should reveal the identity of these users.
The RFC. An RFC will have been submitted to initiate this change. The RFC status will be altered as the change is implemented
Vendor. If the new hardware is from a different vendor, new configuration items may be required.
Documentation. New documentation will be needed to support the new hardware in place.

Maintaining the Configuration Management Database

For configuration management to work properly, it is vital that all the information in the configuration management database is up to date and accurate. Your IT staff will very rapidly lose confidence in the system if, for example, they consult the database to find which connectors will be affected by taking a server running Exchange offline for maintenance, only to find when they actually examine the servers that different connectors are present.

The configuration management database is initially populated by an inventory of your existing hardware, software, tools, and processes. The configuration management database contents change over time as the result of implemented changes of all kinds. You will want to periodically (perhaps annually) audit the configuration management database against reality to ensure that the configuration management database and your IT environment are in synchronization.

To ensure that the database is maintained with accurate information, the following areas must be tightly controlled:

Change management
Ownership of the configuration management database
Security of the configuration management database
Backup of the configuration management database

To be effective, the configuration management database must be operated as though it is a central component of your IT environment.

Change Management

As already mentioned, change management and configuration management are intrinsically linked. If the configuration management database is to be accurate and up to date, then no aspect of change to configuration items may be carried out without that change also being recorded in the configuration management database. For this reason, RFCs are recorded in the configuration management database and are the driving force behind change in the configuration management database. By adding and modifying entries in the RFC part of the configuration management database you will also modify the components that act as dependencies.

Ownership

If your configuration management database is going to remain fully accurate, you must ensure that there is ownership of each part of the configuration management process. The configuration manager should ensure that the configuration management database is always kept fully up to date and that only authorized personnel can modify it. Exactly who modifies the configuration management database depends on nature of the relationship between change and configuration management, but in many cases different configuration items have different owners (often the corresponding change owner).

Security

Security is a vital component of configuration management. The only way in which you can maintain control over your configuration and ensure that the configuration management database is accurate is by ensuring that only authorized personnel change configuration items and that only authorized personnel can make the corresponding changes to the configuration management database.

Backup

With good configuration, the configuration management database is an essential part of your organization. It is therefore essential that you back it up regularly and can ensure that you are able to recover to the point of failure. Examine carefully the configuration management tools that you use, to ensure that you have an effective back up and restore strategy.

Exchange System Policies

Microsoft Exchange 2000 Server is equipped with policies to control recipient e-mail addresses, server configuration, mailbox store configuration, and public folder store configuration. Using Exchange 2000 system policies you can centrally manage as many or as few servers running Exchange as you desire, and you can dramatically reduce your costs in maintaining a consistent configuration across your enterprise. You can create as many system policies as you like; however, each server can have only one server policy, mailbox store policy, and one public folder store policy associated with it.

Administering System Policies

One of the main advantages of Exchange 2000 system policies is that it allows you to centralize administrative control easily. The administrative model you follow determines how you should implement system policies. It can often make sense to create one or more management administrative groups. You would give your policy administrators rights over these groups, plus any other administrative groups where you want the policies to be applied. Local administrators would have rights to their own administrative groups but not over the management groups, therefore preventing them from removing the policies or changing anything set in the policies.

When you are creating your policies, you have a choice over which settings to determine. Typically you will look to use policies to define almost every aspect of servers, mailbox stores, and public folder stores. However, think carefully before deploying the Associated Public Store parameter, because this is likely to be different for a large number of servers and would therefore in many cases require the creation and maintenance of a large number of policies.

Summary

Whatever the size of your organization, you should consider the processes described here and how they can benefit your organization. Remember that the change initiator, the change manager, the change advisory board, and the IT executive board are just descriptions of roles in your organization and can easily overlap.

Many organizations have some difficulty justifying the cost of implementing configuration management. However, for most companies, the benefits of implementing and correctly administering a configuration management process far outweighs the costs of establishing and maintaining the process. Deciding upon a level of granularity of configuration items that is appropriate for you allows you to decide upon a cost structure that will benefit your organization.

If you do not have change and configuration management in your organization currently, you can still implement it for your Exchange 2000 Server environment. It is very likely that doing so will considerably improve the efficiency and the reliability of your operations.