In-Depth

Systems Engineering: A Simple Plan for SMS

Preparing an SMS 2.0 installation requires people, training, data-gathering, design, and testing. Here's an approach to guide you through the entire effort.

• By Ethan Wilansky
• 02/01/2000

Systems Management Server 2.0 is a powerful and scalable systems management tool. However, these characteristics don't necessarily justify making SMS part of your organization's network. Instead, deploying SMS is justifiable if you can determine that the systems management needs of the organization can be met by at least some of the features provided by SMS.

For example, if your network contains Unix and Apple Macintosh client computers and one of your goals is to provide help desk support to your clients, SMS 2.0 can't meet this need. If, however, your network of client computers runs Windows 3.x and Windows 32-bit operating systems and one of your goals is to efficiently distribute software from a central location, SMS can handle the job.

In this article, I walk you through the process of defining your systems management needs and developing your SMS implementation, presuming that SMS meets those needs. (To view a sample planning process sheet, click here.)

Step 1: The Assembly

Before digging into the organization’s systems management objectives, you need to assemble a small team of technologists. This group will be involved in varying degrees throughout the project. In a small organization, the group may contain just the IS director and network administrator. In a large organization, it could include network managers from multiple sites, an application design specialist, computer technicians, database administrators, and possibly a software developer. The key is to assemble a team that will help the person leading the systems management project from start to finish.

The next step is to list the systems management objectives of the organization, without regard to SMS features. Here’s a short list of common objectives:

• Provide centralized help desk support to clients.
• Continuously monitor computers and other network devices for critical warning messages or failures.
• Maintain an accurate database of network assets.
• Distribute software and operating systems efficiently.
• Dynamically map network devices.
• Maintain a high level of fault tolerance throughout the network.
• Address Y2K, Euro, and other software and hardware compliance issues.

These objectives can be prioritized by completion date such as, “by the end of the fiscal year” or “before January 1, 2001.” Dating the successful completion of each objective will help you prioritize your systems management needs. Later in the planning process you’ll use this information to help estimate how long it will take to complete your SMS 2.0 rollout.

Step 2: Understand the Product

Believe it or not, determining systems management needs with the team before you fully understand SMS 2.0 is the best way to create a complete list. Once you have a handle on SMS 2.0, you run the risk of creating a list of objectives limited to the features provided by SMS. Objectivity is the key to distilling a complete and accurate list.

Education is the next important step in the planning process. If you don’t know SMS, you can’t be sure it will meet your needs. Some organizations may choose to use a consultant or consulting team for the entire planning process. Even with this approach, one or more people within the organization should be identified for training. This staff member will be referred to as the SMS administrator.

The purpose of this training is to help determine whether SMS 2.0 can meet some or all of the organization’s systems management objectives. Even if consultants are building the SMS plan, training the SMS administrator is important so that the plan can be validated internally. Additionally, the SMS administrator will work with the planning team throughout the planning process and ultimately manage SMS in production.

There are a number of training methods, training vendors, and a variety of courses already available for SMS 2.0 (see “SMS Training Tips.”)

Step 3: Acquiring Information

In a perfect world, all of the network information required to build an SMS plan is already documented in an up-to-date, well-organized, and complete data repository. In the real world, of course, documentation is often inconsistent and spread around various divisions of the IS department. Therefore, the next step in the planning process is to consolidate network information relevant to SMS.

The SMS administrator should work with the IS team to pull together disparate information in order to build an accurate picture of the company and its network environment. The SMS Administrator’s Guide and the Microsoft SMS 2.0 Training Kit go into detail about the information to be collected. To understand how SMS will be managed, address the following areas.

Organizational Structure

One or many people can manage SMS 2.0. It interacts with users, their computers, and other network devices. Thus, it’s important to answer the following questions:

• Who will serve as the “super administrator” of SMS?
• What is the current IS staff model?
• Will SMS be installed and configured by a single individual or multiple people?
• Who’s responsible for maintaining connections between sites?
• If real-time remote support is required, is there a help desk staff that will support users with SMS remote tools?
• If electronic software distribution will be used, who’s responsible for configuring installation scripts? Who’s responsible for creating software packages? Will software distribution and program advertisement be managed from a single site or multiple sites?
• If asset management will be employed, who will create reports?
• If you operate remote sites, are there site administrators who will manage SMS locally?
• Do you support many mobile users?
• Will your help desk personnel participate in your deployment by being allowed to use Remote Tools?

By answering these questions, you’ll be able to build a staffing and training model in the next step of the job, creating a site design.

The Network

SMS is organized by site. A site typically is defined as a collection of computers interconnected by a fast, reliable network. Understanding the structure of the network is key to configuring SMS sites. The table included with this article shows you the information you’ll need to help you understand the network and ultimately create an efficacious plan for SMS 2.0. In an online version of this table, which is a Word form, I’ve included default values to show you how you might fill it out. For example, in the Details column of the Primary network device information cell, the type field is a drop-down list box containing values of Router, Bridge, and Brouter. Notice that most cells in the Components column contain two or more corresponding cells in the Details column. The Details column should be split into more cells as necessary.

In this phase of the job, you should also determine server capacity for all servers in the network. Getting performance data on all servers will help you identify a server or servers that can perform various site system roles for SMS. You may also determine that the servers are too busy with other tasks to perform SMS site system roles. If so, in the next step, you’ll recommend new servers to serve site system roles.

Installed Software and Software Configurations

While you’re acquiring information about the network, you’ll also probably gain a better understanding of the software currently running in the organization and how it’s configured. SMS is capable of collecting copious information on software located on client computers. Therefore, it’s not necessary to collect this information before deploying SMS.

You should, however, obtain or create a list of approved software running on client computers and servers. Review this list carefully to identify potential conflicts with SMS. For example, if you’re already using remote support software on the client computer, the remote control component of that software may conflict with SMS Remote Tools. If SMS detects a remote control program that runs on the client computer, the SMS Remote Tools Client Agent may not install. After you’ve compiled a list of software, research potential conflicts. The Readme file accompanying SMS 2.0 details some. Microsoft’s Knowledge Base at www.microsoft.com/technet/support/searchkb.htm, the SMS Technology Center at www.microsoft.com/technet/sms/default.htm, and Microsoft’s SMS Web site at www.microsoft.com/smsmgmt are good places to continue your research.

During this part of the planning, you can identify synergies between SMS and running software as well. For example, if computers on the network run the Desktop Management Interface (DMI), additional inventory information may be collected by SMS. Check with the company that developed the DMI implementation to determine if DMI information is written to SMS .MIF files or directly to the WBEM repository. Many software programs include Package Definition Files (.PDFs and .SMSs) that can be imported into SMS to facilitate software distribution. If SNMP is installed on Windows NT/2000 client computers, SMS can translate OS events to be forwarded to a Network Management Station (NMS). Understanding what software is running in the organization will help you determine how to fully leverage the capabilities of SMS.

Software configurations can be important too. For example, you should obtain information on whether users run logon scripts when they log on to the network. If so, review the logon scripts. In the next step you’ll decide how and if SMS will write to the logon scripts. You should also determine the configuration of client redirectors running on the client computers.

In the network information-gathering phase, you determined the protocols supported on the network. In this phase, you determine which client redirector is primary, (if more than one is running) and exactly how it’s configured. You should also collect client redirector version information. For example, some versions of the IntranetWare client for Windows NT support both NetWare login scripts and NT logon scripts; other versions don’t. These details can be important to determining how and where logon scripts will be processed if SMS logon discovery and installation methods are implemented.

Security Model

Security extends to both hardware and software. However, to build an SMS design, the software security strategy and security configuration of the network is key. For example, if users on NT/2000 computers running NTFS aren’t allowed to install software, this can affect the way in which you configure SMS software distribution. Chapter 4, “Creating Your SMS Security Strategy,” in the SMS Administrator’s Guide explores basic security issues. Use the information in that chapter, particularly “Identifying Security Needs” and “Deciding on a Security Model,” to determine how your security model fits your SMS plan. SMS site system security is achieved using NTLM, the WBEM interface, and SQL Server authentication. Chapter 4 of the SMS Administrator’s Guide will also be helpful in resolving your site system security design.

Step 4: Creating a Design for SMS

The goal of this step is to build a production implementation of SMS that meets performance requirements, scales to future needs, provides access to SMS features to the appropriate staff, is fault-tolerant, and is recoverable after a data disaster.

From the needs assessment and your understanding of SMS, you’ll know which of your systems management requirements can be fulfilled by SMS features. Organizational structure information allows you to build your SMS staffing model and determine how many SMS site servers should be created. Using this information and the data gathered about the network, you can decide where the site servers and other site systems should be placed in the SMS hierarchy. Details and design issues are covered in depth in both the SMS Administrator’s Guide and in the Microsoft Systems Management Server 2.0 Resource Guide by MS Press. MS Press bundles this resource guide in the BackOffice 4.5 Resource Kit. [Read Cathy Moya’s in-depth review of it in the September 1999 issue.—Ed.] Figure 1 shows the relationship between the planning steps, the sub-components of a site design, and how the design sub-components interrelate.

Figure 1. Planning an SMS design.

Create Configuration Guidelines

Configuration guidelines contain the SMS features to be implemented, a disaster recovery plan, backup procedures, other factors that affect the design, and SMS hardware requirements data. The guidelines should be detailed enough that an organization can follow them systematically to arrive at a working implementation of SMS.

Build a Disaster Recovery Plan

Disaster recovery is separated from a backup and restore procedure because it includes more than just instructions on recovering SMS site systems. The DR plan provides specific instructions in the event of a data disaster. This plan draws from the configuration guidelines so that if a site system is destroyed by fire, for example, the DR plan can be consulted to determine the appropriate hardware configuration of the destroyed site system. To recover SMS data, one solution is to run the SMS backup and restore procedure. However, the DR plan provides other solutions, such as reinstallation and data rebuild through SMS discovery and client agent functions. Building a disaster recovery plan is a subject unto itself. Use this information to simply understand the purpose of a DR plan.

Determine an Appropriate SMS Backup and Restore Procedure

The procedures outlined here become a section of your DR plan, which is why the backup procedure overlaps the DR plan domain in Figure 1. SMS includes automated backup procedures, which can be enabled through the SMS administrator console. The key components to back up are:

• Site databases
• Software metering databases
• SMS registry keys on the site servers:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS
HKEY_LOCAL_MACHINE\SOFTWARE\NAL

• Site server SMS root directory (application directory)
• Package stores used for software distribution

While you can back up the individual components, it’s simpler to perform regularly scheduled backups of the site servers, software metering databases, and site server databases. You needn’t back up other SMS site systems, although regular backups aid in an efficient recovery.

The SMS Administrator’s Guide suggests that if you’re using a fault-tolerant disk configuration, it’s not necessary to back up the SMS root directory. While this is true, a comprehensive backup routine increases your level of fault tolerance. If the server is physically damaged, a RAID array is of little value. A number of backup procedures are included in SMS for key components of SMS. Layering these procedures on top of an enterprise backup routine is prudent. If the site system fails, the discrete backup files created by SMS and backed up by an enterprise backup system can be used to restore a failed site server and site server database.

Consider Other Factors

Other factors shape the SMS design. For example, NetWare servers acting as site systems will affect the logon discovery and installation methods used. (For information on discovery and installation methods, see my article, “Systems Management Server 2.0 Client Features,” in the May 1999 issue of Windows NT Magazine.) Supporting languages in an SMS hierarchy other than English may require purchasing non-English editions of SMS. Client language support varies by client operating system. For more information on this subject, review “Multi-language Site Hierarchies” in the SMS Administrator’s Guide and similar coverage in the BackOffice 4.5 Resource Kit. Another factor is support of SMS 1.2 sites. If you need to support SMS 1.2 and you wish to make it a part of the SMS 2.0 hierarchy, this must also figure into your design.

SMS Feature Set

The SMS features you’ll deploy are based on the systems management objectives of the organization and your understanding of what needs SMS can meet. If you determine that your sole requirement is asset management, then only SMS hardware and software inventory, and possibly Crystal Info (for inventory reports) is enabled in SMS 2.0. This feature set will require limited support staff and minimal hardware. Staffing and hardware resource requirements increase in proportion to the number of SMS features implemented. Once the feature set is determined, systematic procedures should be added to the Configuration Guidelines.

Identify Hardware Resource Requirements

The computers needed to serve site system roles are determined by the SMS feature set to be deployed, connection speed between networks that will be managed by SMS, the staffing model, performance requirements, fault tolerance requirements, and, of course, the money available to implement SMS. Other factors, like company hardware standards, should be considered in planning hardware resources for SMS. The scalability tools included in the SMS 2.0 Resource Guide will help you size computer and network resources to meet the hardware requirements of an SMS implementation.

Build a Staffing Model

Two groups are responsible for a successful deployment of SMS: the planning and deployment team and the post-deployment administration team. Many factors affect the size and structure of these groups. An effective design has the SMS administrator involved during the planning process and after deployment. In medium to large designs, a project manager oversees the design process to make sure that schedules are being met. An SMS expert builds the design; in smaller sites this might have to be the same person. Additionally, the project manager makes IS staff members and department staff available to the designer so that important questions about the network and systems management needs can be answered. One or two members of each department in the organization are necessary to champion the project. These individuals will be targeted during the pilot deployment in the next step.

The composition of the post-deployment administration team is dependent on the SMS feature set implemented. The team is led by the SMS administrator. In small deployments, the SMS administrator may be the sole member of the team and may have other network responsibilities. In larger implementations, the following support staff may be necessary:

• Help desk support staff to operate SMS remote tools, generate asset management reports, and track software metering data.
• An installation scripting expert to automate installation procedures for software distribution.
• A network administrator to work with SMS Network Monitor, Health Monitor, and SNMP Event to Trap Translation.
• A site configuration manager to manage configuration requests from other members of the team.
• Remote site administrators to manage local installations of SMS.
• A database administrator to manage the SMS databases.
• A software developer to extend the functions of SMS.

Once you’ve determined staffing requirements, time commitments and responsibilities should be documented in the SMS plan.

Diagram a Proposed Structure

A graphic representation of a structure for SMS goes a long way to identifying any weaknesses in the design. The diagram should show SMS site boundaries, site system types, the SMS hierarchy, the speed of connections between sites, the number of client computers at each site, the location of domain controllers, domain names, and NetWare servers (if NetWare site systems will be created). Build the design in a program that allows for the rapid creation and modification of the proposed structure (Visio is my preference).

Begin Project Time Line

The project timeline, typically a Gantt chart, includes all tasks, task dependencies, milestones, and resource requirements that are part of the design process. You may want to organize the tasks by the steps outlined in this article. Include project start and end dates for each task. Project charting programs such as Microsoft Project will walk you through the project plan creation process. Typically, the project manager or SMS designer creates the project timeline. Regardless of who creates it, the project manager uses this timeline to track the progress of the design process and to help calculate the cost of implementation.

Step 5: Lab Testing and Pilot Deployment

Steps 4 and 5 are rarely sequential. Instead, it’s common to return to Step 4 from Step 5, as shown in Figure 1. This iterative process is important for design validation. Anywhere the design doesn’t work as expected is documented through modification to the design documents. For example, you may configure a laptop in the lab to connect to a test site (site1). You then connect the laptop to another network segment in the lab containing another site (site2). You notice that when the laptop connects to site 2, it’s moved to site 2. If you want more control over this behavior, you decide to implement Traveling Mode on your laptop computers. Once this decision is made, you document this design change in the Configuration Guidelines (Step 4).

The more closely the lab environment matches your production network, the fewer surprises you can expect during the pilot and production deployment. The lab should contain the same model of computers that will act as site systems and clients on your network. If your network isn’t standardized to a few client computer models, select a subset of computers that represent the majority of your clients. During pilot deployment, target the computers of the department representatives identified in Step 4; if necessary, target additional computers in the pilot deployment so that your pilot represents the majority of client computers on the network.

Step 6: Production Deployment and Support

You’re now ready to begin a deployment of SMS. It’s best to deploy SMS incrementally, one department at a time or one network at a time. You can make the deployment more granular by enabling one or only a few features at a time. For example, enable discovery methods, verify that discovery is working properly, and then enable installation methods. Once client access points and other site systems are configured, enable the Hardware Inventory Client Agent and the Software Inventory Client Agent. Verify that inventory is collected, then move on to other SMS features.

There are many different approaches to production deployment. During and after deployment, it’s critical that SMS is fully supported by the IS staff identified in the design phase. If not, users will inevitably complain about interactions between SMS and their computers. A well-planned implementation of SMS will fall flat on its face if users are inconvenienced by it.

The key to a successful implementation of SMS is a solid plan that identifies the systems management needs of the organization. Determining whether SMS fits into the plan is based on a thorough understanding of SMS, the organization that will use it, the network that will run it, the software in the network, and the current security model. The design of SMS should include detailed configuration guidelines, a disaster recovery plan, and a staffing model. The configuration guidelines are based on the SMS feature set to be implemented, site system hardware resource requirements, backup and restore procedures, and any other factors that may affect the design. The design should also include a diagram of the proposed structure for SMS, and a project time line.

The design is verified through lab testing and a pilot deployment. Testing and limited deployment will identify parts of the design that require revision or augmentation. Once testing and deployment has concluded, SMS moves into production. With proper support, the deployment of SMS can meet and even exceed your systems management expectations.