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.
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
- Address Y2K, Euro, and other software and hardware
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.”)
|You can choose from a variety
of training on SMS, primarily instructor-led,
online training, and self-study. Many
factors drive the type of training. Instructor-led
training is the most costly but also the
quickest way to train, if the student
“crams” well and needs access to equipment
and software outside the job. Self-study
is the least expensive method but it can
take the most time and requires great
personal discipline. Online training brings
additional structure to self study and
is usually priced somewhere between instructor-led
The two Microsoft Official Curriculum
courses I recommend for the SMS administrator
- Course 827—Administering Microsoft
Systems Management Server 2.0. This
is a prerequisite for Course 828.
If you have equivalent knowledge,
this course can be skipped.
- Course 828—Deploying and Supporting
Microsoft Systems Management Server
Some education centers are bundling
these courses; check with a local Microsoft
Certified Technical Education Center
or Microsoft Authorized Academic Training
- Course 1241—Microsoft SMS 2.0 Training
Kit. This kit was created to prepare
you to plan for and administer SMS.
For more information about this self-study
kit, visit http://mspress.microsoft.com.
- SMS Administrator’s Guide—This
online book bundled with SMS 2.0 is
an excellent resource for building
on the knowledge gained through self-study
or instructor-led training.
Online training providers use a variety
of training materials. Go to www.microsoft.com/train_cert
for a list of training providers. And
for two free self-study courses on SMS.
They’re quite good and free for the
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.
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
- If real-time remote support is required, is there
a help desk staff that will support users with SMS remote
- 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
- 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.
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
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
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 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
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:
- Site server SMS root directory (application directory)
- Package stores used for software distribution
|Enable backup tasks in the
SMS Administrator console and then edit
the Backup Control File smsbkup.ctl contained
in the \SMS\inboxes\
smsbkup.box folder on the site server.
This file allows you to automate the backup
components you've installed on the site
server and site database server. For more
information on the Backup Control File,
use the search keyword smsbkup.ctl in
SMS online help; also open the Smsbkup.ctl
file with a text editor.
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
- 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
- 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
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
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.