SolutionBase: Deployment planning for SMS 2003

SMS 2003 is a powerful network management tool, but you can't blindly install it without some proper preparation. In this article, Scott Lowe discusses what you need to know about SMS 2003 and how to get ready to deploy it in your organization.

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 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.


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.


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.


A group of resources.


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.


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.