On This Page
Document PurposeThis guide provides detailed information about the system administration service management function (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 Introduction to Service Management Functions guide. This overview guide 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/solutions/msm/. Executive SummaryWith the ever-increasing requirements of customers and the globalization of companies, the delivery of world-class services is becoming the difference between the success and failure of an organization. IT environments, although carefully planned originally, evolve with disparate and distributed architectures to grow in complexity. The dynamic nature of organizational structures, advances in IT technology, the continuous upgrading of hardware and software components, and the increasing demand for service quality potentially make the administration of an organization's IT infrastructure very expensive and time consuming. The system administration function defines and delivers the processes and procedures required to administrate a computing environment on a day-to-day basis. Consequently, the system administration function resides in the operating quadrant of the MOF. Process and ActivitiesSystem Administration OverviewThe system administration function, graphically illustrated in Figure 1, performs Security Administration, Service Monitoring and Control, Job Scheduling, Network Administration, Directory Services Administration, Print and Output Administration, and Storage Management. The way in which you design, develop and implement this function will be determined by the size and architecture of your organization. Large organizations will have clearly defined models while smaller organizations will be likely to consolidate functions in order to maintain the health and operational capabilities of the systems. The system administration function is responsible for providing day-to-day administrative services in support of the production-computing environment. This entails managing and providing operational support for various elements within the environment, such as network accounts (users, groups, distribution lists, and so on) and network resources (servers, printers, storage devices, and so on). This function may also lend assistance to, or work in concert with, other service management functions by providing basic monitoring services. For instance, system administration may provide first level performance and capacity monitoring for the service monitoring and control function. System Administration Models As noted, the fundamental objective of this paper is to provide guidance on how to implement the system administration function within your organization. To offer prescriptive guidance on how to implement this function, we need to discuss administration from the standpoint of a specific "model." Modeling system administration takes into consideration an organization's computing architecture—whether it is centralized, distributed, or a hybrid of the two. Your administrative model is most likely to follow the design of your architecture, although there are exceptions. The exceptions are generally associated with specific administrative functions. For example, in a broadly distributed architecture where print and output management is clearly a distributed and delegated administrative function, directory services administration is nonetheless likely to remain a centralized function. This is just one example—there can be numerous others, and because each organization employs widely varying computing architectures, the design of your administrative model will be crafted to accommodate the specific requirements of your individual company. Our goal here is to provide intelligent and sensible guidance on how you can begin to design and implement your own system administration operating model. Goals and ObjectivesThe objective of the System Administration Function is to administer a computing environment on a day-to-day basis. This entails managing and providing operational support for various elements within the production environment. ScopeThe system administration function is responsible for providing administrative services in support of computing environments that contain both centralized and distributed hardware. The scope of system administration is based upon the model shown in Figure 1. Systems Administrative Function may also provide assistance with the functional administration of other SMFs which they are not direct responsible for implementing and managing. This assistance may include:
Key DefinitionsCentralized hardware. All computing resources being managed are located centrally in the corporate data center (sometimes called the computing center or corporate technology center). Centralized administration. The administration resources required to perform the tasks and procedures are centrally located. Centralized administration of centralized hardware. All or most of the operations and support functions centrally located in a single site. Centralized/remote administration of distributed hardware. Although systems may be distributed to remote locations, all major administrative control remains at the central location. Centralized/delegated administration of distributed hardware. The primary administrative function and administrative workforce reside at the corporate (central) data center—all administrative direction and control originate from this function. Distributed administration of distributed hardware. Relies on full support resources located in the remote sites or branch offices to perform the support function of systems distributed to those sites. System Administration ModelsDetermining how best to craft the system administration function within your company is mainly contingent upon the size, capacities, and capabilities of your architecture and IT staff. Large organizations will obviously deploy a more sophisticated administrative model, while smaller organizations will be likely to consolidate functions based upon the amount of work that is required to maintain administrative health. The five basic models we discuss in this document are illustrated in figure 2. These five models essentially take into consideration an organization's ability to centralize computing resources and the associated administrative functions, as well as its need to distribute some or all of the computing and administrative resources to sites apart from a central data center. Centralized Administration of Centralized HardwareThe first model, centralized administration, is illustrated in Figure 3. As shown in Figure 3, all or most of the operations and support functions are centrally located in a single site, or sites. Multiple sites are discussed later. With the maturation of local area, wide area, distributed, and client server computing and their supporting networks, more and more organizations have made great strides toward centralizing support for installed resources, applications, and solutions. Bandwidth to remote sites and branch offices is more widely available and affordable. Basic technologies that support branch office computing (transmission protocols, remote access tools, headless servers, and so on) have improved to the point where each branch office no longer needs its own separate support staff. Companies are thus increasingly able to centralize the fundamental support functions required to maintain the availability, reliability, day-to-day support, and management of systems that are distributed to the remote sites or branch offices. Centralized administration typically assumes that all or most of the computing systems and resources being managed (administered) are centrally located. While this is increasingly true, there continues to be cases where specific solutions (that is, custom applications, specialized databases, and so on.) are not centralized in the corporate data center, but instead are distributed to the remote branch or site. This distribution of some applications and databases does not prevent taking a centralized approach to the administrative model. The centralized/remote administration model, described later, accommodates both centralized administration and the distribution of some solutions. Figure 3 shows a model where all computing resources being managed are located centrally in the corporate data center (sometimes also called the computing center or corporate technology center). The administration resources required to perform the tasks and procedures are centrally located at the data center with the computing systems. This model offers the advantage of greater control over all resources, achieved through physically locating everything (systems and people) at a common site. It also offers reduced costs. Compared to the distributed, remote and hybrid models, there is a reduction in operating costs because the model does not require maintaining remote data centers to support distributed systems and administrative resources. The centralized administration model assumes that you are managing mission-critical, high-availability systems that require a full data center infrastructure, including highly available power, environmental conditioning, fault-tolerance in all data center components, and all the security systems appropriate to the deployment. The disadvantage of the centralized administration model is that it requires maintaining high-speed bandwidth to all remote sites, along with the appropriate levels of redundancy and fault tolerance in the network links. If a remote location supports a large number of users, the bandwidth requirements necessary to maintain the performance characteristics required to support your service level agreements can be substantial. One way to resolve the issue of maintaining expensive wide area network (WAN) links to a remote site with a large number of users is to distribute the systems to those sites while continuing to perform management, operation, and administration functions from the central location. The resulting model, called "centralized remote administration", is discussed in the next section. Centralized/Remote Administration of Distributed HardwareThe centralized/remote administration model, shown in Figure 4, achieves most of the benefits of the completely centralized model. Most administration continues to be performed at the central location (i.e., central data center) thereby retaining the greatest control and consolidation of resources necessary to execute the administrative function. Some control and resource consolidation is given up, however, due to the requirement of maintaining a remote data center environment with at least a minimal localized administrative presence. Remedial system maintenance requirements on the distributed system may include system updates that require a reboot of the computer, as well as tape-backup and storage duties. There may be additional local-site administrative requirements, depending on the application or specific system being managed—you'll have to decide what specific responsibilities are necessary based upon your technology application. As shown in Figure 4, the centralized/remote administration model describes systems that are distributed to remote locations with all major administrative control remaining at the central location. As stated above, there now needs to be a data center presence in the remote or regional location to house the servers or storage units. This implies that you now incur the cost of the data center infrastructure, which includes the physical plant, floor space, power, wiring, HV/AC, and security components. If the technology application evolves to the point where this model no longer remains viable (i.e., no longer meets the service level agreements) or is no longer cost effective, you may need to move to a distributed administrative model. In a distributed administrative model, the computing resources as well as the people resources are physically located at the remote location. This model is described in the next section. Centralized/Delegated Administration of Distributed HardwareThe Centralized/delegated administration model is shown in Figure 5. This model attempts to embrace the best of the centralized and remote administration models with all of their inherent features and benefits, yet also realizes some of the benefits of the distributed administration model. These benefits are achieved by pushing a relatively small and specialized sub-set of administrative tasks and responsibilities to the local branch offices and remote sites. As with the centralized model, the primary administrative function and administrative workforce reside at the corporate (central) data center—all administrative direction and control originate from this location. The centralized resources continue to manage the centralized, data center-based network servers and services, and also continue to remotely administer services across the network where possible, reasonable, and applicable. Certain circumstances dictate the need to distribute specific services, servers, and resources; in these cases it may also be prudent and/or more efficient to allow some of the administrative tasks to be performed at the regional or remote locations. This is done by delegating, very specific authority to the remote location resources. "Very specific authority" refers to a small subset of administrative rights and access that allow the remote administrators to perform specific, discrete tasks. Figure 5 below shows a possible application of the centralized/ remote administration model. Distributed Administration of Distributed HardwareUnlike the other models, distributed administration, shown in Figure 6, relies on full support resources located in remote sites or branch offices. Resources at remotely-located sites perform the fundamental (although critical) support functions necessary to maintain the health, availability, and reliability of systems distributed to those sites. There may continue to be business drivers for maintaining systems that are distributed to remote locations. Some of these drivers may be related to performance, scalability, a specific type of application, or the cost or availability of network bandwidth that would support a centralized solution. Figure 6 shows an example of a distributed administration model for a company with remote sites that are heavily populated with computer users. As shown in Figure 6, computing and people resources are completely distributed to the remote offices and regional sites. As a result, the company may realize much better local site performance for specific technology applications. Specific Application Driving the Distributed Model DecisionLet's look at an example of an application that drives the decision to distribute the environment (and subsequent administration thereof). Electronic messaging is one of the most critical applications that companies deploy to improve company-wide productivity, communications (both internal and external), and computing efficiency for their businesses. Typically, early mainframe-based messaging solutions were completely centralized—both the hardware and the administrative support functions were centrally located in the company's data center. When personal computers and, eventually, server-based, local area networks (LANs) of personal computers became widely embraced and deployed, many companies decided to move the messaging applications from the mainframe to the server-based networks. This decision hinged primarily upon three factors: the unique richness available in the server-based products and solutions, the cost benefits realized by downsizing applications from the more expensive mainframes to the less expensive servers, and the power that users realized by having a full-featured, localized, messaging client on their personal computer. For the most part, these early server-based messaging solutions were, by necessity, distributed. Known by the type of message transport mechanisms they employed, these solutions were described as store-and forward. They required that the post office (hub server where the electronic form of the message database and message transport mechanisms executed) be close to the users whose accounts it hosted. In other words, the post office was connected to the users through a LAN. Consequently, the service that could be provided on these high speed LANS, was defined as "LAN-speed," as opposed to "WAN-speed," which indicates that the service is being made available from a distant location and travels across the companys wide-area network links. The benefits of this distributed design were better performance and scalability (defined as the number of users that could be connected to, or hosted by, a single post office). Users enjoyed an additional benefit as well; they were isolated from any interruption in the WAN link connected to the rest of the messaging network. In the event of a WAN link failure, users could continue to use messaging services and communicate with other users at the local site until the link was restored. On the downside (and there's always a tradeoff . . .), the cost of deployment for the distributed environment was greater. As mentioned previously, distributed models require remote data centers along with the human resources to manage them. If an application (like corporate messaging) was considered mission critical and had specific service level agreements, as well as high availability and fault tolerance requirements, the cost of implementing the appropriate data center infrastructure could be substantial. In addition to the data center costs, the human resource costs could also be significant. In a distributed environment, it's crucial that the remote data center be staffed with operational and administrative resources that are highly trained and prepared for the duties associated with running this technology center. Given the shortcomings of this model, there is a way to help offset (but not totally avoid) the overall costs associated with running a distributed environment. The strong, new security-integrated directory technologies make it possible to delegate administrative tasks and responsibilities to staff located at the remote sites and locations. This means you may not have to co-locate high-level administrative talent to the sites to perform the operational tasks. Your human resources must still be trained and capable, but to a much lesser extent than if you are running the remote technology center as an autonomous data center site. In the discussion of store-and-forward messaging applications above, it should be noted that most of these distributed messaging solutions had specific components that continued to be managed centrally (that is, the rolled-up messaging user directory, the mail-routing tables, the master or "bridgehead" post office servers, and the central message routing servers). Specific tasks related to the operation and maintenance of the distributed post offices was typically delegated to administrators located at the remote sites. Of course, the data center itself in the distributed model must still conform to the standards set to meet your organization's mission critical requirements. The difference is that there is a cost savings associated with being able to delegate specific administrative tasks from the central data center. This approach is discussed in further detail in the next section. Distributed Administration of Centralized Data CentersThe fifth system administration possibility, referred to here as the "follow-the-sun" model, could also be called the "distributed administration-centralized data center" (more than one) model. "Following the sun" in this context means providing support globally 7 days a week, 24 hours a day by transferring the responsibility for this support to different regions around the world as some offices close for the day and others open. This model is somewhat unique, and not as widely implemented as the four basic models previously described. It should be noted, however, that companies have tried, or are currently trying, to get this model to work in their organizations. Figure 7 illustrates the transfer of support responsibility in the "follow-the-sun" time model. As the diagram shows, support (administrative and operational) is transferred to the data center operating during the primary daylight shift. For this example, we show an organization with complete data centers located in North America, Europe, and Asia. Following the Sun with Your Administrative Support OrganizationOrganizations that are globally positioned (typically very large organizations) with complete data centers located both domestically and internationally (that is, having data centers in North America, Europe and Asia as shown in Figure 7), can leverage the capabilities of these sophisticated resources to service users and sites located in other parts of the world during off-hours. With more and more organizations embracing global virtual workgroups, and with more businesses operating 24 hours per day, IT support organizations must provide the same high quality, responsive, proactive, and efficient support during off hours as they do during the prime daylight hours. The question is, do these round-the-clock organizations operate their local data center's support organizations at full capacity during off hours, or do they attempt to leverage the support center thats currently open for daytime business? Considering the cost of maintaining a fully operational data center that includes all facilities, computing services, helpdesk and support services, operational and administrative personnel, and troubleshooting and escalation resources, it makes sense to transfer responsibility for the majority of the support functions to a data center that's operating during their normal daylight shift. It's clearly more cost-efficient to allow remote resources to perform remote support than to maintain the local data center in full production during off hours. While the advantages of this model of "distributed administration to a centralized data center" are clear, there are also big obstacles. A few of the reasons this model hasn't achieved more successful deployments are:
Adapting the Different Models to Fit Your BusinessRarely do organizations achieve a single administrative model; typically companies institute a combination of the models to meet or match their varied administrative requirements. While difficult, it is imperative that organizations carefully investigate and implement administrative models that reduce cost and optimize control (like the centralized model), while balancing and meeting the needs of the users and agreed-upon service level agreements (like the distributed model). This is indeed a balancing act, but ultimately you can use the following best practice guidelines to help determine the best design for your administrative organization:
Table 1 summarizes the tradeoffs of each system administration model. Table 1: Comparison Matrix of the Administrative Models
Roles and ResponsibilitiesPrincipal roles and their associated responsibilities for system administration have been defined according to industry best practice. Organizations might need to combine some roles, depending on organizational size, organizational structure, and the underlying service level agreements existing between the IT department and the business it serves. By necessity, this document distinguishes between large and small organizations when it discusses how the system administration function is implemented. With respect to the roles and responsibilities relevant to this function, there are specific roles that must be created and specific responsibilities that must be addressed regardless of the size of your organization. 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. The scope of these roles is summarized below identifying the specific responsibilities associated with each role. Operations ManagerThe operations manager is responsible for how administrative services will be provided and executed within the scope of the computing environment. This takes into account the size and complexity of the environment, as well as the number of users, number and types of specific applications deployed, and how computing resources, servers, and services are distributed throughout the network. The operations manager also considers the various service level agreements in place as instituted by the service level management function. All of these elements will influence how the system administration function is designed, and will dictate to a large extent how administrative support services are applied across the company. The operations manager belongs to the operations cluster within the MOF team model. The responsibilities of the operations manager are:
Relationship to Other ProcessesAs proactive system administration becomes a more critical and central function to the operation and administration of your computing environment, it's important to understand how providing this service affects other operational processes. The following sections describe how system administration affects and/or interacts with other operational processes. Security AdministrationSecurity administration includes the information required to plan, select, implement, manage, and review security controls. It also includes processes and procedures needed to respond to security events. Security Administration is one of the processes performed by the System Administration function. Service Monitoring and ControlService Monitoring and Control monitors services for compliance with service level agreements (SLAs). Service Monitoring and Control is one of the processes performed by the System Administration function. Job SchedulingThe goal of Job Scheduling is to formalize the process of job scheduling to:
Job Scheduling is one of the processes performed by the System Administration function. Network AdministrationThe goal of Network Administration is to provide a reliable, consistent, and scalable network infrastructure that meets or exceeds service levels and optimizes enterprise assets. Network Administration is one of the processes performed by the System Administration function. Directory Services AdministrationDirectory Services Administration deals with the enterprise directory, including:
Directory Services Administration is one of the processes performed by the System Administration function. Print and Output ManagementPrint and Output Management deals with all data that is printed or compiled into the reports distributed to various members of the organization and external parties. Print and Output Management is one of the processes performed by the System Administration function. Storage ManagementStorage Management deals with on-site and off-site data storage for the purposes of data protection, restoration, and historical archiving. Storage Management is one of the processes performed by the System Administration function. ContributorsMany of the practices that this document describes are based on years of IT implementation experience by Accenture, Avanade, Microsoft Consulting Services, Fox IT, Hewlett-Packard Company, Lucent Technologies/NetworkCare Professional Services, and Unisys Corporation. Microsoft gratefully acknowledges the generous assistance of these organizations in providing material for this document. Program Management TeamJeff Yuhas, Microsoft Corporation William Bagley, Microsoft Corporation Lead WriterStephen Barnard, Microsoft Corporation Contributing WriterVicky Howells, Fox IT EditorSybil Wood, Volt Technical Services 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. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred. © 2002 Microsoft Corporation. All rights reserved. The names of actual companies and products mentioned herein may be the trademarks of their respective owners | In This Article |