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.
Figure 9-1. An overview of planning and deployment of SMS.
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.
A well-designed and managed network will include documentation on the following components:
This includes but is not limited to information on cabling, routers, line speeds, protocols, and the numbers of nodes connecting client computers and servers.
In particular, be sure to document details about network segmentation, such as the speed and effective throughput of the links. Include information about how and where the segments are linked, for example, gateways connected to mainframes; switches used as a backbone for the network; routers used to link remote sites; and so on.
Note the traffic patterns on each segment of the network. For example, traffic may be high during the day and low after 5:00 p.m. This information can be used to determine the best time to utilize the network with bandwidth-intensive SMS operations.
TIP
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.
NOTE
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.
Make sure to note shared (multiple-user) computer resources that will be client computers in an SMS site. Software distribution settings must be adjusted to accommodate shared client computers that will receive packages and programs through advertisements.
Mobile client computers such as laptops that dial in to the network require special attention if SMS client agents will run on them. While mobile users can benefit from SMS, management for these client computers differs from that for non-mobile client computers. For example, for mobile users that connect to multiple networks within an SMS hierarchy, Traveling Mode should be configured on the client computer.
Document information about business-critical software, standard computer software configurations, and current installation methods. Make sure to include any known compatibility issues. In particular, consider whether there are any integration issues with SMS. Further, knowing the name and version of approved software allows you to configure software metering to deny the operation of unapproved software.
Logon scripts for Microsoft Windows NT/2000 and NetWare 3.x and 4.x Servers.
Include the group names, groups members, purposes of the groups, and network rights assigned to the groups. Plan changes to the current environment.
This will help to create an SMS design that accommodates the organization's growth.
Document policies concerning user accounts, passwords, user rights, and auditing.
Document languages used on the computer resources in the network. Special attention should be given to accommodate multi-language support in building an SMS design.
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.
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.
TIP
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?
NOTE
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.
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:
NOTE
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.
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.
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.
NOTE
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.