[Previous] [Next]

Lesson 1: Overview of Planning for SMS

As is the case with most system-wide application installations, a planning protocol should be followed before SMS is implemented. Planning an SMS system is most effective when a step-by-step approach is taken to completing the design. Understanding SMS, performing a needs analysis, and documenting the network must occur before an effective design can be created. After the design phase, resource planning, staff education, and design testing occur.

After this lesson, you will be able to Estimated Completion Time: 20 minutes

Click to view at full size

Figure 9-1. An overview of planning and deployment of SMS.

The Planning Process

The first stage in the planning process is to become familiar with SMS. You become familiar with this product by reading the documentation, particularly the SMS Administrator's Guide, and studying these training materials. When you have a working knowledge of both SMS and the organization that will use it, you then perform a needs analysis. The needs analysis determines how SMS helps an organization to meet its systems management objectives. The needs analysis represents the first documentation created in the planning process.

When it is determined that SMS can help the organization, the next stage is to assess the current environment. Assessment requires that the network be well documented.

Documenting the Network

A well-designed and managed network will include documentation on the following components:

Net available bandwidth is a key characteristic of any network link and should be carefully documented to insure proper utilization of SMS or any networked application. A link between sites may be listed at T1 (1.544MB) bandwidth, but after subtracting the normal utilization on the link, you may find that only 56KB is available for use by SMS.
If you are unfamiliar with trust relationships and how they affect domain models in Windows NT/2000 Server, review the Windows NT/2000 Server documentation and training materials.

If the information specified in the preceding bulleted list is not available, it should be created and included with the needs analysis before moving to the site design phase. As the planning process continues, the needs analysis can evolve into an SMS documentation repository for all phases up to and including the deployment of SMS.

The Design Phase

During the design phase, representatives from all departments in the organization should be included in design discussions. Departmental representatives provide valuable insight when it comes to implementing the design. In addition, including a departmental representative who serves as a "champion" of the implementation increases the likelihood of its acceptance by the entire organization. Success of this system depends on an organization's acceptance of its purpose and utility. It is important to note, however, that only one or two people should be responsible for the final site design and deployment. The SMS deployment and systems management suffers if too many people manage the hierarchy.

Site Boundaries

In this first step, decide which servers and client computers will make up a site. A site is categorized by resource boundaries based on network segments (IP subnets or IPX networks). A site should never span a low-speed or unreliable network connection. Will the entire network be a single site? Will the sites be divided based on geographic location? Will all servers and computer resources be part of a site? What site system roles will various computers play in the site design?

Using the data gathered in the assessment of the current environment, list the computers that could be made available to SMS as site systems. A site system is a Windows NT/2000 Server computer, a Windows NT/2000 share, a NetWare NDS volume, or a NetWare bindery volume that plays a role in the site. There are nine different site system roles in an SMS site. Each one has different requirements with respect to the microprocessor, RAM, hard disk space and operating system. When it is time to plan resources for SMS, the information given in the next paragraphs will help you determine if more equipment is needed. In addition, review "Requirements for Site Servers and Other Site Systems" in Appendix A of the SMS Administrator's Guide.

You should also check the Microsoft BackOffice web site and Microsoft's web site dedicated to SMS, for updated deployment, implementation, and planning requirements. You can access Microsoft's SMS web site from the Web Help button on the SMS Administrator's Guide or the Systems Management Server Administrator Help online documentation toolbar.

Site Hierarchy

Once the site boundaries are defined, determine how the sites will be connected to each other. Which one will be the central site and where will it be physically located? What child sites will be added and where will they be physically located? Will the sites mirror the physical layout of the network or will the current domain structure or IS (Information Systems) organizational structure be used as a model for designing the site hierarchy?

Your site should not mirror the organization's departmental structure. However, from an administrative perspective, it may be useful to define your site by the organizational structure of the IS department. For example, if local site administrators manage a site that is remote to the corporate network, it is useful to configure a child site for the remote network.

Site Types

Determine whether a site should be primary or secondary. Are there local administrative personnel? How many client computers are in this site? Are there hardware restrictions that dictate the use of a secondary site server?

Should site systems other than a site server be configured on the remote network? Not installing a site server on a remote network requires fewer hardware resources, but using this structure should only be considered if there is a fast, reliable connection between the local site and the remote site. Site servers organize the site hierarchy into manageable subsets. Also, site servers on remote networks use the bandwidth of the network more efficiently than do remote sites not running a local site server.

Deployment Strategy

Decide how to deploy SMS to the organization. How will resources be discovered? What client installation methods will be used? What client agents will be installed? Decisions surrounding the deployment strategy include defining site boundaries, selecting installation methods, and enabling client agents. See Chapters 2 through 7 for information on installing SMS and using the various client agents contained in the product.

Resource Planning

Using the needs analysis, you can assess the current environment and determine the SMS design and resource requirements.

The computer resources running the following software are considered in this phase:

The following issues are also considered in this phase:

Resource planning is covered in more detail later in this chapter. Refer also to Chapter 2, Lesson 2 of this guide and Appendix A of the SMS Administrator's Guide for more information on hardware and software requirements for site systems and client computers.

Educating the Organization

The next critical phase of the planning process is education. Administrators and support staff who will use SMS to administer the network must be properly educated in the use of Windows NT/2000 Server, SQL Server, SMS, and the other server and client computer operating systems that will be supported by SMS.

Users at SMS client computers must be informed that SMS client agents will be running on their computer. In particular, the remote tools, software metering, and software distribution client agents require some user interaction. SMS 2.0 includes a document, "Microsoft Systems Management Server Version 2.0 Sample Client Preparation Document," which introduces SMS to client computer users. This document (CLIENT.WRI), located on the SMS 2.0 installation CD-ROM in the \SUPPORT\RESKIT directory, can be copied and customized for the organization. The custom document is then sent to users via email or another distribution mechanism before the client agents are installed.

Education of the entire organization should occur early in the planning process. Remote site support is also critical in larger networks. Local administrators should train administrators at remote sites to deal with SMS issues. The plan should document how key issues are reported to the central team and should outline backup and recovery measures for all sites.

The Testing Phase

Once the preliminary site design phase and the education phase are complete, the project team begins an organized process of testing and refining the design until it is ready for organization-wide deployment. The following paragraphs describe the tasks in the testing phase.

Set Up the Test Lab

Set up a lab with site systems and client computers configured to reflect the enterprise environment. Duplicate the network environment as closely as possible. This includes creating protocols, client computer operating systems, and network operating systems. Be sure to set up a WAN environment so that WAN issues are raised in testing. Make sure that the test client computers have the same hardware and software that production client computers have. This lab should not be dismantled after SMS deployment, since it will be used continuously for SMS functions such as package installation tests and new hardware compatibility tests.

Perform the Lab Testing

Install SMS in the lab. Test all features, scripts, and any other procedures. Focus on features that will get the most use initially after deployment. Test any performance requirements, such as remote control responsiveness or querying the database.

Conduct the Pilot Project

A pilot project should have its own set of specific objectives, along with a set start and end date. Objectives include verification of staffing needs and verification of appropriate server/network capacity. Include phases as if this were a full production deployment: site design, testing, scheduling, verification of success, troubleshooting, and evaluation.

Choose a department or a group of users to test a pilot deployment. It is helpful if this set of users is comfortable with technology so they can work with the deployment team on problems. The departmental representatives used during the design phase are good candidates for the pilot project. Prepare the users in this group prior to deployment. Revise the plan as necessary, based on feedback from this pilot. It may be necessary to return to the lab to test changes and revise the site design.

It is imperative to establish clear criteria for moving from a pilot project to production. These criteria should include objectives, an assessment of risks, a plan to mitigate those risks, a clear date for a decision, and a plan for restructuring the pilot if the decision is a no-go.