【正文】 agement can be used to successfully manage IT ponents within a small part of the anization, the benefits are only fully realized when it is used throughout. Service Management Function 11 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: ? Although a workstation is made up of a number of ponents, such as motherboard, processor, operating system, and software applications, an anization may wish to track and control change to the operating system and installed software applications only. ? An anization has offices in several countries/regions, with each country/region responsible for the management of local IT resources. It would be reasonable to assume that each country/region would want to use configuration management to track and control change to its own resources. Agree on Boundaries of Management Ideally, information about all ponents and services of interest to change management would be recorded in a single CMDB. In practice, however, anizational issues, such as a widespread geographic structure, delegated administration, and ownership of specific IT ponents, will dictate the contents of a particular CMDB. In the example just cited of a geographically dispersed anization, each country/region 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 plexity to a minimum. In most cases, the impact of a change to the local environment is restricted to the country/region in which the change is applied, so there is little need to maintain configuration data about IT ponents in other countries/regions. 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 ponents on a much larger scale. If a change request requires that the Microsoft Windows NT174。 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 municated appropriately. During the change and release processes, configuration management is responsible for updating the configuration management database (CMDB) to reflect all changes to configuration items (CIs). 2 Introduction This guide provides detailed information about the Configuration Management SMF for anizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of enterprise puting 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 panion, Microsoft Solutions Framework (MSF), is available in the MOF Service Management Function Overview 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 at What’s New? This Configuration Management SMF has been revised to bring it into pliance with MOF version . 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 ments about this SMF guide to . 3 Configuration Management Overview Configuration management is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other inanimate ponents of the information technology (IT) anization. This chapter discusses the goal and objectives of configuration management and defines the key terms used in its processes. Goal and Objectives The goal of configuration management is to ensure that only authorized ponents, referred to as configuration items (CIs), are used in the IT environment and that all changes to CIs are recorded and tracked throughout the ponent’s life cycle. To achieve this goal, the configuration management process includes the following objectives: ? To identify configuration items and their relationships and add them to the configuration management database (CMDB). ? To enable access to the CMDB and CIs by other SMFs. ? To update and change CIs following changes to IT ponents during the release management process. ? To establish a review process that ensures that the CMDB accurately reflects the production IT environment. 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 ponent that is under configuration management control. Each CI can be posed of other CIs. CIs may vary widely in plexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware ponent. Configuration item attributes. The information recorded in the CMDB for every configuration item identified, ranging from the item3