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.
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
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:
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.
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)
the SMS hierarchy.
SMS, taking into consideration security and recovery needs.
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
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
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!
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
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