Service Management Functions

On This Page

	Executive Summary
	Introduction
	Configuration Management Overview
	Processes and Activities
	Roles and Responsibilities
	Relationship to Other SMFs
	Appendix: Recommended Technologies
	Copyrights and Disclaimer

Executive Summary

Configuration management is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other inanimate components of the information technology (IT) organization. The goal of configuration management is to ensure that only authorized components are used in the IT environment and that all changes are recorded and tracked.

This document discusses the main processes and activities involved in configuration management and includes the setup activities that must be performed before configuration management can be conducted.

The importance of the Configuration Management service management function (SMF) lies in the ways in which it relates to other SMFs in the Microsoft® Operations Framework (MOF) Process Model. For example, configuration management is responsible for performing a baseline assessment of the IT production environment. Change management uses this baseline assessment in evaluating the impacts of a change and depends on the accuracy of the configuration data to ensure that these impacts can be understood and communicated appropriately. During the change and release processes, configuration management is responsible for updating the CMDB to reflect all changes to CIs.

Top of page

Introduction

Document Purpose

This guide provides detailed information about the Configuration Management SMF for organizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of enterprise computing environment. This is one of the more than 20 SMFs defined and described in Microsoft Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies discussed.

An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available in the Overview section of the Service Management Function Library guide. This overview also provides abstracts of each of the service management functions defined within MOF. Detailed information about the concepts and principles of each of the frameworks is also available in technical papers available at http://www.microsoft.com/mof.

What’s New?

This Configuration Management SMF has been revised to bring it into compliance with MOF version 3.0. It now includes information about how the newest MOF Team Model role cluster, Service, is involved in each step of the configuration management process.

Feedback

Please direct questions or comments about this SMF guide to msmfeed@microsoft.com.

Top of page

Configuration Management Overview

Goal and Objectives

Configuration management is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other inanimate components of the information technology (IT) organization. The goal of configuration management is to ensure that only authorized components, referred to as configuration items (CIs), are used in the IT environment and that all changes to CIs are recorded and tracked throughout the component’s life cycle. To achieve this goal, the configuration management process includes the following objectives:

Key Definitions

Configuration baseline. A configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system and enables that product or system to be rebuilt at a later date.

Configuration control. Activities that control changes to configuration items. They include evaluation, coordination, approval, or rejection of changes.

Configuration item (CI). An IT component that is under configuration management control. Each CI can be composed of other CIs. CIs may vary widely in complexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component.

Configuration item attributes. The information recorded in the CMDB for every configuration item identified, ranging from the item's name, description, and location to technically detailed configuration settings and options.

Configuration management database (CMDB). A database that contains all relevant details of each configuration item (CI) and details of the important relationships between CIs. The database can include ID code, copy and serial number, category, status, version, model, location, responsibility, or historical information about the item. The level of detail contained in this database depends either on the aims or on the degree to which information is to be available.

Configuration manager. The role that is responsible for managing the activities of the configuration management process for the IT organization. The role also selects, assigns responsibilities to, and trains the configuration management staff.

Top of page

Processes and Activities

Process Flow Summary

Configuration management is graphically represented in the form of a process flow diagram (Figure 1) that identifies the activities needed to successfully manage and control key components of an IT infrastructure.

Figure 1. Configuration management process flow

This high-level overview can be further broken down into a number of detailed activities and process flows, which are summarized below. Together these detailed activities and process flows provide a comprehensive blueprint for the configuration management process.

Establish Configuration Items (CIs)

Assuming the need to track and control changes to an IT component, the process of adding an item to the CMDB involves first deciding upon the appropriate level of detail necessary to track and control change. Next, configuration items (CIs) are created in the database to permit management of components at this level.

One of the key benefits configuration management provides, in addition to asset management, is the modeling of relationships between IT components. These relationships need to be identified and connections built between configuration items in order to model the real-world situation. For example, a workstation is made up of a desktop computer, operating system, and applications, and the workstation is connected to and uses the network. The proper understanding and documentation of relationships between IT components makes it possible to perform detailed impact analysis on a proposed change.

Access Configuration Items

After information about IT components and relationships has been added to the CMDB, it can then be used by other SMFs. Change management, for example, uses the relationships defined within the CMDB to determine the impact of a change on other components within the IT environment. Problem management uses the CMDB as a resource to identify which CIs are the root cause of incidents, and so on.

Change Configuration Items

As release management begins to make changes to IT components, corresponding changes must be made to the CMDB. Without accurate and up-to-date information, the value of configuration management is lost. This process should be done automatically, wherever possible. The amount of information and the frequency of change make manual data entry impractical for all but the smallest organizations.

Review Configuration Items

The accuracy of the information stored in the CMDB is crucial to the success of the Change Management and Incident Management SMFs, as well as other service management functions. A review process that ensures that the database accurately reflects the production IT environment needs to be established.

Note   A more fundamental review should also be carried out at periodic intervals to establish whether the information in the CMDB is relevant to the business and is being managed at the correct level of detail.

Setup Activities

Prior to initiating the configuration management process flow activities described above, a number of detailed setup and planning activities must be completed in order to use configuration management effectively. The following process flowchart (Figure 2) identifies these activities and the sequence in which they should be performed.

Figure 2. Setup activities for configuration management

One-time configuration management setup activities necessarily precede the daily, ongoing configuration management process and involve a great deal of decision making and planning. Setup activities begin with deciding upon specific aims and objectives (the purpose) the organization intends to achieve by establishing a configuration management process. Issues to be considered include the scope of the IT environment to be managed and the level at which it needs to be managed. Participants in the discussions of purpose should include representatives from all parts of the organization that will be affected, and business relevance should be a guiding decision factor.

A second major setup activity involves identifying the entire set of IT components that exist within the agreed management boundaries. This leads to more decisions: determining the subsets of these components that need to be managed.

With very few exceptions, all the information necessary to manage the selected IT components needs to be stored in a CMDB hosted in a database product. Building the CMDB is the third major setup activity. It includes building table definitions and creating outline reports. An organization may have one or more CMDBs.

Finally, setup also includes design and development tasks that are specifically related to use of the CMDB. Policies and procedures for using the database, such as designing security and access restrictions and developing maintenance routines (which include backup and recovery procedures), must be established. Only after these have been accomplished can the database be populated.

Configuration management setup activities typically involve all of the MOF Team Model role clusters. Their involvement varies, however, based on the particular role cluster, as shown in Table 1.

Table 1. Involvement of MOF Team Model Role Clusters in Setup Activities

Agree on Purpose

The first and most important step in any project leading to the deployment of configuration management is to reach an agreement on its purpose, articulated in terms of key aims and objectives. These will act as terms of reference, helping to define the level at which the organization wishes to track and control change and to identify the IT components and services that should be regarded as “in scope” of the configuration management function.

Agreeing on a purpose entails obtaining a detailed understanding of the current situation (background). The issues and problems that exist in the current environment are often the main factors behind a decision to implement this function. For example, if a number of changes seemingly unrelated to line-of-business (LOB) applications have had an impact on them, there is clearly a need to understand and model the links and relationships between these IT components. In fact, the ability to model relationships and allow change management to look at the potential impact of a change is one of the key benefits that configuration management provides.

When discussing aims and objectives, representatives from all parts of the organization that have a responsibility for IT components and services should be included. Although configuration management can be used to successfully manage IT components within a small part of the organization, the benefits are only fully realized when it is used throughout.

The following two examples illustrate how aims and objectives relate to the level of tracking and controlling change and the scope of configuration items to be managed:

Agree on Boundaries of Management

Ideally, information about all components and services of interest to change management would be recorded in a single CMDB. In practice, however, organizational issues, such as a widespread geographic structure, delegated administration, and ownership of specific IT components, will dictate the contents of a particular CMDB.

In the example just cited of a geographically dispersed organization, each country would likely want to use a CMDB that contains only the local resources (the resources for which it is responsible). This ensures responsiveness and keeps database size and complexity to a minimum.

In most cases, the impact of a change to the local environment is restricted to the country in which the change is applied, so there is little need to maintain configuration data about IT components in other countries. The installation of corporate standard software on a client in Edinburgh, for example, has no impact on similar clients in Cambridge or Seattle.

There are some changes, however, that will impact IT components on a much larger scale. If a change request requires that the Microsoft Windows NT® 4.0 master domain (which contains all user accounts) be upgraded to Windows .Server™ 2003, users in more than one country and location could be affected by it.

A best practice would be to create processes and procedures that ensure other groups are notified whenever certain types of changes are proposed. The types of changes that could fall into this category include upgrading or replacing international lines or working on network services linked to a critical LOB application.

The responsibilities and placement of the service desk and the support model should also be considered at this point. If the service desk uses the “follow the sun” model (using geographic time zones to cover a 24-hour day) to provide 24x7 support, it must be able to access the CMDB that contains the IT components mentioned in the call. If a single database is not being used, it may be necessary to make a local copy of any remote CMDB to reduce the impact of network delays and to ensure that support personnel can access the data in case of a network failure.

After the geographic organizational issues have been resolved, another organizationally related aspect of scope that needs to be considered is the type of resources that might be recorded and tracked in the CMDB.

For example, the setting up of a desktop computer and operating system is normally the responsibility of the IT department, but the setting up of a work area, which includes desk, chair, and telephone, is the responsibility of facilities. A new employee requires a desktop computer (from IT) and a telephone, desk, and chair (from facilities). If information from both groups were to be recorded in a single CMDB, it would be quite simple to identify and coordinate delivery of the infrastructure components necessary to support the new user.

In practice, however, the CMDB is likely to contain information about IT components and services only. Facilities normally uses another system, such as the asset register, to manage the resources it owns. A manual procedure needs to be established that ensures that both groups are informed of changes that affect the resources under their control.

Establish Standards for Configuration Management

Configuration management is only as good as the policies and procedures governing its activities. This includes the procedures that are used in the performance of such configuration management tasks as updating the CMDB, performing audits, reconciling the CMDB, and preparing management reports. All configuration process activities should be clearly defined and documented.

The policies and procedures that define the relationships and interaction between configuration management, change management, and release management must also be defined. Without proper planning and communication between these groups, the objectives of the configuration management process cannot be realized. Security guidelines should also be established that provide guidance on how these groups should interact.

Definition and documentation of configuration management standards is a best practice, as is maintaining the standards as a single document in a secure location.  One example of a best practice policy is: Only a few people and automated processes should have update privileges to the CMDB.

Discover IT Components

All of the IT components that exist within the agreed management boundary must be identified before it can be determined which ones are important enough to be tracked and controlled using configuration management. In this context, IT components include process documentation, reference guides, technical manuals, and build documents—in addition to software applications, operating systems, network routers, workstations, and servers.

An extensive audit is needed to identify the different types of hardware and software deployed within the agreed management boundary and to collect the documentation (both process and technical) that supports that environment. The audit should also identify relationships between IT components. For example, all workstations are built using the Microsoft Windows® XP client build document.

Decide What Needs to Be Managed

Managing and tracking change for every single component within even a small IT environment would be impractical. Over and above the challenge of obtaining and loading all of this information into the CMDB, the costs involved in maintaining and updating it would be prohibitive.

Therefore, choices need to be made concerning the subset of components to be managed. This requires considering the business relevance and importance of the component and the relationship(s) it has with other components within the IT environment. Best practice calls for managing only those components that:

The decision to include a component in the CMDB should be reviewed at periodic intervals.

Build CMDB

The CMDB provides a single source of information about the components of the IT environment. This information can be used within the organization to improve system reliability, availability, and control. By establishing a database to track IT components, known as configuration items (CIs), configuration management can verify that only authorized components are used in the IT environment. Why is the use of only authorized components so important? This is an important aspect of control, because an unauthorized component introduces an unknown that could have undocumented, detrimental, and/or difficult-to-trace effects on related components.

This single source of information also provides other organizational groups, such as the service desk, incident management, and problem management, with the ability to quickly and accurately assess the impact and cause of incidents and problems. This leads to a faster resolution of problems and a reduction in system downtime. The result is improved availability and reliability of the IT environment. For example, supplying a quick answer to a user’s question typically requires knowledge of the user’s hardware and software configuration. With a CMDB, this information is available at the fingertips of the service desk staff.

In addition to selecting the tools and technology to host the CMDB, a number of setup and initialization tasks need to be performed before the database can be populated with information about managed IT components and relationships. These tasks include:

The tasks needed to be accomplished at this stage depend on the database product selected and the complexity of the IT environment to be managed.

Once these setup activities have been completed, the process flow activities required to carry out configuration management can take place.

Establishing Configuration Items

The process flow that leads to the identification of configuration items and relationships and their subsequent addition to the CMDB is shown in Figure 3.

Figure 3. Establishing configuration items process flow

Tracking and controlling changes to an IT component involves adding it to the CMDB. This assumes that previously, in the setup stage, the desired level of detail at which to track and control change was identified, and CIs were created in the database that permit managing the component at this level.

When the component is recorded in the CMDB, relationships can be built between CIs to model the real-world situation in which IT components are connected to and dependent upon one another. For example, a workstation is made up of a desktop computer, operating system, and applications, and the workstation is connected to and uses the network. The proper understanding and modeling of the relationships in the CMDB makes it possible to perform detailed impact analysis on a proposed change.

Identifying CI activity is managed by the Release Role Cluster, but other Team Model role clusters also have some involvement, as shown in Table 2.

Table 2. Involvement of MOF Team Model Role Clusters in Establishing Configuration Items

Does an Asset Need to Be Tracked and Controlled?

The initial setup and preparation activities should have included defining the list of IT components needing to be placed under the control of configuration management. As new components and assets are identified, they should be added to the CMDB only if they appear on this list.

The decision to include or exclude an IT component from the CMDB needs to be periodically reviewed to ensure that the database supports the needs of the organization and the service management functions using it.

Determine the CIs to Be Managed

Adding an IT component to the CMDB involves establishing it as a CI or CIs. To choose the appropriate CIs requires referring to the organization’s customary level of detail for tracking and controlling change. Then, in the database, CIs can be created that permit managing the component at this level.

Using a workstation as an example, a workstation has several components: the installed operating system, software applications, processor, and memory.

To manage this workstation, organizations normally use configuration items that represent the workstation as a whole, including the operating system and installed software applications. However, in some situations, CIs could be created to represent each of these components, resulting in the ability to track and control change at a high-level of detail. And there may be some specialist organizations, such as personal computer hardware manufacturers, which need to include configuration items that allow them to track and control changes (at a very high-level of detail) to the graphics card, network card, and motherboard installed in a particular model of personal computer.

Although it is possible to do so, the benefits of tracking change at a high-level of detail may be vastly outweighed by the administration and management costs required to keep the CMDB up-to-date. Because each organization has different aims and objectives, there are no clear guidelines as to what constitutes a correct level of decomposition. However, the available time, resources, and technology should be considered prior to making a decision. This is the type of issue that must be explored during the initial discussions of the purpose of configuration management in the organization.

Note   It is not necessary to track changes to items that an organization regards as consumables—items that generally have a low monetary value. The mouse and keyboard attached to a workstation often fall into this category.

Identify Relationships and Dependencies Among CIs

One of the key benefits of configuration management as compared to asset management is that configuration management models relationships between IT components. To do so, these relationships must first be identified and connections built between configuration items to replicate the real-world situation.

If the Internet Protocol (IP) address for a DNS server is changed, for example, it is then necessary to change the DNS resolver setting for all clients that use this server for name resolution. If the relationship between the DNS server and its clients is not maintained in the CMDB, it is possible that some clients will be missed, thereby preventing them from gaining access to network resources.

Identifying some relationships is relatively easy, while others may come to light only as changes are made to components within the IT infrastructure. It is advisable to focus initially on identifying the key relationships—those that are essential to the successful operation of the component and the infrastructure in which it is deployed—and then add in additional relationships as needed.

Relationships between IT components are modeled by building links between configuration items in the CMDB. When changes are proposed to a configuration item, these links can be used to identify the configuration items that may be impacted by that change. Making a change to a configuration item may not impact all the configuration items it is related to, and rules may be needed to ensure that only the relevant configuration items (those that will be affected by the change) are identified during impact analysis.

If a workstation’s memory is increased from 256 MB to 512 MB, for example, this has no impact on the network the workstation is connected to. However, the network would be affected by a proposal to install a video conferencing application that requires a substantial (and dedicated) amount of network bandwidth.

It is not practical or even possible to define automated rules that cover all eventualities. The identification of configuration items affected by a change may require a combination of automated rules and the skills and experience of technically qualified staff.

Select CI Attributes

For every configuration item identified, there is normally a great deal of information that could be recorded in the CMDB, ranging from the item’s name, description, and location to technically detailed configuration settings and options.

As will be emphasized throughout this document, the value of configuration management is entirely dependent on the quality and accuracy of the information contained in the CMDB. If too many attributes are selected, keeping this information accurate and up-to-date can be costly and time consuming. It is far better to select only those attributes that are needed to manage the configuration item and for which the organization needs to monitor and track change.

A configuration item (CI) that describes a software application, for example, could have the following attributes:

It is also possible to create and store attributes that summarize lower-level details or contain values that are calculated by processing or filtering information. The need for these types of (processed) attributes depends on the requirements of each organization and the level at which configuration items have been identified and defined.

Add CI(s) to CMDB

The next major process to be conducted after identifying (or discovering) the configuration items and their relationships and selecting the attributes that represent the managed components of the IT infrastructure is to add this information to the CMDB.

The first step in this process is to look at each configuration item (CI) and work out the best way to obtain the value (an assigned or calculated numerical quantity or an alphabetical entry that describes an attribute) of each attribute to be managed. These values are often recorded in a number of different places and it must be decided which of these should be used to populate the CMDB.

The IP address of a network server, for example, may be found in DNS, in the database of an automated inventory system, or even in a manually maintained Internet Protocol (IP) address register. It is also available locally.

In selecting an information source, consider the information’s accuracy, whether it is up-to-date, and the difficulty and cost-effectiveness of retrieving it. In the example above, the server’s IP address would probably be obtained from the automated inventory system in preference to DNS or the IP address register.

The next step is to decide how to retrieve the information. It is usually more efficient to obtain attribute values automatically by developing a tool that connects to the information source and extracts the needed information. In some cases, this approach is not cost effective or even possible, and some information has to be entered manually. Due to the time-consuming and error-prone nature of manual data entry, however, it is best to try and keep this to a minimum.

Note   The tools and processes developed to retrieve attribute values from the information source will be needed whenever it becomes necessary to compare database values with those in the production environment (database verification).

After these preparatory steps have been completed, the third step is to initiate a change request that describes the configuration items, attributes, and relationships to be added to the CMDB. The request should also describe the mechanism by which attribute values will be populated.

Assuming the change request is approved, the configuration manager or an approved deputy should update the database structure to include the new configuration item(s), attributes, and relationships. The attribute values should then be populated using the tools and techniques identified in the change request.

All relevant document properties must be completed prior to storing a document in the production CMDB.

Accessing Configuration Items

After the configuration items and their attributes and relationships have been recorded in the CMDB, people or automated processes carrying out other service management functions can request access to that information, as shown in the process flow diagram in Figure 4.

Figure 4. Accessing configuration items process flow

Two primary and common CI access scenarios generally occur, for example, when the change management function uses the relationships defined within the CMDB to determine the impact of a change on other components within the IT environment, and when the problem management function uses the CMDB as a resource to identify which CIs are the root cause of incidents.

Accessing a CI can potentially involve all of the MOF Team Model role clusters, but their involvement varies according to their area of responsibility as shown in Table 3.

Table 3. Involvement of MOF Team Model Role Clusters in Accessing Configuration Items

Request for Information

A request for information in the CMDB may originate from within an SMF at any time. Information may be required about a single configuration item or multiple configuration items, using the relationships and dependencies to conduct an impact analysis (as in change management).

In organizations with more than one CMDB, a number of separate requests may be required to establish the true impact of a change. To understand the impact of replacing a transatlantic line, for example, staff members engaged in change management may need to request information from databases located in both Edinburgh and Seattle.

To achieve the needed results, requests for information must take into account the part(s) of the environment that are modeled in a particular CMDB. If desks, chairs, and telephones are not included in the CMDB, for example, then queries must be issued against other databases (such as the asset register) to gain the needed information. The implication is that personnel making requests directly and programmers setting up automated requests should both be familiar with the kinds of information contained in the CMDB.

Note   Access rights and controls are also required to ensure that only authorized users access information stored in the CMDB. Even among this group, there may be a requirement to restrict access to sensitive information. For example, only certain users should be able to view detailed attributes of a network router. Security guidelines, policies, and access restrictions should have been established during the configuration management setup process.

How is information requested?

Assuming authorized access, information retrieval may be performed within the CMDB application or through published interfaces.

Present Information

How the information is presented to the requester is dependent on the method or tools used to request the information. The information may be made available online through a Web reporting tool or database query or delivered through hardcopy reports.

Note   The value of the information returned to the requesting service management functions depends entirely on the quality of the information stored within the CMDB. To achieve the anticipated benefits, information within the database must be complete, accurate, and up-to-date. Maintaining these aspects of quality is a responsibility associated with the “change CI” and “review CI” steps. Regular reviews (the last step of the configuration management process flow) should be held to ensure that the database and hence the information returned to an SMF accurately reflect the status of the production environment.

If, for example, some critical configuration item relationships and dependencies are missing from the CMDB, then the information returned to change management during impact analysis will be incomplete. As far as configuration management is concerned, however, the information retrieved and presented to the requesting SMF is complete.

To make it very easy to use these tools, the information needs to be presented in a simple and logical manner. One point to consider here is the naming standards for the CMDB fields—when “as needed” reporting is involved, the name of the field should be immediately understandable.

Sometimes the presentation of information contained in the CMDB suggests the need for a change in a configuration item. In this case, the regular change process must be followed, including approval and authorization through change management, before physical changes can be made to the IT component. Only then is the corresponding information within the CMDB changed.

Changing Configuration Items

As changes are made to IT components during the release management process, corresponding changes must be made to the configuration items and relationships that model them in the CMDB. If managed IT components in the live environment are changed without mirroring them in the CMDB, information within the database quickly becomes out-of-date or inaccurate, and the value of configuration management to other SMFs is significantly reduced. Whenever possible, the release mechanism should make these changes automatically; but in practice, this is not always possible. Manual data entry may sometimes be required to keep the database up-to-date.

The following process flow diagram (Figure 5) highlights the fact that changes to IT components are rarely done in isolation. The relationships and inter-dependencies between IT components can often mean that a change to one component has an impact on another, forcing a change in or update of the other.

Figure 5. Changing configuration items process flow

Adding video conferencing facilities to a workstation, for example, has the effect of increasing network utilization whenever conferences are in progress. If the local area network (LAN) is already running at capacity, video conferencing sessions cannot be run without making changes to other IT components and services. To resolve the problem, the workstation could be moved from one network segment to another, the LAN could be re-segmented to reduce utilization, or another solution could be found.

In all cases, however, a change must be made to one or more related IT components before video conferencing can be deployed and used successfully. Note that these changes must also be agreed upon and approved through the change management process. Assuming that approval is given, the CMDB needs to be updated with the original change (add video conferencing to workstation) and the additional changes required to support it (move workstation to new network segment).

The changing configuration items activity is managed and owned by the Release Role Cluster, but each of the other team roles may also be involved in this activity, as shown in Table 4.

Table 4. Involvement of MOF Team Model Role Clusters in Changing Configuration Items

Change CI

There can be a substantial delay between change management approval and the eventual (full) deployment of that change into the production environment by release management. To make sure that the CMDB takes account of this delay and accurately reflects the state of an IT component, the CMDB must be updated at least twice for every change—once when the change is first approved and again, when it has been completed.

The initial update, at change approval, is required to ensure that an SMF querying the database for information about a particular configuration item can be notified about upcoming changes. The information added to the database at this stage should include the RFC, the date of the proposed change, and a status indicator that shows that a change(s) is (are) pending.

Note   More than one RFC may be pending for a particular configuration item. A server, for example, could have these RFCs pending: upgrade server memory from 256 MB to 512 MB (RFC1) and install SQL Server (RFC2).

Over its lifetime, a configuration item is likely to be updated a number of times. A history of changes (with dates) should be maintained to provide the Problem Management SMFs and other SMFs with a view of changes made over time. If a change needs to be rolled back and the IT component restored to its previous state, this information will be invaluable.

If SMS is used to roll out software applications or to roll back an installation, then a “receipt of advertisement successful (or failed)” message can be used to trigger a CMDB update. Note that a program that is tied into the status message system (and particular messages) is required to write the update into the CMDB.

Change Dependent CI

As explained previously, the relationships and inter-dependencies between IT components can often mean that a change to one component affects another. In some cases, it is necessary to make additional changes to support the original change.

To install Microsoft Windows Messenger 4.6, for example, a workstation must be running Windows XP. If the installed operating system is currently Microsoft Windows 2000 or Windows 98, the operating system must be upgraded before Windows Messenger can be installed. In addition, the client might not have sufficient memory or disk space for Windows XP and further changes will be required to bring the computer up to the required specification.

Because the goal of configuration management is to provide a model of the production environment, the CMDB must record and track the original change and all of the subsequent changes required to support it. In the example above, changes to the operating system, memory, and disk space need to be tracked in the CMDB. Only when all of these changes have been successfully completed can the installation of Windows Messenger begin.

Reviewing Configuration Items

Because the accuracy of the information stored in the CMDB is crucial to the success of the Change Management and Incident Management SMFs as well as other SMFs, a review process (shown in Figure 6) should be set up to ensure that the database accurately reflects the production IT environment.

Figure 6. Reviewing configuration items process flow
See full-sized image

At regular intervals, configuration management staff should perform an inventory (and audit) of managed components within the production environment and compare the information retrieved with that stored in the CMDB. Assuming that no differences exist, the date and time of the comparison should be recorded for tracking purposes.

If differences do exist, however, the action to be taken (if any) depends on a number of different factors. If an approved change has been deployed but the information within the CMDB is out-of-date, the likely choice is to update the database to the current value. However, if the CMDB indicates that Windows XP, for example, is installed on a workstation, and the actual installation is Windows 98, the issue would be raised with incident management.

It is also recommended to periodically check that the configuration items recorded within the CMDB are still relevant to the business and enable the organization to manage the IT environment at the correct depth (level of detail). Similarly, the accuracy of the agreed management boundaries or scope of configuration management should also be confirmed. (This type of architectural review is not shown on the process flow diagram.)

The reviewing configuration items activity is also managed and owned by the Release Role Cluster but, similar to other configuration management activities, each of the other Team Model role clusters may be involved.

Table 5. Involvement of MOF Team Model Role Clusters in Reviewing Configuration Items

Perform Inventory Collection

The first phase in the review process is to obtain information from the production IT environment. This can be accomplished in a number of different ways, but it should be automated as much as possible. Manual auditing of IT components and assets is often expensive and time consuming and the results are often out-of-date before the information has even been analyzed.

Compare Inventory with Information in CMDB

After the needed information has been collected from the production environment, it can be compared with that stored in the CMDB. As with inventory collection, this task should be automated as much as possible. If collection was manual, for example, the information can be added to a spreadsheet or database application, which can then be used as an input to the mechanism used to validate the CMDB.

If there are no differences between the inventory value and that recorded in the CMDB, the date and time the comparison was made should be recorded for tracking purposes. Although the two values may match, a further check should be made on pending changes. If the “implement by” date for a change has expired but the live environment remains the same, then the issue should be escalated to incident management.

An example: A change request is created and approved to deploy Microsoft Office XP on all workstations before the end of the month. At the end of the month, the CMDB information is reviewed. For some workstations, the CMDB reports that Office 2000 is currently installed but an installation of Office XP is currently pending. If the inventory process confirms that Office 2000 is still installed, the issue needs to be raised with incident management.

If there are differences between the production environment and the CMDB, the action to be taken depends on a number of factors:

In all cases, however, the difference between the CMDB and the production environment should be logged, together with any actions taken (if any). This log may be required when evaluating the success of configuration management within the organization.

Top of page

Roles and Responsibilities

This section describes the roles and associated responsibilities of the configuration manager and the configuration management staff. It is important to note that these are roles, not job descriptions. A small organization may have one person perform several roles, while a large organization may have a team of people for each role. It is always recommended, however, that the configuration manager role be performed by just one person.

The roles also correspond to the roles defined within the seven role clusters of the MOF Team Model. These role clusters (Release, Infrastructure, Support, Operations, Partner, Service, and Security) represent at a high-level the operations functions that must be performed in an IT environment to achieve successful operations. The individual roles within each role cluster are closely related to one another.

The significant roles defined for the configuration release management process are:

Configuration Manager

The configuration manager is responsible for defining the processes and procedures that govern management of the CMDB. The person in this role is a member of the change advisory board (CAB) and works closely with the change manager to ensure that the impacts of proposed changes are known prior to changes being authorized and that all changes to the IT environment are recorded accurately in the CMDB.

For more information about the CAB, refer to the Change Management SMF guide.

Configuration Management Staff

The size of the configuration management staff depends on the size of the organization, the size and frequency of changes and releases in the IT environment, the automation of the CMDB, and the granularity at which CIs are recorded in the CMDB. The configuration manager should ensure that sufficient staff is available to prevent the configuration process from becoming an impediment to the successful operation of other related processes.

If an organization is spread across multiple geographic locations, staff members may be required at each location. In a small organization, participating as a member of the configuration management team may be a collateral duty. However, in large organizations, being a member of the configuration management team is a full-time position—with the staff segmented into multiple groups, each responsible for managing specific areas of the IT environment. If the configuration management staff is segmented into separate groups, close coordination must occur between staff members to prevent updating errors.

When defining the CMDB management processes and procedures, the configuration manager needs to establish appropriate control mechanisms to ensure that the information recorded in the CMDB by the configuration management staff is accurate and complete.

Table 6 summarizes the responsibilities associated with each of the configuration management roles.

Table 6. Configuration Management Roles and Responsibilities

Top of page

Relationship to Other SMFs

There is a close relationship between the three service management functions (Change Management, Configuration Management, and Release Management) that make up the MOF Changing Quadrant. Figure 7illustrates the relationship that exists between these three SMFs.

Figure 7. MOF Changing Quadrant process flow

Change management:

Configuration management:

Release management:

All other service management functions have a relationship to change management in that there is a direct effect on each SMF as change management is applied to that particular area. This not only applies to each of the technical areas covered within the Operating Quadrant, but also to changes that may affect the SMF processes in the Supporting and Optimizing quadrants.

Top of page

Appendix: Recommended Technologies

All organizations that intend to use configuration management to track and control change to key components within their IT environment need to obtain and make use of certain tools and technologies. The appropriate number and complexity of these tools depends on the size of the organization and the number and type of IT components it wishes to manage.

This service management function guide takes a middle road by describing the tools needed to support the detailed processes that make up configuration management. The tools described here are sufficiently generic to enable all types and sizes of organizations to apply the advice.

There are a number of Microsoft tools that can help with the configuration management process. These include:

Top of page

Copyrights and Disclaimer

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

Top of page

5 of 23