In the first part of this SMS series, Get
a handle on network clients using SMS
, I provided a high-level overview of
SMS 2003 and its system requirements. In
this article, I will present to you common deployment planning considerations,
which will include some further requirements information. The purpose of this article is not to learn
exactly how to deploy SMS into a huge infrastructure, though. Rather, the purpose is to introduce concepts
related to SMS, and learn some of the considerations that must be made in order
to install and support this complex product.

SMS terms, concepts, and features

SMS is a fairly complex program and provides a huge amount
of functionality, but requires that you learn some new terms and concepts. Before you get into actually planning, let’s
go over some of these terms and concepts as they will make the job of planning
an appropriate installation much easier. Table A explains some of the things
you should know.

Table A

There are other terms and more advanced concepts that are
useful for particularly large SMS organizations that help to define how
management points are assigned to roaming devices, and how roaming devices are
supported by software distribution. For
this series of articles, these concepts are out-of-scope, however. In these articles, I will be working with a
single SMS site, although I will, in the next part of this series, provide an
example of child site installation and administration.

SMS deployment planning

Before you undertake an SMS deployment, particularly for
anything larger than a small, single-server SMS deployment, you should take
some time to plan the deployment in order to avoid problems with your initial
experience. I always recommend that you
deploy the product to a single server in a lab environment before you deploy into
production, particularly since SMS affects your Active Directory schema, and is
fairly complex.

I’m assuming that you’ve already taken the step of
identifying the organizational challenges that you’re attempting to correct,
that you’ve adequately documented your environment, and that you’re at least
basically familiar with the terms and concepts discussed in this article and
the previous article in this series.

For a complete enterprise-wide rollout of SMS, you should
consider the following steps as a part of your deployment plan:

  1. Understand
    SMS basics and deploy the product into a test environment similar enough
    to the real environment to be able to get a sense of how the product will
    perform and whether it will meet your organizational needs.
  2. Perform
    preplanning steps that analyze your current environment and management
    tools, and determine opportunities for integration (i.e. integration with
    a help desk product such as FootPrints)
  3. Create
    the SMS hierarchy.
  4. Installation
    planning.
  5. Deploy
    SMS, taking into consideration security and recovery needs.
  6. Deploy
    clients.
  7. Assess.

For this article series, I will be skipping steps 1 and 6;
step 5 will be included, but will be limited to deploying SMS. The SMS 2003 Concepts, Planning, and
Deployment guide will provide you with a complete breakdown of Microsoft’s
usual recommendations for enterprise software deployments.

SMS hierarchy design

One of the more important planning steps in your SMS
deployment is the hierarchical design, including site type and placement, role
setting, and more. For small environments
that plan to run from a single server with a single site, this step is not
critical, but if you have a need to support multiple locations, or you’re a
large, distributed organization, this step is critical as it can mean the
difference between the success and failure of your project.

Planning for this step consists, among other things, of
making sure you have an appropriate design diagram of your entire network
infrastructure, broken down by IP subnet. Your diagram should include all of your various geographic locations as
well, in order to be able to more adequately determine which sites should be
primary and which should be secondary, and which other roles are needed to
support your overall SMS infrastructure.

Don’t forget to include bandwidth calculations between major
locations as bandwidth needs will help you to determine where you need to
deploy distribution servers. As a part
of your bandwidth calculations, also try to ascertain at what times of day you
have peak loads on your interconnections.
Further, your diagram should indicate how many clients exist in each
location and on each subnet, as well as information regarding your Active
Directory hierarchy. Bear in mind that
SMS can be deployed in such a way that it uses your Active Directory site
structure, so this information is important.

On the client side of the equation, make sure you document
where you have clients not directly supported by Microsoft, such as Macintosh
and Linux systems. While not directly
supported by Microsoft, there are third party clients available that do extend
SMS’ management capabilities to non-Microsoft systems. Visit http://www.vintela.com/products/vmx/
for more information about a well-supported third party client. Also on the client side, make sure you have
the ability and rights to push the SMS client out to each desktop. Finally, bear in mind that the SMS Advanced
Client only runs on newer desktops, such as those running Windows 2000 or
better. Other machines need to use the
legacy client, which has an impact on how you need to deploy distribution
servers.

Also on the client side, make sure that all clients you want
to manage are members of a domain. SMS
does not support the management of non-domain systems.

At the end of the SMS hierarchy design discussion, you
should have a list of sites, have indicated which site will be the central
primary site, which sites will be primary, which sites will be secondary, and
how each site will interrelate with all other sites. Further, if you are in a particularly large
or distributed environment, you should have identified the locations for
various distribution points, management points, server locator points and client
access points. Some of these roles are
necessary only if you have older clients that require use of the legacy
client. Finally, your hierarchy design
should provide three-letter SMS site names for your entire SMS rollout. Remember that SMS site names cannot be
changed!

The Microsoft document SMS
2003 Concepts Planning Deployment Guide
provides an exhaustive, yet
comprehensive, overview of additional steps you should take for very large
installations of tens of thousands of SMS clients spread across dozens of
locations. Chapter 9 in that document
also provides an outstanding overview of sizing considerations for SMS servers,
which, again, is particularly important for larger deployments. For an article-length feature, it’s
impossible to replicate the contents of this 676-page document!

Installation planning

The SMS installation process itself should also undergo at
least some planning before you deploy into production. For example, you need to make decisions
regarding whether or not to extend the Active Directory schema, whether to
install SQL Server right on the SMS server or to use a separate SQL Server
system, if/how to introduce SQL Server replication for your SMS infrastructure,
backup and recovery, whether to use an Express or a Custom installation, and
whether to use Advanced or Standard security.

When it comes to making a decision as to whether or not to
extend the Active Directory schema, keep a couple of things in mind. First, SMS will work without extending the schema, but some features will
not. In particular, you will be unable
to publish SMS objects into Active Directory, and client features including
global roaming and automatic site assignment for a client can be hindered. Further, you will need to provide appropriate
entries in a WINS server for servers running certain SMS roles, such as server
locator points and management points. Unless you have a really good reason not to, I highly recommend that you
do extend the Active Directory schema
for SMS. An option to perform this
extension is provided during the installation, which you will see later in this
article. If you want to extend the
Active Directory schema before you install SMS, you can use the ExtADSch tool
to do so.

Like most other database applications, SMS supports both
local and remote SQL Server databases for its data warehousing needs. For performance reasons, Microsoft recommends
that you install SQL Server right onto the SMS server. In my environment, we have fairly recently
deployed SMS, but did not install SQL Server on the SMS server. Rather, we pointed SMS at our central SQL
Server 2000 cluster. However, we are not
a large environment. We are supporting
only a few hundred clients on our SMS server, and all of our servers are interconnected with gigabit links all
connected to the same switch fabric. As
such, we are also not doing any kind of database replication. If you are in a larger environment, database
replication may be desirable. Do note
that Microsoft does not recommend that you share a single SQL Server database
for multiple SMS sites.

When it comes to installation type–Custom or Express–Microsoft
does not recommend the use of the Express option for production sites. The Express option, on a primary site,
installs the SMS server, the SMS administrative console, remote tools, and some
scripts. The custom option, in contrast,
makes the remote tools and scripts optional components. In reality, the express setup option is fine
for smaller SMS rollouts. However, do
note that the Express option also enables just about every possible role on the
SMS server, including the client access, management point, and distribution
point roles. If you don’t need these
roles, use the custom installation method to gain more granular installation
control.

The final deployment topic that I will discuss in this
article is the security mode–Standard or Advanced–that you plan to use for
your SMS infrastructure. Before I get
started, I want to point out that, if you opt for advanced security, you can’t
change it back to standard, so make sure you’re able to meet all of your needs
before you choose the advanced option. You can change from Standard to Advanced any time.

Because of the tasks it performs, advanced security requires
the use of Active Directory in order to function. Whereas standard security uses user accounts
to handle SMS tasks, advanced security uses the Local System Account. Further, advanced security uses computer
accounts rather than user accounts to access clients. Advanced security is not available if any of
your site systems are running NT, or if you’re still using an NT domain. Specifically, all of your site systems need
to be at Windows 2000 SP2 or better in order to use advanced security.

On the security front, Microsoft also recommends that you
install the fewest possible SMS servers and management points that you can and
still provide the services you need to your infrastructure. If you’re running a large environment,
Microsoft has produced the document Scenarios
and Procedures for Microsoft Systems Management Server 2003: Security
. It’s 182 pages of information dedicated to
securing SMS. While I take security
seriously, my goal in this article series is to help you use SMS, so I won’t be discussing securing your sites very much.

The final topic of the security discussion has to do with
your firewall configuration and making sure it can pass all SMS traffic. Microsoft has dedicated knowledgebase
article 826852
to just this purpose.

Getting off on the right foot

A 600+ page guide, plus multiple 200-page guides to install
a piece of software may, at first glance, seem a bit over the top. However, bear in mind that SMS performs a
large number of functions, and is intended to be scalable to any size
organization, in as many locations as needed. As such, there is a certain complexity to the product.

This article was intended to help organizations with smaller
needs to get up to speed a little more quickly and be able to intelligently put
together a project plan for an SMS installation.

While this 3,000-word article can’t cover everything you
might need to know, the next part in this series will go over the installation
of a central primary site and a secondary site, with Active Directory schema
extensions being handled separately, to give you a better overview of how SMS
works. I find that installing a product
into a lab environment can go a long way toward learning how that product
works.























Site

In SMS, a site is a logical
administrative unit which defines the various resources, including users,
groups, and computers, that will be managed by SMS. SMS sites are defined by groups of subnets
or by Active Directory site names. Each
site is assigned a unique 3-letter code that cannot be changed after
installation.

There are two different
kinds of sites in SMS: Primary and Secondary.
A primary site stores SMS data itself in an SMS site database, and
primary site servers provide administrative tools that allow an SMS
administrator to manage a site. Within
the “primary site” class of SMS server, there are some different
classifications that can describe a site.
The top-level site in an organization is called the Central Site, and
has no children (defined later).
A central site is a special class of “parent site”. A parent site is a primary site that has
other sites that connect to it. A
parent site’s database contains information about all down level sites. A “child site”, on the other hand, is
attached to a parent site. A child
site can be a primary site, but can also be what SMS calls a “secondary
site”. A secondary site does not have
its own database, but instead forwards information to a primary site. Secondary sites are often used in remote
locations that will be managed from a central location.

When it comes to hierarchy,
a parent, including the central site server, can have many children,
resulting in a complex, but very flexible and extensible hierarchy made up of
different tiers. For example,
if you have two child servers connected to the central site primary server,
those two child server would be considered to be at the same tier and what
SMS calls “sibling sites

Site Server

The server onto which you
install SMS and related management or monitoring tools. The Site Server accesses the SMS site
database server
(described later), which can be installed on the same
machine, but does not have to be

Component Server

A site system role that is filled by any SMS site system running an SMS component installed by SMS Site Component Manager. The only site system that is not a component server is the distribution point.

SMS Site Database Server

This role is often shared
with a primary site server, and includes the SQL Server database, used to
store discovery, hardware, and other inventory data about a site. Every primary server must have a database
server.

Site Boundaries

A site boundary limits the
scope of a site by subnets or Active Directory site names (or both). This is the method by which SMS clients are
added to a site. Clients from a particular
IP subnet or AD site are added to the appropriate site server to be managed.

Client Access Point

The client access point
role acts as an intermediary between devices running the SMS legacy client
and the site server. This role must be
installed for each site that maintains legacy clients. This role is automatically installed on
each site server. I will not be
discussing this role in depth as it is not required for current operating
systems.

Distribution Point

Also automatically
installed on each site server, a distribution point is a point of contact
from which clients pull data when a new package is pushed for installation.

Management Point

The management point is the
contact point for systems running the advanced client, and performs such
chores as providing client configuration information, pointing clients at
distribution points, and for receiving from clients and forwarding to SMS
site servers inventory, status, and other related
information.

Server Locator Point

This role has the
responsibility of pointing clients, legacy and advanced, at client access
points and management points, respectively.

Reporting Point

This is an SMS server that
houses reports, and communicates only with an SMS site database server.

Resource

An object, such as a
computer, group of users, or even the SMS client itself that can be managed
by SMS. Resources are located through
the discovery process during which all pertinent information about a
resource is collected.

Collection

A group of resources.

Provider

Handles requests for
information from the SMS site database.
Generally installed on the site server or the site database server.

Hardware and Software Inventory

SMS feature. Provides an administrator with a detailed hardware
configuration and list of software installed on each managed device. This features uses
WMI (Windows Management Instrumentation) to accomplish the hardware side of
the equation. On the software side,
SMS uses the Add/Remove programs list and full disk scans to compile software
lists.

Software Distribution

SMS feature. Distributes software to managed clients and
provides a managed overview of the entire deployment process. Software distribution can use the data
gathered by the inventory processes to deploy software only to systems that
meet specific requirements that you define.

 

Software distribution is
handled via “package definition files”, which contain all of the necessary
information for a package to be deployed to a system. For large SMS hierarchies, you can opt to
deploy software in a number of different ways to provide for efficient
distribution and installation.

Software Update Management

SMS feature. Provides a patching mechanism for Windows, Microsoft
Office, Internet Explorer, SQL Server, and Exchange. This feature uses a number of tools,
including the software update inventory tools, Microsoft Office inventory
tool, and others, to handle the actual updates. Again, information gleaned from the various
inventories can be used to assist in this process.

Software Metering

SMS feature. Allows IT to monitor program usage on
clients and really see how various software investments are being used, and
to maintain and monitor licensing compliance.

Remote Tools

SMS feature. A collection of tools that help
administrators support end-user workstations.
Includes remote reboot, remote control, remote
execution, chat and file transfer capabilities.

Reporting

Allows you to run one of
SMS’ included reports, or run your own reports against the plethora of data
captured by SMS.

Product Compliance

Working in conjunction with
the software information, SMS’ product compliance feature can help an organization
enforce IT policies on software usage.
For example, you may not allow older versions of Office to be run
because of various unpatched security
problems. You can create a product
compliance rule that disallows execution of the Office 97 programs.