Enterprise Manageability The Definitive Guide To Jeremy Moskowitz

Enterprise Manageability The Definitive Guide To Jeremy Moskowitz
The Definitive Guide To
Enterprise Manageability
Jeremy Moskowitz
Chapter 3
Chapter 3: SMS as a Solution ....................................................................................................... 66
SMS Planning and Architecture.................................................................................................... 66
SMS Sites .......................................................................................................................... 66
SMS Site Hierarchy........................................................................................................... 67
SMS Components.............................................................................................................. 68
SMS Flow Review ............................................................................................................ 70
Server Sizing ..................................................................................................................... 71
Disk Storage .......................................................................................................... 71
RAM and Processor Considerations ..................................................................... 72
Total Hardware Considerations............................................................................. 72
Installing Your First SMS Site ...................................................................................................... 73
Exploring the SMS Administrator's Console ................................................................................ 80
Telling SMS a Bit About Your Site .............................................................................................. 83
Discovering and Installing Your First Clients............................................................................... 84
Discovery Methods ........................................................................................................... 84
Installation Methods.......................................................................................................... 85
Installation Agents......................................................................................................................... 88
Verifying the Client....................................................................................................................... 90
Inspecting the Hardware and Software Inventory......................................................................... 91
Remotely Controlling the Client ................................................................................................... 93
Understanding Collections ............................................................................................................ 97
Predefined Collections ...................................................................................................... 97
Direct Collections.............................................................................................................. 98
Query-Based Collections................................................................................................. 100
Advertising a Software Package to a Collection......................................................................... 103
Understanding the Distribution Lingo............................................................................. 103
What Can You Send? ...................................................................................................... 103
Distributing a PDF/SMS Package ................................................................................... 104
How Clients Get Advertised Packages............................................................................ 108
What's New for the Next Version of SMS? ................................................................................ 109
Summary ..................................................................................................................................... 110
Chapter 3
Chapter 3: SMS as a Solution
In the last chapter, we examined various ways to ensure that our environment is as predictable as
possible. First, we started out by taking a rudimentary inventory of our systems—both NT-based
(including Win2K and Windows XP Pro) and Win9x-based systems. We then took a network
inventory. We used this information to move equipment to provide our power-hungry users with
increased bandwidth.
We went on to create a more compatible environment using the Apcompat.exe support tool and
Slayerui.dll. We left behind DLL hell with the use of the SFC, DLL-redirection, and side-by-side
instancing. We discussed how to bring a machine from 0 to 60 by using an unattended answer
file, RIS, and Sysprep. Finally, we learned when it's best to use Sneakernet, Group Policy, or—
for extra horsepower—SMS. In this chapter, we’re going to explore a simple SMS 2.0
implementation to gain insight about how we can best use this tool in our environment.
You should not take an enterprise-wide SMS installation lightly. Although SMS is fairly easy to install,
don’t underestimate its power. SMS is, quite possibly, one of Microsoft’s most intricate products, and
it has an amazingly far reach and scope. Because SMS can touch every Windows node on your
network, you should seek approval from your Change Management committee after a thorough
investigation of its capabilities within your environment. This chapter is not meant to provide the full
design review that is required before you implement SMS. Rather, this chapter will highlight SMS
features that will lower your TCO should you choose to implement them.
SMS Planning and Architecture
As we've discussed in previous chapters, SMS has four main functions:
Hardware and software inventory
Software distribution
Remote tools
Software metering
In this chapter, we'll be working with three of the four main features, excluding software
metering because it doesn’t fit within the scope of this chapter.
SMS is able to perform most of its magic because of the way Microsoft designed it. The SMS
architecture is fairly straightforward.
SMS Sites
SMS systems (server components and client components) are members of an SMS site. An SMS
site is defined much in the same way that a Win2K site is defined—as a collection of IP subnets
that have slow connectivity between them. Therefore, if you have three campuses in your
organization—Delaware, Arizona, and New York, you'll likely have three Win2K sites as well as
three SMS sites. There are two types of sites: primary sites and secondary sites. All sites have
one or more SMS site servers on which all the SMS services run.
Chapter 3
All known data about the resources on your network is stored in a SQL Server database on a
system called an SMS site database server. The SMS site database server can run SQL Server 6.5
or later.
SMS 2.0 can work with SQL Server 2000, but the SMS CD-ROM must have SMS SP2 slipstreamed
in. SMS SP2 is now slipstreamed into the shipping product, so anyone buying new copies of SMS 2.0
doesn’t have to worry about it.
Although you can set up the SQL Server system to have databases other than the SMS database
located on it, for ease of administration, you should grant SMS exclusive use of its own SQL
Server system.
The SMS site server and the SMS site database server can be the same box. If you do so, SMS
automatically performs SQL Server tuning, relieving the hassle of tuning the SQL Server machine
before introducing the SMS database.
If an SMS site contains an SMS site database server (that is, a system that runs SMS and SQL
Server), the site is considered a primary site. An SMS site that doesn’t have an SMS site
database server is considered a secondary site.
Primary sites are handy and are required in certain circumstances. For instance, you will use a
primary site when
You are installing the first (or only) SMS site. The first site is given a special moniker—
the central site.
You have a large collection of users in one site.
You have an administrator who can handle the day-to-day care and feeding of an SMS
and SQL Server system in a site.
You think you might have a need for a child site someday.
Otherwise, you'll create secondary sites. You create secondary sites when
You have a small collection of users.
You have no administrator for an SMS and SQL Server system for the site.
You do not want the overhead or cost of an additional SQL Server system.
All sites (primary and secondary) are designated with a unique three-character site code, which
you choose.
SMS Site Hierarchy
If you determine that you want or need more than one site, you'll need to produce what's called a
hierarchy of SMS sites. As Figure 3.1 shows, a hierarchy is a simple parent-child relationship:
Primary sites can be parents or children.
Primary sites (as parents) can have either primary sites or secondary sites as children.
Secondary sites cannot have children.
Chapter 3
Figure 3.1: A sample SMS hierarchy of parent and child and primary and secondary sites.
A hierarchy serves a dual purpose. First, it allows administration from a parent level to
automatically affect all child levels under that parent level. Additionally, all child levels report to
their parents. All parents eventually report to the central site. The central site holds all data for all
resources, therefore having a birds-eye view of the entire SMS network.
SMS Components
SMS has various processes that run on various servers in your environment. An SMS site server
(sometimes called a site system) is an NT or Win2K Server system that hosts one of these
SMS logon points are the client’s first point of contact with the SMS environment. These logon
points tell the client computer which site the computer belongs to and refer the client toward an
SMS client access point (CAP).
SMS CAPs are the next place a client looks for information. A CAP is the main point of contact
for a client and where the client connects when it's ready to dump hardware and software
inventory or discover software packages are being offered. CAPs are an important component for
SMS, as they provide a crucial layer of abstraction between the clients and the SQL Server
database (that is, the SMS site database server). Clients never talk directly to the SQL Server
database, rather they always communicate with a CAP, which processes the client's information,
then makes sure that the information is safely relayed to the site server. The site server’s job is to
place the collected information into the SQL Server database.
Chapter 3
The SMS logon point and CAP can be the same box. For instance, a client could log on to a domain
and be validated by a domain controller that has been designated as both an SMS logon point and
CAP. In this case, the client simply talks first to the logon point processes, which refer the client to the
CAP, which happens to be the same server. This configuration is common.
SMS distribution points are simply servers that have sharepoints that are accessible to clients.
These servers should have plenty of available hard drive space because clients grab software
from these servers through software distribution. SMS distribution points do not need to be
Windows based; they could be Novell machines if the clients have the ability to connect to
Novell-based shares, through, for example, Novell's client for NetWare.
For that matter, logon points and CAPs can also be NetWare servers. However, SMS site servers,
software metering servers, and site database servers must be Windows-based systems.
As you can see in Figure 3.2, the logon points, CAPs, and distribution points can be on the same
Figure 3.2: Logon points, CAPs, and distribution points can be on the same hardware or on multiple
SMS clients are where the rubber meets the road. SMS clients can be any of the following:
Windows XP Pro (when SMS Service Pack 3—SP3— or later is installed on the SMS
site server)
Win2K Workstation or Server systems (when SMS SP2 or later is installed)
Chapter 3
NT 4.0 Workstation or Server with SP4 or later
NT 3.51 Workstation or Server with SP5 or later
Windows for Workgroups
Windows 3.1
SMS does not support
Windows XP Home Edition
DOS clients (including LAN Manager 2.2c)
SMS 1.2 supports DOS, Macintosh, and IBM OS/2 clients. If you need to support those clients, you
can create a hierarchy in which an SMS 2.0 parent site controls an SMS 1.2 child site consisting of
any of DOS, Macintosh, and IBM OS/2 clients.
SMS 2.0 doesn’t offer UNIX support. However, there are add-on packages to enable UNIX
manageability within SMS 2.0. These products are available from Altiris Software (which merged with
Computing Edge in 2000). Check out http://www.altiris.com for more information.
SMS Flow Review
After the server components are set up in a site, Windows computers are ready to become SMS
resources. To get the SMS client software, a target computer will locate a logon point when a
user logs onto the client. (However, the user doesn’t have to log onto the client for the target
computer to locate a logon point. Later in this chapter, I’ll explain how the target system locates
a logon point even if a user does not log onto the target system.)
When a user logs onto the client, the client usually runs a logon script. SMS has the ability to
modify the default logon scripts so that the logon scripts run a little program that loads some
initial SMS components. Once those initial components are loaded from the logon point, the
client accepts a list of CAPs that are in the client's site. A CAP is chosen at random, a connection
is established, and the rest of the SMS client components are installed.
After the SMS client components settle in, regular ongoing communication can occur between
the clients, the logon points, and the CAPs. That is, at next logon, the logon point tells the client
the list of the current list of CAPs in the site.
If hardware and software inventory is set up, the client will push its inventory list to the CAPs,
which, in turn, will push the list to the site server on which the list belongs. Each site server then
passes the collected client information up the chain until all information is received at the central
site server.
Chapter 3
If software distribution is set up and packages are offered for the client, the packages are pulled
from a distribution point at the time the administrator specifies or a client can choose to grab the
packages whenever the client chooses. Figure 3.3 shows the SMS communication flow.
Figure 3.3: Client and server communication.
Server Sizing
In the last chapter, you were able to gauge the number of clients in your network using various
built-in and third-party tools. To know how to size your servers, you'll need to know roughly
how many clients you need to serve.
Disk Storage
You can use a simple formula to help you plan for database sizing on your SQL Server:
10MB + (x × 100KB) = needed megabytes for database size
Replace x with the number of clients, and voila, you have a rough idea of how big the database
should be. This formula makes several assumptions about how you will use SMS, including how
often hardware and software inventory will be checked on the client.
Collection for a large inventory of objects will cause the database to grow quickly.
If you guess that you have 300 clients, the approximate database size will be 10 + (300 ×
100KB) = about 30MB. Not a whole lot. But if you have 3000 clients, the amount of needed disk
space for the database jumps to about 210MB. If you have 30,000 clients, your database requires
a little more than 2GB of disk space.
SMS has the ability to maintain histories of certain important files, such as the AUTOEXEC.BAT, if
desired. This size estimate does not take into account files preserved in this manner.
Chapter 3
Each server in the hierarchy is responsible for holding the data for the clients in its site, and all
the data for the sites below it. You will likely have to size your servers incrementally larger and
beefier the higher up the hierarchy you go.
SMS requires 1GB of free disk space to install. This requirement doesn’t include the space required
for the SQL Server components, which may (and often should) be on the same site server you
designate for SMS.
Depending on the size of your network, a healthy recommendation for sizing an SMS 2.0 site
database server is between 6GB and 12GB of usable database space.
Always overestimate how many SMS clients you will have on your network. Even in a stagnate
environment, you should multiply your current population by 1.5. Therefore, if you have 1000 users,
estimate for 1500 users.
Best performance will be found on systems with RAID-5 hardware, especially if the database is
isolated on separate RAID-5 hardware from the Windows system and log files.
RAM and Processor Considerations
SQL Server and SMS are both RAM users. Because most configurations will utilize the single
SMS and SQL Server site server configuration, plenty of RAM should be allocated for this
system. Modern machines can take many gigabytes of RAM, and with the OS, SQL Server, and
SMS on the same box, the RAM will definitely be used. Start your single-server site servers off
with 256MB of RAM minimum; consider 512MB of RAM for configurations with more than
1000 clients, and 1GB of RAM for 2000 clients and more. Single processor Pentium III XEON
systems will do for most server loads, but because the central server needs to process all other
child server data, consider making that box a dual-processor box if possible.
Total Hardware Considerations
If you want to buy fewer hardware boxes but want to run more components on a box, be
prepared for slower performance or be ready to throw more hardware inside the box. For
instance, a reasonable expectation is to house the logon point and CAP on the same hardware.
However, if, in a pinch, you also need to make that same equipment a distribution point, you're
suddenly putting a very high demand on the machine.
If you wanted a machine that had every component on it (SQL Server, SMS site server, logon
point, CAP, and distribution point) you may need a monumental machine to handle the capacity
at peak times. For instance, at logon time, the server would have to handle logon requests, give
the list of CAPs (including itself), deal with the hardware and software inventory, and potentially
send the information up the food chain—all while distributing software to hungry clients! Ouch!
So, consider the load each machine will shoulder in your SMS environment. For these hardware
considerations, a consultant's experience can really help guide decisions about which hardware is
right for your environment.
Chapter 3
Installing Your First SMS Site
After you've laid out how you want your parent-child relationship to work, determined which
sites are going to have SQL Server systems (and hence become primary sites), and decided
which sites are not going to have SQL Server systems (and hence become secondary sites),
you're ready to install your first site. You start by inserting the SMS CD-ROM into the drive of
the system that you want to configure as the site server (or combination site server and site
database server). For information about how to choose the right media, see the sidebar “Getting
the Media Straight”
Getting the Media Straight
The SMS 2.0 CD-ROM comes from Microsoft in two flavors—without a service pack and with SMS SP2
embedded. All the fixes that were included in SMS SP1 are included in SP2. If you only have the CDROM version that doesn’t include SP2, you can infuse SP2 onto an installation and burn your own CDROM with the results.
This process is simple but lengthy. You'll first need to download SMS SP2 from the Microsoft Web site at
http://www.microsoft.com/smsmgmt/downloads/sms20sp2.asp. Then, you'll need to have your SMS CDROM handy. When you go to run the service pack, you are prompted to create an image of the CD-ROM
to a writeable location. Then, the service pack is applied on top of that writeable location. This process is
called slipstreaming. Once completed, you can burn a CD-ROM from the results.
Before you install SMS on any Win2K Server or Pro machines, you'll need to standardize the version of
SMS that you want to use—SP2 or SP3. (SMS SP4 is right around the corner.) However, SMS SP3 is not
a slipstreamed installation. Rather, you must start your installation with an SMS CD-ROM slipstreamed
with SP2, then apply SP3 to the central site server after the SMS SP2 installation. For more information,
see the Microsoft technical note "Systems Management Server 2.0 Service Pack 3 (SP3)"
p3.asp) and the Microsoft whitepaper "Deploying SMS Service Packs" at
After you insert the SMS 2.0 CD-ROM, Windows' auto-play feature should present the SMS 2.0
welcome screen, which Figure 3.4 shows.
Figure 3.4: The SMS CD-ROM opening screen.
Chapter 3
If you're planning to run SMS on NT 4.0 servers, the server needs to be running at least NT SP4,
which comes on the SMS 2.0 CD-ROM (both the version that includes SMS SP2 and the version
that includes only SMS). SP6a is the latest service pack for NT 4.0, and works well with SMS.
If you're planning to run SMS on Win2K servers, no Windows service pack is required, although
Win2K SP2 offers some compatibility updates that include fixes for SMS. However, to run SMS on
Win2K server, you are required to have SMS SP2. To create your own slipstreamed version of SMS
with SP2, please see the proceeding sidebar “Getting the Media Straight.”
To start off the journey, simply click Set Up SMS 2.0 on the welcome screen. You are presented
with the SMS 2.0 Setup Wizard. Click Next to continue. SMS Setup Wizard will make sure you
aren't trying to modify an existing setup. After it finds no SMS components, click Next to get to
the Setup Options screen, and select the first option to install the first site, as Figure 3.5 shows.
Figure 3.5: Choose the first option to install the first site.
Because this site is the first SMS site, select the option to install an SMS primary site, and click
Next. If you already had a site hierarchy established, you could add another primary site, a
secondary site, or just install the SMS administrative console.
Installing an SMS primary site also installs the SMS administrator's tools on the same machine.
You are then presented with the Installation Options screen, which Figure 3.6 shows.
Chapter 3
Figure 3.6: Choose Custom Setup to select the components you want to install.
If you are installing an evaluation edition of SMS 2.0, you have three options. Otherwise, you
simply have to choose between Express Setup and Custom Setup. Express Setup essentially
loads every SMS option. We'll select Custom Setup.
If you select the Express Setup installation option on a production network, all SMS components are
installed and most are enabled. Thus, the Windows Network Logon Discovery and Installation will be
enabled, your domain controllers will automatically have files and services added to them, and your
clients will begin to install the SMS client components at their next logon. The clients will take
inventory—both hardware and software—and will be prepared for software distribution. Custom setup
installs only the components you select and does not enable any SMS components.
After you select Custom Setup and click Next, the wizard takes you to the Required Fix Notice
window. You won’t need to worry about the required fix unless you have multiple sites and
some are running versions earlier than SMS SP2. After this window, you must agree to the
licensing agreement.
After that, enter in your product ID, along with your name and organization. Next, you'll be
presented with the SMS Site Information screen, which Figure 3.7 shows. In this window, you
instruct SMS what you want to call the first site as well as dictate the three-letter code.
Remember, the three-letter code must be unique throughout the organization.
The three-letter code must be unique, but SMS doesn't check. If you enter the same three-letter site
code as another server, you cannot change it, and you must reinstall SMS on the server that has the
duplicated site code.
Chapter 3
Figure 3.7: Give your site a unique three-letter site code and name.
You are then prompted to enter the service account, as Figure 3.8 shows. This account will be
granted Domain Administrator rights as well as the Log On as a Service right, so take special
care in choosing a password.
Figure 3.8: Enter in a service account name and password.
I have changed the default account from SMSService to _SMSService. An underscore is useful to
preface service account names so they "bubble up" to the top in user lists when sorting in User
Manager for Domains and Active Directory Users and Computers.
Chapter 3
Next, the wizard presents the SMS Primary Site Client load screen. Because you’re installing the
first site in the hierarchy, you’ll need to specify the total aggregate number of clients you expect
in the SMS system. If you were installing a child site, you would need to enter the aggregate
number of clients expected from this point in the hierarchy down.
The wizard next presents the SMS Server Platform screen. You can, theoretically, load SMS 2.0
on Alpha machines running NT 4.0. Select Next to continue with the default settings.
In the SMS Server Platform screen, SMS automatically picks the drive that has the most free space
on an NTFS partition. However, you can change the drive setting in this window if necessary.
In the next window, you must select the SMS components you want to explore, as Figure 3.9
Any check box you select now cannot be uninstalled later. As a consolation, just because you install a
component doesn’t mean you have to use it.
Figure 3.9: SMS has some optional components.
For the purposes of these examples, we will be initially loading as the following lists describe.
Items to leave unchecked:
All software metering components
SMS installer
NetWare components
Product compliant database
Items you can optionally select:
Chapter 3
Systems Management Server (already selected)
SMS Administrator Console (already selected)
Remote Tools (required for the exercises in this chapter)
Network Monitor (not required for the exercises in this chapter)
Package Automation Scripts (helpful, but not required for the exercises in this chapter)
Crystal Reports (If your network includes less than 500 users, select this item, but this
item isn’t required for the exercises in this chapter. For more information about Crystal
Reports, see the sidebar “Working with Crystal Reports.”)
Working with Crystal Reports
SMS’ Crystal Reports component is not meant to be used for an aggregate client count of more than 500
users. It is simply a sample application to show off some reporting features. Crystal Reports will fail to
function with an aggregate client count of more than 500 users and should not be installed in such a case.
You will get a warning message from the SMS installer program regardless of the amount of aggregate
users you put in the previous steps.
There are two known workarounds. One workaround is to manipulate your site hierarchy so that the
central site is the only site using the built-in Crystal Reports component. You can find the details about
this problem in the Microsoft article "SMS: Support Options for Crystal Info (Reports)”
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;q215469). This workaround is usually not a
good option. Alternatively, you can step up to the fully working version of Crystal Reports. To do so, you
need Crystal Reports for SMS Server, a third-party add-on from Crystal Decisions
Another option is a free download from Microsoft called the Web Reporting tool. You can download this
tool for free from http://www.microsoft.com/smserver/downloads/20/tools/webreport.asp.
Next, the wizard takes you to the Dedicated Copy of SQL window. For most installations, you’ll
want to choose Yes. SMS will automatically set up SQL Server for you as well as tune it for
SMS. By default, the SQL Server Administrator Account window is populated with the same
password as the SMS service account. You can change it if you want. Click Next to continue.
The wizard then takes you to the SQL Server Installation screen. If you have the hardware to
keep all three components separate (that is, the OS, SMS, and SQL Server), I advise that you do
so for speed and safety. The Concurrent SMS Administrator Consoles screen is next. This screen
helps you tune SQL Server for the number of in-bound connections. Finally, the SMS
Installation summary screen appears, as Figure 3.10 shows.
Chapter 3
Figure 3.10: Click Finish to kick off the installation process.
Be sure to review the proposed information to make sure the configuration has the settings that
you desire, paying particular attention to the name of the service account, the site name, and the
site code. When you click Finish, the service account is created, and if you selected an integrated
SQL Server installation, you will be prompted for the SQL Server media.
The SMS evaluation version has SQL Server 7.0 on the CD-ROM, so you will not be prompted.
When SQL Server and SMS are finished loading, you should be prompted with a final message,
as Figure 3.11 shows.
Figure 3.11: Sweet success after a long installation.
After you click OK, you will be presented with the SMS group through Windows Explorer, as
Figure 3.12 shows.
Chapter 3
Figure 3.12: The SMS 2.0 program group.
You have now successfully created the first site and the first site sever in that site. This first site
server is burdened with a very heavy load. Specifically, it takes on all roles as we defined. If it's a
domain controller, it automatically becomes a logon point, a CAP, and a distribution point in addition
to its duties as an SMS site server—the central site server—and hosting SQL Server! This default
setup is fine for our testing, but in a real-world deployment, it is unlikely that you would have one box
that shoulders the entire load.
Exploring the SMS Administrator's Console
Let's take a look at the main tool we'll use to manage our SMS environment: the SMS
Administrator Console. Simply double-click the console’s icon or click Start, Programs, Systems
Management Server, SMS Administrator Console. Either option causes the system to present the
console, which Figure 3.13 shows. The SMS Administrator Console is similar to Windows
Explorer and Exchange 2000; it uses layers of folders each containing various settings to
configure. For the purposes of discussion, several points have been highlighted in Figure 3.13.
Chapter 3
Figure 3.13: The SMS Administrator Console.
SMS is a huge product. Instead of discussing every configurable configurable option, we'll focus
on the most essential pieces of the product so that you can explore SMS to see whether it will
suit your needs. In the following bulleted list, the numbers correspond with the numbered items
in Figure 3.13:
Item 1: Site Definition—During the installation, you named the site and gave it a unique
three-letter SMS code. That code is listed here, and lets you know that you're currently
set to work on the site you want.
Item 2: Client Agents—SMS runs in a client-server model. That is, the server dictates
which actions the client can perform. This setting lets you turn on and off which features
SMS clients will use. We'll explore this option in a minute.
Item 3: Client Installation Methods—For clients to “join” the SMS club, they must have a
client component run on their desktop. There are various methods that enable clients'
ability to "join.” We'll explore those options in the next section.
Chapter 3
Item 4: Discovery Methods—Clients are discovered, then show up in the SMS database.
This process is sometimes confusing because clients can be discovered by the SMS
system but not have the SMS client running on them. Discovery is simply your chance to
see what's out there without having to intrude on the clients with the actual SMS
software. After running the discovery process, you might learn something you didn't
know about your environment. Perhaps you'll find out about an additional mystery server
in Engineering. With that knowledge, you can decide whether to install SMS on the
system. Discovery can also nose out devices, such as your routers, and add them to a
network diagram. You can install the SMS client on systems without running a discovery
Figure 3.14: Understanding the discovery process.
Item 5: Collections—SMS is able to round up groups of machines or of any user type and
allow them to be a target for a software distribution. We'll explore this option in the
section entitled “Understanding Collections.”
Item 6: Packages—With this setting, you tell SMS which software packages to use for
software distribution.
Item 7: Advertisements—You use this setting to offer packages to collections. Figure
3.15 illustrates the relationship between collections, packages, and advertisements.
Figure 3.15: Understanding software distributions.
Item 8: Queries—This option is the window to the SMS database. You shouldn't really be
directly inspecting the underlying SQL Server database on which SMS relies. Rather, use
the Queries tool to mine for the data that you're looking for. You can use the results of
Queries to create collections, as we'll explore later.
Item 9: System Status—SMS has a lot of nooks and crannies, and occasionally things get
jammed up in the works. The System Status helps you begin to discover where things
might be stuck.
Item 10: Tools—From Tools, you can use the rudimentary Crystal Reports generator, as
well as determine which internal components of SMS are running.
Chapter 3
Telling SMS a Bit About Your Site
Before you can really do anything with SMS, you need to kick start its knowledge about its
surroundings. SMS must be told which IP subnets it can search for clients. To perform this
crucial step, simply right-click the three-letter site code, click Properties in the resulting menu,
and select the Boundaries tab, as Figure 3.16 shows.
Figure 3.16: You need to define the site boundaries of an SMS site before you can use the site.
By default, SMS adds the only subnet it knows of—the one on which you installed it. If your site
has more subnets, you'll need to tell SMS. Simply click the Add icon (which looks like a little
starburst and appears next to the X at the upper right corner of the window), and add each subnet
in the site.
If you have multiple subnet masks, you must use a different method to tell SMS about your network.
To learn how to describe your network to SMS, read the Microsoft article "SMS: Defining Site
Boundaries in Systems Management Server 2.0" at
Remember that only clients inside the boundaries you define will ever become SMS clients.
Chapter 3
Discovering and Installing Your First Clients
Contrary to popular belief, SMS doesn't just take over all the client machines on the network
(that is, unless, you choose the Express Installation). In fact, SMS's usual operation is quite the
opposite. SMS must be told, specifically, how to locate clients, and how the clients can join the
SMS site.
Discovery Methods
A client is discovered when SMS detects it. As Figure 3.14 illustrated, you must first turn on a
discovery method. Really, you're turning on a detection mechanism. Simply click the Discovery
Methods option (Item 4 in Figure 3.13) to expose the potential discovery methods, as Figure 3.17
Figure 3.17: SMS offers multiple discovery methods.
The discovery methods that SMS offers include:
Windows Networking Logon Discovery—Enable this method when you want clients to
be discovered through an NT-style logon script. These scripts are the logon scripts that
run in the NETLOGON share, not Group Policy-based Win2K-style logon scripts. We'll
be changing the Windows Network Logon Discovery setting in a just a bit.
Windows NT User Account Discovery—Enable this method to allow SMS to paw
through the NT or Win2K accounts database to see which user accounts can join the SMS
site network. Enabling this setting doesn't actually affect any user accounts; it simply
grants SMS the ability, later, to target the user accounts for software distribution.
Chapter 3
Windows NT User Group Discovery—This method is similar to the Windows NT User
Account Discovery method, except that the Windows NT User Group Discovery method
enumerates groups instead of users.
Heartbeat Discovery—You use this method in situations in which users log on and stay
logged on to machines. This method keeps machines active in the SMS database instead
of having them fall off due to disuse. This method works only on previously installed
Network Discovery—You can set up this method to use various networking methods to
sweep for clients. Specifically, you can give SMS a specific subnet, an SMTP community
(if enabled on the client), a DHCP server's database, or a foreign domain to search.
Enable your first discovery method by double-clicking on Windows Networking Logon
Discovery. Figure 3.18 shows the resulting window.
Figure 3.18: Enable the Windows Networking Logon Discovery method.
To enable the Windows Networking Logon Discovery method, simply select the Enable
Windows Networking Logon Discovery check box. This selection will prepare all logon points
(that is, domain controllers) in the domain (for example, RTP) for initial client communication.
You needn't make any additional changes at this time. Simply click OK.
Installation Methods
There are two installation methods. You can view these methods by clicking Client Installation
Methods, as Figure 3.19 shows.
Chapter 3
Figure 3.19: Selecting your client installation method(s).
Windows Networking Logon Client Installation—If you enable this installation method,
existing logon scripts can be automatically or manually modified to tell clients that they
are ready to receive SMS. If no logon scripts exist for a user, the client is automatically
assigned a logon script that enables SMS on the client.
Windows NT Remote Client Installation—This method automatically installs the client
on systems on which users don't frequently log on. For instance, in the server room, on a
kiosk desktop that is always logged on.
For our purposes, we're going to simply double-click the Windows Networking Logon Client
Installation selection. To enable this option, simply select the Enable Windows Networking
Logon Client Installation check box in the resulting window. This selection will prepare all
logon points (that is, domain controllers) in the domain (for example, RTP) for client
communication. Next, click the Logon Settings tab to view the window that Figure 3.20 shows.
Chapter 3
Figure 3.20: Use this dialog box to modify the logon scripts.
The dialog box that Figure 3.20 shows tells SMS to locate all the logon scripts in the
NETLOGON share of the domain controllers, and once a day, update them to make sure that the
SMS client-initiation script is linked. Thus, when clients run their normal logon scripts, they run
the logon script, then link to the SMS client-initiation scripts. If the client doesn't run a script,
this setting ensures that the client simply gets the client-initiation script.
If you tell SMS to modify the logon scripts, there are three possible results. First, the user has no
logon script configured on his or her profile. Therefore, the user just gets an entry for the SMS logon
script (SMSLS). Second, the user already has a logon script configured called something.BAT, in
which case SMS modifies the user’s current .BAT script by adding “call SMSLS” at the top or bottom,
as you specify. Third, if the user has a logon script without an extension (for example, just “sales”),
SMS won’t touch the logon script—it will not link to SMSLS at all, add the SMSLS to the user profile
page, or modify the logon script that doesn’t have an extension. You can use the knowledge of this
behavior to your advantage if you have a user who should not receive the SMS logon scripts for some
reason. Simply give them a logon script (or the name of a bogus script) that has no extension, and
SMS will leave the user alone for logon discovery and installation.
At this point, you should take a break. SMS can take a while to propagate the various NT and
Win2K domain controllers with the SMS logon scripts and to set up all the necessary
components to allow for client communication.
When this process is done, you can verify its success. First, double-click any user account in the
domain (except Administrator) and make sure that there is a logon script entry on the Profile tab. If
the user doesn't have a logon script, the user will be assigned SMSLS.BAT. Additionally, make sure
there is a batch file named SMSLS.BAT in the NETLOGON share on each domain controller.
To review, you set up three things to enable your clients to communicate with the SMS system:
You set the SMS site boundaries to include the subnets in its focus.
You set the SMS discovery method of your choice.
Chapter 3
You set the SMS installation method of your choice.
After you complete all three steps, you should start to get SMS clients in your system. Clients
will appear during the normal course of business, when the user logs off and logs on again. But
what will you be able to do with the clients? We’ll explore the answer to this question in the next
Installation Agents
You've set up the boundaries and the discovery and the installation methods. You're ready to tell
the clients which features of SMS you want to use. You can choose to do this step as soon as the
first SMS site server is installed, or any time afterward. If you do so any time afterward, your
clients will not immediately get the signal that you want a change; this process might take as
long as 24 hours. As Figure 3.21 shows, simply click the Client Agents selection to view a list of
things you can do.
Figure 3.21: Use Client Agents to define which features your clients will use.
The following list provides a rundown of the options available for clients:
Hardware Inventory Client Agent—This agent enables hardware inventory on the client.
Hardware inventory is initially transmitted to the CAP, then the CAP transmits it to the
site server.
Chapter 3
Software Inventory Client Agent—This agent enables software inventory on the client.
Software inventory is initially transmitted in the same way as the hardware inventory;
that is, first to the CAP, then the CAP transmits it to the site server. By default, software
inventory scans every .EXE file, reads the header information, and uses that information
to describe the software it finds. You can also set up this inventory process for DLLs. In
addition, there is a facility that lets you grab special important files, such as
AUTOEXEC.BATs, on, for example, Win95 clients.
Remote Tools Client Agent—This agent allows administrators to remotely control
Advertised Programs Client Agent—This agent allows administrators to push software to
the clients.
Event to Trap Translator Client Agent—This agent will push a Windows event (that is,
an event found in a client's Event Viewer) back out in SNMP format for other systems to
capture. This feature is useful for environments in which HP OpenView and other larger
systems are installed.
For our example, double-click each entry (Except Event to Trap Translator Client Agent), and
select the corresponding enable check box on the first page that comes up. You needn't make any
changes on any other tab in any agent. Figure 3.22 shows all four check boxes at a glance.
Figure 3.22: Enabling four Client Agents.
Chapter 3
For the upcoming examples, specifying a time of 5 minutes for the Advertised Programs Client
Agent Properties would be best, rather than leaving the default setting of 60 minutes. However, I
don’t recommend a setting of 5 minutes in the real world because this setting causes increased
load on the clients.
Verifying the Client
You’re now ready to log on as your first client. Again, be sure that you've verified that the user’s
logon Profile tab has the SMSLS script in it, or that the user's current logon script has been
automatically modified to execute SMSLS, which is a .BAT file. Figure 3.23 shows the Profile
Figure 3.23: Ensure that the user is automatically set to run SMSLS.BAT or a script that calls SMSLS.BAT.
After you log on as the user (Sally User in this example), you will briefly see the logon script
kicked off in a minimized window on the desktop, run for several seconds, then disappear.
Afterward, the user's normal desktop should appear.
At the client, you can ensure SMS is being loaded by inspecting the Systems Management
Control Panel applet, which Figure 3.24 shows.
Figure 3.24: Look for the Systems Management icon in Control Panel.
Chapter 3
You can double-click the Systems Management icon to see whether the client is fully installed.
After you double-click this icon, you are presented with three tabs: General, Sites, and
Components. Click the Components tab, which Figure 3.25 shows, to see which components
have been properly installed.
Figure 3.25: Make sure all components have a status of Installed.
You should see a status of Installed next to all components. If you see Not Available, wait a little
while to see if the status changes. If you have many clients pounding the SMS CAPs at once, the
clients might take a little while to get all the components.
If the components do not get installed after a while, they should, theoretically, be installed
around a day later due to normal SMS processes refresh. If you don’t want to wait that long,
click the Sites tab, then click Update Configuration. You might also have to click Repair
Installation on the Components tab. Moreover, the information on the tab isn't dynamically
generated; rather, you need to keep pressing Refresh Status to see whether things are really being
Inspecting the Hardware and Software Inventory
After your client is loaded, the client should automatically kick off both the hardware and
software inventory, which you configured in Client Agents. To see the results SMS has found,
you simply need to locate the client within the SMS hierarchy. In our example, we have only one
site, so our resource should be fairly easy to find. Specifically, drill down to Site Database,
Collections, All Systems. After a fair bit of processing against the SQL Server database (perhaps,
as long as an hour), SMS should show you the known clients in the system, as Figure 3.26
Chapter 3
Figure 3.26: Inspect the All Systems collection to see all the systems in the site.
To inspect the hardware and software inventory, simply right-click the client, and select All
Tasks, Start Resource Explorer. Doing so will give you access to both the hardware and software
inventory. Figure 3.27 shows a slice of the hardware inventory, the network adapters.
Figure 3.27: Use the Resource Explorer to view the hardware in a client system.
Inspecting the software inventory is just as easy, as Figure 3.28 shows.
Chapter 3
Figure 3.28: Use the Resource Explorer to view the software inventory.
The software inventory is broken down by manufacturer, then each reported software product is
individually shown. Once you've finished inspecting the hardware and software inventory,
simply close the Resource Explorer window.
Remotely Controlling the Client
Anyone who has ever worked on a Help desk will tell you that it's easier to troubleshoot a
problem if you can actually see what's going wrong. SMS has an excellent remote help facility,
and it's very easy to use. The remote help feature offers useful several tools, including real-time
chat, file transfer, and a great remote control application.
You can access the remote tools in a method similar to how you start the Resource Explorer—
right-click the client, and select All Tasks, Start Remote Tools. When you do so, you'll be
prompted with the Remote Tools screen, which Figure 3.29 shows. The icons in Figure 3.29
have been annotated for discussion.
Chapter 3
Figure 3.29: The Remote Tools window with annotations.
Item 1: Remote control icon—Clicking this icon lets you take control of the client
machine and act as if you were sitting directly at the client’s keyboard. This feature is
most useful for workstations, but also helpful for servers. Win2K comes built-in with a
two-user terminal services client, but NT Server does not. This SMS option really bridges
the gap to ensure remote connectivity to servers you might not have hands-on access to.
To simulate Ctrl+Alt+Delete on the client, click the little Key icon in your viewer window. All NT
machines first require a reboot in order for the Key icon to work. Win2K machines do not require a
reboot for the key icon to work.
Item 2: Reboot machine icon—Clicking this icon results in a reboot of the machine.
Item 3: Chat icon—This icon enables a two-way real-time chat mechanism. This feature
can be useful if the problem workstation isn't near a phone and you want to communicate
with the end user.
Item 4: File transfer icon—This icon can be useful if you need to replace broken files or
transfer files from your machine to the client's machine.
Item 5: Remote execute icon—This icon gives the administrator the ability to run a
specific program on a client. For instance, if you wanted to manually kick off a virus
scan. The administrator needs to know the exact path and name of the executable (unless
it's in the path).
Items 6 through 11 are only available on non- NT based clients, such as Win9x:
Item 6: Windows memory icon—Shows the memory allocations on the client.
Item 7: Windows modules icon—Shows the drivers and libraries loaded on the client.
Chapter 3
Item 8: Windows tasks icon—Shows the tasks running on the client.
Item 9: CMOS icon—If the system can access the CMOS information, clicking this icon
displays the data provided from CMOS.
Item 10: ROM information icon—Shows all IRQs in use.
Item 11: DOS memory map icon—Shows which programs are loaded into the first
640KB of memory as well as the upper memory.
Item 12: Ping test icon—This icon allows for a quick speed test between your machine
and the target machine. This test is useful because not everyone uses TCP/IP, which
comes with a built-in ping. Therefore, this test can be used without TCP/IP, if necessary,
to determine the speed of the client.
By default, the users at the target machines will need to allow the administrator to perform the
desired action on the machine. The users are prompted with the dialog box that Figure 3.30
shows (or something similar):
Figure 3.30: Asking the client to allow an administrator to remotely control the client’s machine.
Users can change this behavior by manipulating the settings in the Remote Control applet in
Control Panel. However, you can also change this behavior by tinkering with the Remote Tools
Client Agent on the server. Remember, you set up the Remote Tools Client Agent back in the
“Installation Agents” section. You did this by drilling down into Site Database, Site Hierarchy,
{Site Name}, Site Settings, Client Agents, Remote Tools Client Agent. If you want to change the
behavior such that permissions are not required, simply select the Policy tab, which Figure 3.31
Chapter 3
Figure 3.31: You can force a policy down to your clients from the server.
If you want to ensure that you do not need permission, simply select the Do not ask for
permission option. Additionally, you might want to change the default settings the user
experiences while you take control over the machine. By default, there is both a visual indicator
and a beeping sound that happens when an administrator remotely controls a machine. Many
administrators choose to leave the visual indication on, but opt to turn off the sounds as it might
disturb others. Figure 3.32 shows the Notification tab on which you can control these settings.
Figure 3.32: Changing the default notification settings.
Chapter 3
In addition, you can change the clients’ ability to change these settings. To do so, select the
General tab, and select the Clients cannot change Policy or Notification Settings check box, as
Figure 3.33 shows.
Figure 3.33: You can disable clients’ ability to change policy and notification settings.
Understanding Collections
We've already explored the concept of collections a bit. A collection is a group of resources (that
is, any number of computers, users, and groups). You can use collections to explore a group of
resources or target a specific subset of your resources for software distribution. SMS software
distribution is, in general, more powerful than software distribution with just Win2K Group
Policies. The reason is that you're able to target SMS resources in a way that Group Policy
simply cannot.
The idea is to use the collected hardware and software inventory (stored in the SQL Server
database) and a target criteria that we want to match, and ask SQL Server to create a collection
based on that criteria. Once we have the collection, we can update it as new systems come along.
If the system meets the criteria—poof!—it’s automatically added to the collection, and hence,
automatically receives the software that we want it to get.
First, we’ll create a collection, and in the next section, we'll explore how to advertise a package
to the collection. There are three types of collections: predefined, direct, and query-based.
Predefined Collections
These are collections that come right out of the box. Indeed, you've already interfaced with one
collection—the All Systems collection—to manipulate that first machine with remote control
tools. There are a handful of useful predefined collections such as All Windows NT Systems and
All Windows NT Server Systems that can be handy when it comes time to roll out service packs
to specific machine types with specific OSs.
Chapter 3
Direct Collections
Direct collections let you create your own collection and manually populate it with the resources
you choose. SMS allows you to choose any type of resource: computer, user, or user group.
However, the particular discovery method for the object type must be enabled for the collection to
allow that object type. Specifically, for the examples thus far, we opted not to turn on the Windows NT
User Account Discovery or Windows NT User Group Discovery. Therefore, our collections technically
cannot contain either user or group accounts.
For instance, let's suppose we want to create a collection based on all the machines in our
environment created using Remote Installation Services (RIS). In our environment, we'll suppose
we've maintained a consistent machine naming convention with these machines (as RIS will do
automatically). Therefore, we'll create a collection that rounds up all the machines that have RIS
in the name, and call it a collection.
To create a collection of machines that have RIS in the name, simply right-click the Collections
heading, and select New, Collection. When you do so, you'll be prompted to enter some general
information about the collection, such as the name and a comment, as Figure 3.34 shows.
Figure 3.34: You can define your own collection.
When done, select the Membership Rules tab. On this tab, click the little computer icon with the
starburst on it. When you do, you'll be presented with the screen that Figure 3.35 shows.
Chapter 3
Figure 3.35: Click the highlighted icon to create a direct collection.
Click Next to continue. When you do, you'll have the ability to query for various attribute names,
as Figure 3.36 illustrates. For this example, select Client. For Value, select %RIS%, which will
match with any machine that has RIS in its name, such as RISMACHINE1, JONSRIS4 or
Figure 3.36: Enter the values for which you want to make a match.
You'll then be presented with the Collection Limiting screen; you may leave this screen blank,
and click Next. You'll then be presented with the Select Resources screen. Select the resources
Chapter 3
you want to add by adding a selecting the check box (or selecting Select All), then click Next. At
the end of the wizard, click Finish.
Back at the Membership Rules tab, you might notice a selection entitled Update this collection
on a schedule, which Figure 3.37 shows.
Figure 3.37: Be sure you understand how direct collections work.
For direct collections, like the one we just set up, selecting this option is a re-evaluation of the
direct members. This option can help expunge members if they no longer exist. If SMS doesn't
hear from a resource in 90 days, the resource is presumed to be gone. Therefore, when the next
evaluation of that collection (after a 90-day period) has elapsed, this feature will remove the item
from the collection.
Selecting this option doesn’t cause SMS to add new items to a direct collection. To do so, you must
use a query-based collection, which we explore in the next section.
Query-Based Collections
Query-based collections are a bit harder to set up, but have a bigger payoff. That is, this facility
can automatically query the SQL Server database for new matches, and add them to the
collection. For example, you could create a new collection for all machines that have at least
128MB of memory.
To create a query-based collection, right-click the Collections heading, and select New,
Collection. When you do so, you'll be prompted to enter some general information about the
collection, such as the name and a comment. For this example, enter
Machines with at least 128MB of Memory
in the Name field.
Then, click the icon that looks like a cylinder with a starburst next to it to open the Query Rule
Properties window, which Figure 3.38 shows.
Chapter 3
Figure 3.38: You can click the highlighted icon to create a new query rule.
In the Name text box, enter a description, such as Add machines with 128MB or more. Ensure
that System Resource in the Resource class drop-down list is selected. Then click Edit Query
Click the starburst icon, then select the Criteria tab to open the Criterion Properties page, which
Figure 3.39 shows. Click the starburst icon to start editing the query. Make sure that the Criterion
Type is set to Simple Value. Then, to populate the Where dialog box, click Select. Next, pull
down the Attribute Class, and select Memory. Pull down the Attribute, and select Total Physical
Memory (Kbytes). Enter 128000 for a Value, to represent 128MB.
Chapter 3
Figure 3.39: Enter values to make a match.
Click OK to finish. Click OK to leave the Criterion Properties page. Click OK to close the Query
Rules Properties window. Click OK to leave the Collection Properties page. Now, you should be
able to click the Collections you just created, and see the results of the queries, as Figure 3.40
Figure 3.40: Machines that meet the criteria are automatically added to the collection.
You might have noticed that there is no option to create a collection from a Win2K AD OU. If you want
to make a collection from a Win2K AD OU, you'll need to load a free add-on from Microsoft. You can
download two Active Directory/SMS Collection Synchronization Tools from the Downloads section at
Chapter 3
Advertising a Software Package to a Collection
You're ready to explore the last major SMS feature in this chapter—the ability to distribute
software to your collections. Indeed, most people think SMS's powerful software distribution
features lie here—in advertising—but that's not really true. The power is in the creation of
collections, which we just explored. In other words, you already did the hard stuff, and from here
it's smooth sailing.
Understanding the Distribution Lingo
Surfing late-night television can be an amazing experience. Let’s say you’re watching late-night
TV and your eyes fixate on a home shopping channel. The announcer comes on “Today we have
a great offer folks—two hamsters for the price of one. This offer is only good for those in the
914 area code!” You think for a moment—you’re in the 914 area code, and you’d LOVE two
hamsters. You call and place an order. After you place the order and a little time passes, a
package is delivered at your doorstep with a greeting card attached on the outside. You open the
greeting card first to find out how to open your new package. You want to make sure you do it
right. For example, the card might provide instructions such as “Open only on a flat surface” or
“Open while in an enclosed space.” Although this example might seem a little far fetched, it can
help you picture the difference between a package and a program.
Let’s equate the items in the example with SMS lingo:
The late-night home shopping channel is an advertisement.
The 914 area code is a collection.
The delivery person is the software distribution mechanism.
The package is a package.
The greeting card is a program.
SMS allows a single package to have multiple programs. This feature lets SMS administrators
design one package that provides multiple instructions for how to kick it off. For instance, you
might have an in-house application that requires Win95 machines to execute setup in the \win95
directory and NT machines to execute setup in the \winnt directory.
You could also send programs without any packages at all. This feature lets you send instructions
to clients to start a job for software already loaded on the client’s hard disk. For example, you
can simply tell your clients to run “defragment the disks” or “the virus scanner.”
What Can You Send?
SMS, first and foremost, is a delivery mechanism. Once the package is delivered with the
instructions for how to properly open the package, SMS's job is more or less done. At that point,
whatever you distribute needs to be smart enough to get itself installed.
SMS has endured through a long and glorious history. One holdover from the original SMS
legacy is a file type that SMS looks for called a PDF or Package Definition File. This PDF is not
to be confused with the new PDF files made popular by programs such as Adobe Acrobat. This
PDF file type is a set of instructions that describes a set of instructions for how a package is to be
placed. PDFs are usually used with SMS 1.0 through 1.2, though they can still be used in SMS
Chapter 3
2.0. SMS 2.0 also has its own file type that does the same thing as old-style PDFs. This new file
type is called an SMS file and has an .SMS extension.
So, SMS can assist in getting packages properly loaded if the packages come with their own
PDF or SMS file. The only problem is that packages usually don't come with their own PDF or
SMS file. There are a handful of off the shelf products that ship with PDF/SMS files, and they're
usually from Microsoft or a Microsoft partner. But, by and large, PDF/SMS files are hard to
come by.
However, with the advent of Win2K and Group Policy, many more manufacturers are heeding
Microsoft's recent request to repackage third-party applications as Windows Installer files, which
come with an .MSI extension. Additionally, some applications come from the developer as selfextracting executables. You'll find these typically downloaded from the Internet.
So, in general, SMS can deliver just about any file type you can throw at it. The only problem is
that there is where SMS's job ends—at the delivery phase. Your package needs to know how to
“unwrap” itself based on the program you deliver. In this example, we'll deliver a package using
an SMS file.
Distributing a PDF/SMS Package
One package you might want to automatically distribute around your environment is NT 4.0's
SP6a. It comes with a .PDF file for use with distributing with SMS (either 1.2 or 2.0).
To begin, simply copy the SP6a (with the NT4SP6A.PDF file) to a sharepoint. Then choose the
collection to which you want to distribute the software. In this case, the most appropriate
collection is All Windows NT 4.0 Workstations. Simply right-click Collection, and select All
Tasks, Distribute Software. When you do so, you'll be presented with the Distribute Software
Wizard, which Figure 3.41 shows. Click Next to access the Package screen.
Figure 3.41: Select the first option to use a PDF or SMS file.
Because we're using a PDF file, select the first option, and click Next. At the Package Definition
screen, you'll see a list of PDF files for other products. However, because you want to install
Chapter 3
SP6a to your NT 4.0 Workstations, you'll need to introduce the SP6a PDF file. Do so by clicking
Browse and selecting the PDF file, as Figure 3.42 shows.
Figure 3.42: After you browse to the PDF file, it will show up in the list.
Click Next to continue. You are presented with three options:
This package does not contain any files—This option is useful when you want to run an
executable that you know is already installed on the target computer. This option might
be useful to kick off an anti-virus application on a regular schedule.
Always obtain files from a source directory—This option is useful when you already
have source files copied to an existing directory and you want to save disk space. This
option is also useful if you have ready access to the files on CD-ROM and can simply
pop the disk in whenever you need to set up a new distribution point.
Create a compressed version of the source—This option is useful when you live in a
world of uncertain CD-ROMs. You know who you are—you put a CD-ROM on your
desk, turn around, and it's already vanished. Rather than hunting down the CD-ROM
every time you need a new distribution point, you can have SMS store a nice little
compressed copy on the site server.
You can specify on which local drive you would like SMS to store the compressed copy of the
software. (Sorry, but if you want a compressed copy stored on a remote server, you'll have to do that
yourself.) To specify the drive, go to Systems Management Server, Site Hierarchy, <site name>, Site
Settings, Component Configuration, and right-click Software Distribution. When you select Properties,
you'll see on the General tab the option to Set the compressed package storage location. You can't
specify the directory, only the drive letter.
For our purposes, select the Always obtain files from a source directory option, and click Next.
You are presented with the Source Directory screen, which Figure 3.43 shows. Here, you will
type in the path of the source files. You can choose straight paths or UNC paths. After you type
in the path of the source files, click Next.
Chapter 3
Figure 3.43: Select the source directory for the package.
The next screen is called Distribution Points. Recall that SMS clients always pull the files from
distribution points. As stated, by default, the first SMS site server you bring up in an
environment is burdened with a heavy load. One of those loads is its role as a distribution server.
For our testing purposes, this setup should be fine. However, in a real SMS environment, you
wouldn't generally have the site server actually be a distribution point.
For more information about how to relieve the site server from being a distribution point and how to
add distribution points, see the SMS built-in Help topic “Distribution Points."
Click an available distribution point, and select Next. At the Advertise a Program screen, click
the Program labeled Update x86 Windows NT Version 4.0, and click Next. At the Advertisement
Target screen, ensure that the proper collection is being targeted (that is, All Windows NT 4.0
Workstations), and click Next. At the Advertisement Name screen, you can inspect the default
name, change the name if you desire, and add a note. At the Advertise to Subcollections screen,
select the Advertise the program only to members of the specified collection check box, and click
Next. The Advertisement Schedule screen appears, as Figure 3.44 shows.
Chapter 3
Figure 3.44: You can set up the package to be available at a later date.
You can choose to schedule when this program becomes available for use. Perhaps you want to
modify the time to ensure that the program starts only after business hours or some other timesensitive period. Additionally, you can expire the package, which means that after a certain date,
it's no longer available. This feature can be helpful for programs such as virus definitions, which
are incremental, and you needn't require or desire for the user to be responsible to acquire the
latest version. Click Next when ready to go to the Assign Program screen, which Figure 3.45
Figure 3.45: You can force clients to receive the packages by assignment.
SMS has the power to “force” a resource to get the package you want. You can choose to stagger
the timing so that a program is Available at one time, say, right after being packaged, but
Chapter 3
Assigned in 15 days. This setting gives the users some time to perform the installation on their
own. If they do not, you can ensure that the package is sent to them. Click Next when ready to
get to the final screen, which Figure 3.46 shows.
Figure 3.46: Click Finish to kick off the software distribution process.
How Clients Get Advertised Packages
Once packages and programs are created and the programs are advertised, the clients may run the
advertised program as desired. Once you enable Advertised Programs Client Agent (as we
discussed earlier), the icons that Figure 3.47 shows automatically appear in the users’ Control
Figure 3.47: Additional SMS Control Panel icons.
Clients may change how they are notified about available advertisements through the Advertised
Programs Monitor icon. Once selected, they may choose the notification options that Figure 3.48
Chapter 3
Figure 3.48: Clients can change the software distribution options if they desire.
Clients cannot change these options if the Clients cannot change agent settings check box is
selected on the SMS server in the Advertised Programs Client Agent settings.
Clients may choose to manually kick off the advertisements through the Advertised Programs
icon in Control Panel.
What's New for the Next Version of SMS?
Internally at Microsoft, the next version of SMS is called Topaz. This name is to keep with the
gemstone theme that runs through the SMS product line. SMS 1.0 was codenamed Diamond,
SMS 2.0 was codenamed Opal. However, when it finally hits the streets, the next version will
still be called SMS. Perhaps it will be called SMS 3.0 or have an alternative designation such as
SMS 2002, SMS .NET, or SMS XP. The official name has not yet been announced. It's
scheduled to be released in the summer of 2002.
There are three big differences between SMS 2.0 and the next version. The first major difference
is a better integration of AD support. Today, AD can be used with SMS 2.0 with a downloadable
add-on tool that I previously mentioned. The next version of SMS will work in a similar method.
That is, it will not directly interact with AD; rather, the OUs will be evaluated and converted for
the SMS database. The reason that this setup is advantageous is for SMS (and AD) performance
reasons. The downside, however, is that there might be a lag time between when an AD OU is
created and when SMS sees that new OU. You can control some of the update timings and
restrict which OUs are to be imported, which can speed things up.
The second major difference is the new mobile support. When SMS 2.0 users on laptops are sent
a package, it's an all-or-nothing proposition. If the connection gets dropped, the agent tries to
keep getting the file until the entire thing is received. The next version of SMS has a new
function called checkpoint restart, which automatically restarts software downloads at the point
of failure. Additionally, the new SMS client will support bandwidth throttling. That means that
the client will pull software in the background—when you're not using the connection for other
things, like surfing the Web.
Chapter 3
The third major new piece is the new software metering components. They have all been
completely rewritten for better integration into SMS and a better experience for administrators.
There are a lot of other minor improvements, such as a better Microsoft Management Console
(MMC) snap-in, and enhancements to speed things up. Additionally, the add-on components for
SMS 2.0 currently downloadable from Microsoft's Web site are already integrated for the next
version of SMS. So, essentially, if you learn SMS 2.0, you'll be well prepared for the next
version of SMS.
In this chapter, we learned about most of the major SMS features: hardware and software
Inventory, remote control tools, and software distribution. We learned how SMS is architected,
and got to install our first site and distribute our first packages using PDF and SMS files.
In the next chapter, we'll take a break from desktops, servers, and specific applications and focus
on a serious issue—backups. It's a jungle out there with technologies and vocabulary all its own.
And you'll need to be familiar with this information. After that, however, we'll return to SMS,
and explore some of its minor but not unimportant features as well as get to know Microsoft's
newest product for helping ferret out problems in the Enterprise—MOM.
Chapter 3
Copyright Statement
© 2002 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtimepublishers.com, Inc. (the “Materials”) and this site and any such Materials are
protected by international copyright and trademark laws.
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web
site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtimepublishers.com, please contact us via e-mail at
[email protected]
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF