Sie sind auf Seite 1von 676

Concepts, Planning, and

Deployment Guide

Microsoft Systems
®

Management Server 2003


Scalable Management for Windows-based Systems

M
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other


intellectual property rights covering subject matter in this document. Except as expressly
provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.

 1994-2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, Intellimirror, Microsoft Press,
Win32, and Windows Server are either registered trademarks or trademarks of Microsoft
Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.

Document No. X09-75009


Printed in the United States of America.
Contents

PART 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Technical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Online Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Product Documentation Available for SMS . . . . . . . . . . . . . . . . . . . . . . . xviii
Keeping Your Technical Knowledge Current . . . . . . . . . . . . . . . . . . . . . . xviii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
System Requirements and Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . xix
Requirements for SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Unsupported Operating Systems and Features . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
CHAPTER 1 Introducing Systems Management Server 2003 . . . . . . . . . . . . . . . . . 1
SMS 2003 Features and Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Collections and Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Hardware and Software Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Software Update Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Tools for Managing Software Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Enhancements to Software Update Management . . . . . . . . . . . . . . . . . . . 8
Software Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Remote Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
SMS Site Maintenance and Upgrade Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Product Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Status System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
SMS Administrator Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
iv Contents

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Standard Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Advanced Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Site Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Client Discovery and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Legacy Client Installation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Advanced Client Installation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Site System Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
PART 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
CHAPTER 2 Understanding SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Site Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Parent-Child Site Relationships and the SMS Hierarchy . . . . . . . . . . . . . 25
Site Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Site Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Roaming and Roaming Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Hierarchy Modeling Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Flat vs. Deep Hierarchy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Building the SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Site Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Senders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
CHAPTER 3 Understanding SMS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Collections and Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Hardware and Software Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Software Update Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Software Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Remote Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Product Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Status System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Contents v

Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


Network Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Integrating Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
IT Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
CHAPTER 4 Understanding SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
How Clients Find and Use Site Systems and Domain Controllers . . . . . . . . 104
Client Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Discovering Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Windows User Account Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Windows User Group Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Heartbeat Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Active Directory System Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Active Directory User Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Active Directory System Group Discovery . . . . . . . . . . . . . . . . . . . . . . . . 121
Installing SMS Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Client Software Installation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 122
Assigning Clients to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Installing SMS Client Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Client Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
User Control of Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Determining Client Version and Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
CHAPTER 5 Understanding SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
SMS Security Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Operating System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
SQL Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Windows Management Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Internet Information Services Security . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
vi Contents

SMS Security Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143


SMS Advanced Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
SMS Standard Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
SMS Accounts and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Complete List of SMS Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Common Server Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Common Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
SMS Database Accounts and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Managing Accounts Through Site Setup and Site Reset . . . . . . . . . . . . 166
SMS Object Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
The SMS Object Security Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Changing SMS Object Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
SMS Feature Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
SMS Query and Report Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
SMS Remote Tools Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Software Distribution Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Inventory Collection Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
CHAPTER 6 Understanding Interoperability with SMS 2.0 . . . . . . . . . . . . . . . . . 193
Administering a Mixed-Version Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Interoperability of SMS 2.0 Features with SMS 2003 Features . . . . . . . . . 198
PART 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
CHAPTER 7 The Pre-Planning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Step 1 Understand the Methodology and the Risks . . . . . . . . . . . . . . . . . . . . . 213
The Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Step 2 Analyze Your Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Previous Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Geographic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Client Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Domain Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Active Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Server Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
IT Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Contents vii

Step 3 Analyze Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232


Identify Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Assessing Time and Budget Allotments . . . . . . . . . . . . . . . . . . . . . . . . . 234
Step 4 Assemble the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Occupation Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Assigning Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Support Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Step 5 Begin Assembling the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Step 6 Learn SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Groups to Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Training Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Step 7 Establish Test Lab Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
CHAPTER 8 Designing Your SMS Sites and Hierarchy . . . . . . . . . . . . . . . . . . . . . 247
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Designing SMS Sites and the SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Business and Technical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Business Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Technical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
SMS Site and Hierarchy Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Planning Site Boundaries and Roaming Boundaries . . . . . . . . . . . . . . . 256
Determining the Locations and Types of Site Servers . . . . . . . . . . . . . . 264
Assigning Site System Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Advanced Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Advantages of Multiple Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Multilanguage Site Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Upgrade and Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Domain Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Active Directory Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Reviewing and Testing the Design in the Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Changes to Hierarchy Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Test Lab Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Minimum Recommended Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 283
Standard Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Duplicating Network Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Site Design Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Sample Design Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
viii Contents

CHAPTER 9 Capacity Planning for SMS Component Servers . . . . . . . . . . . . . . . 287


Introduction to Modeling for Sizing and Capacity Planning . . . . . . . . . . . . . . . . 289
Capacity Planning Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . 290
Capacity Planning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Modeling Principles for Sizing and Capacity Planning . . . . . . . . . . . . . . 292
Performance and Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Monitoring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
SMS Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
SMS Activities That Affect SMS Server Performance . . . . . . . . . . . . . . . . . . . . . 299
Server Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Sizing SMS Component Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Setting Expectations and Service Level Agreements . . . . . . . . . . . . . . . 309
Methods and Formulas Used to Determine Server Capacity . . . . . . . . . 309
Determining Site Server Hardware Requirements . . . . . . . . . . . . . . . . . 313
CHAPTER 10 Planning Your SMS Deployment and Configuration . . . . . . . . . . . 325
Strategies for Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
High Level Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Key Elements of a Successful Deployment . . . . . . . . . . . . . . . . . . . . . . . 327
Sample Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Site Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Hardware and Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 334
Active Directory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
SMS Site Server Deployment Considerations . . . . . . . . . . . . . . . . . . . . . 338
SMS Site Database Server Considerations . . . . . . . . . . . . . . . . . . . . . . . 341
SMS Administrator Console and Related Tools . . . . . . . . . . . . . . . . . . . 342
Setup Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Domain and Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
NetBIOS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Site Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Site Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Configuring an SMS Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Configuring an SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Configuring Site Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Attaching SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Client Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Determining Which Client Type to Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Contents ix

Developing Strategies for Discovery and Client Installation . . . . . . . . . . . . . 364


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Choosing a Discovery Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Controlling Discovery and Client Installation . . . . . . . . . . . . . . . . . . . . . . 372
Deploying SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Assigning Clients to SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
The Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Understanding the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Creating the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Running the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Using Performance Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Using Remote Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Analyzing the Design and Making Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 392
SMS Hierarchy Design Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Burst and Recovery Effects on Design . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Total Processing Time and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Hardware Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Software Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Dismantling the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
CHAPTER 11 Planning an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Preparing to Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Upgrade Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Reconsider SMS Objectives During Upgrade Planning . . . . . . . . . . . . . 405
Determine the Effect of the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
In-Place Hierarchy Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Overnight Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Phased-site Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Side-By-Side Hierarchy Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Using a Transition Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Restricting Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Deciding When to Upgrade a Flat Hierarchy . . . . . . . . . . . . . . . . . . . . . . 416
Upgrading Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Replacing Secondary Sites with Protected Distribution Points . . . . . . . 417
Replacing Multisite Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Upgrading Clients by Attrition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Finalizing Your Upgrade Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
x Contents

Post-upgrade Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420


Unsupported SMS Features and Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 420
SMS 2003 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
CHAPTER 12 Planning Your SMS Security Strategy . . . . . . . . . . . . . . . . . . . . . . . 425
SMS Security Planning Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
SMS Security Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
General SMS Security Planning Considerations . . . . . . . . . . . . . . . . . . . 429
Security Considerations for Site and Hierarchy Design . . . . . . . . . . . . . 430
Security Considerations for Planning Setup . . . . . . . . . . . . . . . . . . . . . . 431
Planning SMS Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Using Optional Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
SMS Security Account Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Planning for SMS Account Lifecycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Minimizing the Number of Accounts SMS Uses . . . . . . . . . . . . . . . . . . . 442
Creating or Modifying SMS Accounts and Groups . . . . . . . . . . . . . . . . . 444
Planning SMS Object Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Planning Collection Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Planning Object Security for Objects Other Than Collections . . . . . . . . 454
Planning SMS Feature Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Planning to Use SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
SMS Security Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Tightening SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Operating System Security Best Practices . . . . . . . . . . . . . . . . . . . . . . . 458
Monitoring and Auditing SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Advanced Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Testing SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
CHAPTER 13 Planning for Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 463
Overview of Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Backing Up and Recovering Throughout the SMS Hierarchy . . . . . . . . . . . . 467
The Impact of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Minimizing the Risk of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Minimizing the Impact of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Planning for Backup and Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Plan for Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Plan for Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Develop a Backup and Archive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Document the Backup and Archive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 479
Contents xi

Planning to Simplify the Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479


PART 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
CHAPTER 14 Upgrading to SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Performing Site Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Preparing a Site for Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Upgrading Primary Site Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Installing SMS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Upgrading Secondary Site Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Secondary Site Upgrade Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Performing Post-Upgrade Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Software Update Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
CHAPTER 15 Deploying and Configuring SMS Sites . . . . . . . . . . . . . . . . . . . . . . 505
Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Security Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Setup Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
SQL Server Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
SQL Server Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Starting the Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Running Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Running an Unattended Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Installing a Primary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Express Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Custom Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Installing a Secondary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Installing a Secondary Site Using SMS Setup . . . . . . . . . . . . . . . . . . . . . . . . 523
Installing a Secondary Site Using the SMS Administrator Console . . . . . . . 524
Installing the SMS Administrator Console and Related Tools . . . . . . . . . . . . . . 526
Configuring Your SMS Sites and Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Configuring a Single Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Configuring a Site Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Extending the Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Creating SMS Containers in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 542
CHAPTER 16 Using the SMS Administrator Console . . . . . . . . . . . . . . . . . . . . . . 543
SMS Administrator Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Supporting Different Versions of SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Understanding the Console Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
xii Contents

Exploring the Console Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546


Viewing Items in the Details Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Using the SMS Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Displaying the Action and Shortcut Menus . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Viewing and Modifying Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Viewing Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Using the Import and Export Object Wizards . . . . . . . . . . . . . . . . . . . . . . . . . 549
Starting SMS Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
SMS and Microsoft Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Console Taskpads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Export List Views to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Print Items in the Details Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Creating Custom Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
CHAPTER 17 Discovering Resources and Deploying Clients . . . . . . . . . . . . . . . 555
Enabling and Configuring Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Discovery Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Discovery Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Heartbeat Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Windows User Account Discovery and Windows User Group Discovery . . . 561
Active Directory Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Installing and Configuring SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Installing the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Using Advanced Client Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Automated Installation by Using the SMS Administrator Console . . . . . 571
Initiating a Program File at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Using Computer Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Installing the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Automated Installation by Using the SMS Administrator Console . . . . . 580
Initiating a Program File at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Installing Clients with Insufficient Security Credentials . . . . . . . . . . . . . . . . 583
Assigning SMS Clients to an SMS Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Assigning the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Automatic Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Manual Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Removing Advanced Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 586
Assigning the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Contents xiii

Legacy Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586


Removing Legacy Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Upgrading SMS Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Upgrading to the SMS 2003 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Upgrading to the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Upgrading to the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Updating an SMS 2003 Client to a Newer Version . . . . . . . . . . . . . . . . . . . . 591
Updating the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Updating the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Removing and Repairing SMS Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Removing the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Removing the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Automatic Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Manual Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Repairing SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
APPENDIX A Accessibility for People with Disabilities . . . . . . . . . . . . . . . . . . . . 597
SMS 2003 Accessibility Features and Options . . . . . . . . . . . . . . . . . . . . . . . . . . 598
SMS Help Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
MMC Navigation Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
MMC Navigation Mouse Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
MMC Main Window Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
MMC Console Window Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . 600
SMS Administrator Console Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . 601
Accessibility in Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Windows XP Professional and Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Windows 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Windows 95 and Windows NT Workstation 4.0 . . . . . . . . . . . . . . . . . . . 602
Adjusting Microsoft Products for People with Accessibility Needs . . . . . . . . . . . 602
Assistive Technology Products for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Microsoft Documentation in Alternative Formats . . . . . . . . . . . . . . . . . . . . . . . . 604
Customer Service for People Who Are Deaf or Hard-of-Hearing . . . . . . . . . . . . . 605
Getting More Accessibility Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
TECHNICAL SUPPORT OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
P A R T 1

Introduction

This part of the Microsoft® Systems Management Server 2003 Concepts, Planning, and
Deployment Guide provides an overview of the information contained in this guide, lists other
resources that you can use to learn more about Systems Management Server 2003, and introduces
features that are documented in this guide.
Getting Started

Welcome to Microsoft® Systems Management Server (SMS) 2003, a Windows®-based product


designed to make it easier for your organization to manage, support, and maintain a distributed
network of computer resources.
The following sections will familiarize you with the wide range of technical information about
SMS. With this information, you can plan your SMS deployment, understand the features SMS
offers, and understand how you can use those features to benefit your organization.

Technical Resources
SMS includes comprehensive product documentation and other technical resources that help you
deploy and use SMS.

Online Library
All the information you need for deploying and using SMS is provided in the SMS Online
Library. The Online Library includes the following:
u An electronic version of the Microsoft Systems Management Server 2003 Concepts,
Planning, and Deployment Guide.
u Information about how to order printed books for SMS, including the Microsoft Systems
Management Server 2003 Concepts, Planning, and Deployment Guide and the Microsoft
Systems Management Server 2003 Operations Guide.
u Information about where to find electronic versions of the Microsoft Systems Management
Server 2003 Concepts, Planning, and Deployment Guide and the Microsoft Systems
Management Server Operations Guide on the Web.
u SMS Administrator Help, which provides information about how to use the SMS
Administrator console to manage your sites.
u Release notes, which contain critical information about SMS.
u Links to the SMS Web site at http://www.microsoft.com/smserver/default.asp. In this site,
you can find SMS-related information, such as technical papers, product news, and software
updates. The SMS Web site also provides specific information about how to use SMS with
other Microsoft products, such as Microsoft Windows XP and Microsoft Office XP.
xviii Getting Started

To run the SMS Online Library


u On the Start menu, point to Programs, point to Systems Management Server, and then
click SMS Online Library.
– or –
In the SMS Administrator console, right-click SMS Online Library, and then click Run
Online Library.

Product Documentation Available for SMS


Before you start using SMS, you should read the following books to become familiar with the
product.
Table 0.1 SMS Books
Book Description
Microsoft Systems Management Server 2003 This book contains valuable information about
Concepts, Planning, and Deployment Guide planning for deploying SMS in your organization,
important SMS concepts, and directions for
installing SMS and upgrading from previous
versions. This book is key to understanding SMS.
Microsoft Systems Management Server 2003 This book provides information about configuring
Operations Guide and using SMS.

These books are available in several different formats:


u Administrator Help on the product CD (the Microsoft Systems Management Server 2003
Concepts, Planning, and Deployment Guide only)
u PDF files that can be downloaded from the Web
u Searchable content on Microsoft TechNet
For more information about accessing these resources, see information about the Online Library
in the previous section.
Administrator Help is also provided for all SMS features, including the SMS Administrator
console. To access Administrator Help in the SMS Administrator console, press F1, or right-
click any item and click Help.

Keeping Your Technical Knowledge Current


To help you stay current with the latest information about SMS, the SMS product documentation
and other helpful resources will be updated on a regular basis on the Web after the initial release
of SMS. For example, you will be able to download updated troubleshooting information from
the SMS Web site that reflects new knowledge of the product gained through real-world
experience since the product’s initial release.
System Requirements and Supported Platforms xix

You should regularly check the SMS Web site at


http://www.microsoft.com/smserver/techinfo/default.asp for updates to important technical
references and product documentation that help you stay informed about SMS.

Document Conventions
The following conventional terms, text formats, and symbols are used throughout this book.
Table 0.2 Document Conventions
Convention Description
Bold Indicates the actual commands, words, or characters that you enter in a dialog box
or at the command prompt.
Bold also indicates named user interface elements (such as the Program
Properties dialog box).
Italic Indicates a placeholder for information or parameters that you must provide. For
example, if the procedure asks you to type file name, you must type the program
name of the file.
Italic typeface also indicates new terms and the titles of other resources in the
SMS documentation set.
ALL UPPERCASE Indicates an acronym, key, or macro name. You can use lowercase letters when
you type directory names or file names in a dialog box or at the indicated
command prompt.
Monospace Represents examples of screen text or entries that you might type at the command
line or in initialization files.
Indicates a procedure.
u Indicates an unordered list of related information that is not a procedure.

System Requirements and Supported


Platforms
This section describes system requirements and supported platforms for SMS site servers, site
systems, and clients.
If you are upgrading from a previous version of SMS, you must be running SMS 2.0 Service
Pack 4 or later. Also, SMS 2.0 sites that report to the upgraded site must be running SMS 2.0 SP4
or later before the parent site is upgraded to SMS 2003. For more information about upgrading,
see Chapter 11, “Planning an Upgrade,” and Chapter 14, “Upgrading to SMS 2003.”
Updates to the information in this section are available in the SMS 2003 release notes and on the
Systems Management Server Web site at http://www.microsoft.com/smserver/default.asp.
xx Getting Started

Requirements for Site Servers and Other Site Systems


This section provides tables and discussions about supported platforms for site system roles and
requirements for site servers and the SMS Administrator console.
To install SMS, you need at least one computer to set up as a primary site server. You can assign
other site system roles later, as required. The requirements for your site server vary according to
the size and configuration of your site.
Supported platforms and prerequisites for site system roles
In SMS, a site system is a server or a share that provides functionality to the SMS site. The SMS
site server and site system roles must be installed on computers running one of the following
operating systems:
u Windows 2000 Server
u Windows 2000 Advanced Server
u Windows 2000 Datacenter Server
u Windows Server™ 2003, Standard Edition
u Windows Server 2003, Datacenter Edition
u Windows Server 2003, Enterprise Edition
All Windows 2000 platforms require SP2 or later.
Table 0.3 lists the prerequisites for setting up distribution points, management points, reporting
points, and server locator points.
Table 0.3 Prerequisites for Site Systems
Site system Prerequisite
Client access point To be a client access point (CAP), the site system
that you want to configure as a CAP must have at
least one NTFS partition available. SMS 2003 does
not support CAPs on non-NTFS partitions.
Distribution point To use the Background Intelligent Transfer Service
(BITS), the site server and distribution point must
have Microsoft Internet Information Services (IIS)
installed and enabled. For more information, see
Chapter 3, “Understanding Features.”
Management point To be a management point, the system must have
IIS installed and enabled, and Windows 2000 SP3.

(continued)
System Requirements and Supported Platforms xxi

Table 0.3 Prerequisites for Site Systems (continued)


Site system Prerequisite
Reporting point To be a reporting point, the site system server must
have IIS installed and enabled.
Microsoft Internet Explorer 5.01 SP2 or later must
be installed on any server or client that uses Report
Viewer.
To use graphs in the reports, Office Web
Components (Microsoft Office 2000 SP2 or
Microsoft Office XP) must be installed.
Server locator point To be a server locator point, the site system server
must have IIS installed and enabled.

Requirements for Site Servers and the SMS Administrator Console


The minimum system requirements for running an SMS site server are:
u A computer with an x86-based or later processor.
u Microsoft SQL Server™ 7.0 SP3 or later (required for the primary site server in standard
security mode).
u Microsoft SQL Server 2000 SP3 or later (required for the primary site server in advanced
security mode).
Table 0.4 Requirements for SMS Site Servers
Remote SMS
Operating Administrator Primary Secondary SQL Server SQL Server Other SMS
system console site site 7.0 2000 site system
Windows 2000 ;
Professional,
SP2 or later
Windows 2000 ; ; ; ; ; ;
Terminal Server,
SP2 or later
Windows 2000 ; ; ; ; ; ;
Server, SP2 or
later
Windows 2000 ; ; ; ; ; ;
Advanced Server,
SP2 or later

(continued)
xxii Getting Started

Table 0.4 Requirements for SMS Site Servers (continued)


Remote SMS
Operating Administrator Primary Secondary SQL Server SQL Server Other SMS
system console site site 7.0 2000 site system
Windows 2000 ; ; ; ; ; ;
Datacenter
Server, SP2 or
later
Windows XP ;
Professional
Windows ; ; ; ; ;
Server 2003,
Standard Edition
Windows ; ; ; ; ;
Server 2003,
Enterprise
Edition
Windows ; ; ; ; ;
Server 2003,
Datacenter
Edition

1. An SMS Administrator console can run on a server running Terminal Server, the Terminal Server feature, or through a

Terminal Server session.

Note
A remote SMS Administrator console requires 150 MB of hard disk space.

Site licensing and SQL Server licensing


For information about the SMS and SQL Server licensing requirements, see the SMS end-user
license agreement that accompanies your server running SMS.
You can also find this information in the Systems Management Server Web site at
http://www.microsoft.com/smserver/howtobuy/default.asp.
Support for specialized storage technology
SMS supports specialized technologies such as Network Attached Storage, Storage Area
Networks, and System Area Networks. SMS works with the hardware that is certified on the
Windows hardware compatibility list for the supported version of the operating system on which
the SMS component is installed.
System Requirements and Supported Platforms xxiii

SMS server-side roles require NTFS file system formatted partitions so that directory and file
permissions can be set. SMS site systems running on separate computers cannot share a logical
partition on any storage device, but each site system uses a separate logical partition on a
physical partition of a shared storage device.
For more information, see Microsoft Knowledge Base articles 260176, 264135, and 307813.

Requirements for SMS Clients


The following table shows the minimum hard disk space required for clients running each of the
supported SMS client types.

Note
SMS requires that all client computers be a member of a domain.
Computers located in a workgroup are not supported.

Table 0.5 Hard Disk Space Requirements for SMS 2003 Clients
SMS 2003 client type Installation requirement Usage requirement
Legacy Client 40 MB of available hard disk 40 MB of available hard disk
space space
Advanced Client 25 MB of available hard disk 25 MB of available hard disk
space space (275 MB recommended)

The following table shows the operating systems that are required for clients running each of the
supported SMS client types.

Note
All SMS 2003 Legacy Clients require Microsoft Internet Explorer 5.0 or later.

Table 0.6 Operating System Requirements for SMS 2003 Clients


Operating system Legacy Client Advanced Client
Windows 98, Windows 98 Second Edition ;
Windows NT® 4.0 Workstation, SP6a or later ;
Windows NT 4.0 Server, SP6a or later ;
Windows NT Server 4.0, Terminal Server Edition, ;
SP6a or later
Windows 2000 Professional ; ;
Windows 2000 Server ; ;

(continued)
xxiv Getting Started

Table 0.6 Operating System Requirements for SMS 2003 Clients (continued)
Operating system Legacy Client Advanced Client
Windows 2000 Advanced Server ; ;
Windows 2000 Datacenter Server ; ;
Windows XP Professional ; ;
Windows Server 2003, Web Edition ; ;
Windows Server 2003, Standard Edition ; ;
Windows Server 2003, Enterprise Edition ; ;
Windows Server 2003, Datacenter Edition ; ;

Unsupported Operating Systems and


Features
Computers running the operating systems and SQL Server versions listed in Table 0.7 are not
supported. This list is a summary and might not include last minute changes to the product. For
more information, see the release notes, which contain the most current information about SMS.
Table 0.7 SMS 2003 Unsupported Operating Systems and Features
Item Description
Operating System MS-DOS® computer
Microsoft Windows 3.1 and Windows 3.11
Microsoft Windows 95
Windows NT 4.0 SP5 (or earlier)
Microsoft Windows Millennium Edition
Microsoft Windows XP Home Edition
WinPE (Windows Preinstall)
Macintosh operating systems
Novell NetWare
Microsoft Small Business Server
Alpha-based systems
SQL Server SQL Server 7.0 SP2 and earlier
Intel IA64-based computers running SQL Server

(continued)
Unsupported Operating Systems and Features xxv

Table 0.7 SMS 2003 Unsupported Operating Systems and Features (continued)
Item Description
Other Windows Management Instrumentation version 1.10.698
Netscape browser
IP version 6
Windows XP Professional Fast User Switching
Computers in workgroups
SNMP Event to Trap Translator SMS 2003 does not support the SNMP Event to Trap Translator. Note
that this feature is natively supported in Windows 2000 and later
operating systems.

Note
SMS 2003 does not support managing more than one operating system on
a single computer. If there is more than one operating system on a
computer, configure the discovery and installation methods that are used, to
ensure that the SMS client is installed only on the operating system that
must be managed.
C H A P T E R 1

Introducing Systems
Management Server 2003

Information Technology (IT) administrators have used Microsoft® Systems Management Server
(SMS) 2003 for many years to manage client computers and servers that are running Microsoft
Windows® operating systems within their organizations. SMS has helped IT administrators
contain the cost of managing heavily distributed systems by keeping the cost of ownership low
while allowing the number of deployed computers and installed applications to increase.
Managing client computers within your organization includes tasks like troubleshooting
individual computers, software asset management, and analyzing network problems. These tasks
are often complex and time consuming. Using your resources effectively is an important part of
troubleshooting computer and network problems. SMS provides a scalable change and
configuration solution for centrally managing client computers and servers, which increases
productivity and improves service quality to your organization.
SMS 2003 meets the technical and management challenges of managing computing systems by
using a distributed and scalable architecture, and by enhanced use of the Microsoft Management
Console (MMC). SMS 2003 takes advantage of Windows 2000 Server Active Directory
directory service technology, which further simplifies the process of managing clients.
SMS 2003 addresses the following key issues that IT administrators face in managing distributed
computing environments:
u Managing computers that roam from one location to another and connect to the network
from different geographical locations
u Tracking deployment and use of software assets, and using this information to plan software
procurement and licensing
u Providing IT administrators and management access to data accumulated by SMS
u Providing scalable hardware and software management to the growing population of
computers running Windows operating systems
u Managing security on computers running Windows operating systems while expending a
minimum level of administrative overhead

In This Chapter
u SMS 2003 Features and Enhancements
2 Chapter 1 Introducing Systems Management Server 2003

SMS 2003 Features and


Enhancements
SMS 2003 provides the following key features and enhancements:
u Collections and queries
u Hardware and software inventory
u Software distribution
u Software update management
u Software metering
u Remote tools
u SMS site maintenance and upgrade tools
u Reporting
u Product compliance
u Status system
u SMS Administrator console
u Advanced Client
u Security
u Active Directory
u Site installation
u Client discovery and installation
u Site configuration
u Site systems roles
u Backup and recovery

Collections and Queries


Each SMS primary site contains a database of collected SMS data. You can run queries against
the database to retrieve specific data according to the query criteria. You can select queries from
those that are provided by SMS, or you can write them separately.
SMS 2003 Features and Enhancements 3

SMS manages resources such as client computers and software. Logical groups of SMS
resources having common attributes are called collections. Collections are defined by queries that
are refreshed at intervals that an administrator specifies. A resource that no longer meets the
collection criteria is removed from the collection. Conversely, a resource that meets the
collection criteria is added to the collection. SMS features can operate on clients only if they are
members of a collection. By default, all SMS clients are members of the All Systems collection.
For more information, see Chapter 3, “Understanding SMS Features.”

Hardware and Software Inventory


SMS performs hardware and software inventories on SMS client computers. You can run a wide
variety of reports against the resulting data, so you can plan upgrades, track hardware and
software assets, or check software license compliance.
Before you deploy a new software package, you can build a report that shows how many
destination computers have the required memory and disk space to support the software package
that is planned for distribution. This allows you to upgrade noncompliant systems before the
deployment begins, ensuring a higher overall project success rate.
You can customize which of the more than 700 classes of data should be recorded when you
gather information during hardware and software inventory collection. This allows you to select
the appropriate balance between performance and inventory depth for your organization.
SMS 2003 also gives you more control over which software files should be scanned. Software
inventory can scan specific directories and drives, using environment variables to optimize the
data-gathering process.
The following table summarizes the core SMS 2003 hardware and software inventory features.
Table 1.1 SMS 2003 Hardware and Software Inventory Features
Feature Description
Windows Management SMS has been designed to use WMI (which is built into the Windows
Instrumentation (WMI)-based operating system) to collect inventory data. WMI is based on the
hardware inventory Common Information Model (CIM) standard. SMS has access to data
from many sources, including the Win32® API, Simple Network
Management Protocol (SNMP), and Desktop Management Interface
(DMI), which provides administrators with a broad collection of
inventory and configuration data.
Support for WMI 1.5 and later WMI enhancements are included in WMI 1.5 (which is installed and
used by SMS 2003). These enhancements allow improved client-side
performance during hardware and software inventory.
Discovery-based software SMS examines every configured file type for version and developer
inventory information rather than relying on file-to-product mapping databases.

(continued)
4 Chapter 1 Introducing Systems Management Server 2003

Table 1.1 SMS 2003 Hardware and Software Inventory Features (continued)
Feature Description
Granular file inventory search SMS 2003 can be configured to retrieve only the necessary asset
discovery. This is done with wild cards, environment variables, and file
properties to control software inventory searches more effectively.
Other options allow for compressed and encrypted files to be skipped.
Add or Remove Programs search Installed software registered in Add or Remove Programs or installed
by the Windows Installer service is inventoried and reported as part of
normal hardware and software inventory collection. This is a
checkpoint against file-based inventory for accurate descriptions of
installed applications (not just the files present on a computer).

Software Distribution
SMS significantly reduces the time and complexity of maintaining and upgrading software for
organizations with distributed networks. You can upgrade and configure each computer from a
central location or from multiple locations. You can schedule individual software files or
software programs for distribution to specific computers. You can also initiate unattended
software installations to selected computers.
Software installation packages can come ready-to-install from Windows Installer or can be
created with the SMS Installer, which is available by download and is not included with the
SMS 2003 product. For more information, see Chapter 7, “Creating Software Installation
Packages with SMS Installer,” in the Microsoft Systems Management Server 2003
Operations Guide.
The following table summarizes important SMS 2003 software distribution features.
Table 1.2 SMS 2003 Software Distribution Features
Feature Description
Rich distribution Software distribution can be directed to computers based on collected
information including network and hardware configuration, group
membership, and software installation status.
Dynamic distribution If an SMS client computer is added to a group, software is
automatically sent to the client according to predefined administrative
settings for that group. Likewise, new computers matching predefined
destination attributes (such as Internet Protocol (IP) subnet or installed
video card) automatically receive specified packages or driver updates.
Courier Sender Courier Sender allows software to be sent between SMS sites by CD or
other media, rather than across the network. This is particularly useful
in situations where the available network bandwidth is low or too
expensive to use for the delivery of large packages.

(continued)
SMS 2003 Features and Enhancements 5

Table 1.2 SMS 2003 Software Distribution Features (continued)


Feature Description
Software program removal SMS can be used to remove deployed software and applications from
particular computers or groups.
Use of BITS technology Software distribution uses Background Intelligent Transfer Service
(BITS) technology, which can transfer files from distribution points that
are BITS-enabled. Advanced Clients use BITS technology to
automatically detect the client network connection capacity and adjust
transfer rates efficiently. This is supported only on clients running
Windows 2000, Windows XP Professional, and Windows Server™ 2003
family operating systems.
Checkpoint restarts A checkpoint is set if a file download is interrupted. The file download
is resumed and proceeds from the checkpoint rather than restarting
the download from the beginning. On reconnection, any partial
downloads to clients continue where they left off; there is no need to
restart transmissions because of a disconnected session.
Roaming boundaries Roaming boundaries enable SMS to provide more efficient software
distribution and client management for Advanced Clients that roam to
other sites. Advanced Clients use roaming boundaries to find the
nearest distribution point. Roaming boundaries are also used in the
site assignment of Advanced Clients.
Download and run Administrators can have clients download packages directly from an
SMS 2003 distribution point. An option can be set to download the
entire program to the client computer and then run the program.
Delta distribution between site When changes are made to existing software package source files, only
servers the changes, or deltas, are propagated to distribution points, rather
than the entire software package. Only new or changed files are
transferred, which minimizes the impact on network bandwidth.
Convert older SMS packages to Existing SMS packages can be converted to packages that are
Windows Installer compatible with Windows Installer by using SMS Installer.
Administrators can also create new packages in Windows Installer
format, which takes advantage of the self-repair, just-in-time
installation, and enhanced software deployment tracking abilities.
Create packages from Windows SMS 2003 can generate software packages for distribution from any
Installer files Windows Installer file. Windows Installer configuration files contain all
the information needed to generate an SMS software package which
can support self-repair and appropriately timed installation.
Add or Remove Programs An SMS software package can be advertised and configured in the Add
integration or Remove Programs in Control Panel.

(continued)
6 Chapter 1 Introducing Systems Management Server 2003

Table 1.2 SMS 2003 Software Distribution Features (continued)


Feature Description
Elevated rights installations Software packages can be installed using elevated rights. Applications
requiring administrative access during installation can be partially
installed with administrative privileges and still have user-specific
options installed with a user account.
Protected distribution point An administrator can assign site or roaming boundaries to a
distribution point. Advanced Clients outside these boundaries are
unable to download packages from the protected distribution point.
This protects the distribution point from excessive network traffic.

For more information, see Chapter 5, “Distributing Software,” in the Microsoft Systems
Management Server 2003 Operations Guide.

Software Update Management


Software update management is the process of keeping computers and servers that are running
Windows operating systems updated with security updates or patches, and includes:
u Performing an inventory of the installed and applicable updates on managed computers.
u Evaluating and testing available updates.
u Authorizing and distributing the updates.
u Tracking software update compliance.
SMS 2003 provides new tools for software update management. You can use these tools to take
advantage of the critical software updates that Microsoft provides for Windows operating
systems, Microsoft Office, Microsoft SQL Server™, Microsoft Exchange, Internet Information
Services (IIS), and other system software.

Tools for Managing Software Updates


Several software update management tools that are provided as Web downloads in the SMS 2.0
Software Update Services Feature Pack have been updated and enhanced for SMS 2003, and they
are now installed by default on the SMS site server. These include the Distribute Software
Updates Wizard, the Software Updates Installation Agent, and a collection of predefined reports
for software updates (formerly called the SMS Web Reports Add-in for Software Updates).

Important
Two SMS 2.0 Software Update Services Feature Pack tools (Security Update
Inventory Tool and the Microsoft Office Inventory Tool for Updates) are not
installed with SMS 2003. Because these tools are updated regularly to add new
detection capabilities and product types, they are available for SMS 2003 as Web
downloads only. See Table 1.4 for more information about these tools.
SMS 2003 Features and Enhancements 7

Table 1.3 lists the software update management tools that are now integrated with SMS 2003.
Table 1.3 Software Update Management Tools
Feature Description
Distribute Software Updates Wizard Performs the following tasks:
Uses inventory information to analyze the applicable software
update status for client computers.
Provides a method of reviewing and authorizing suggested
software updates.
Downloads authorized software updates and installation
information.
Builds packages and advertisements tailored to
specifications for each software update or set of updates.
Distributes software update advertisements to client
computers by using SMS software distribution.
Software Updates Installation Evaluates advertised software updates against missing or
Agent previously installed updates on an SMS client computer and
installs the applicable updates.
Software Update Reports Predefined reports allow you to view information that is gathered
by the software update inventory tools. With these reports and with
custom reports designed by using SQL Server views, entire
dashboards can be built that provide a picture of compliance and
performance and the service levels being provided to each
identified group or update.

Table 1.4 lists the software update management tools that are available as Web downloads from
http://www.microsoft.com/smserver/downloads.
Table 1.4 Software Update Management Tools Available as Downloads
Feature Description
Security Update Inventory Tool Scans a client computer for installed software updates to
Windows operating systems, Internet Explorer, SQL Server,
and other system software. Matches installed updates against
the current catalog of software updates available from
Microsoft.
Propagates the inventory of applicable updates to the site
server by using SMS hardware inventory.
Microsoft Office Inventory Tool for Scans a client computer for installed software updates to
Updates Microsoft Office. Matches the installed updates against the
current catalog of software updates available from Microsoft.
Propagates the inventory of applicable updates to the site
server by using SMS hardware inventory.
8 Chapter 1 Introducing Systems Management Server 2003

Enhancements to Software Update Management


In addition to software update management tools that are described in the previous section,
SMS 2003 includes enhancements to the software update management capabilities of SMS,
which are described in Table 1.5.
Table 1.5 New Software Update Management Features in SMS 2003
Feature Description
Persistent notification for software An icon appears in the notification area (formerly called the system
updates tray) whenever a user is logged on and there are pending, but
uninstalled, software updates. When the computer is in
compliance the notification area icon does not appear. The
notification area icon can be used to:
Check for upcoming installations.
Schedule installations and reboots to occur at convenient
times of the day.
Install software updates immediately.
Unattended software update Provides a method to deploy mandatory updates to client
installation computers silently. No notification icon appears in the notification
area, and users with insufficient rights cannot terminate the
process in Task Manager.
Firewall authentication support Enables the synchronization host to obtain catalogs of software
updates in an automated, unattended way, even through a firewall
or proxy server that requires domain user account authentication.
Scheduled installations Provides a way to restrict installation of software updates to
certain hours on certain days. Outside of this time window, no
installation is performed. If the SMS client is offline during the
scheduled advertisement interval, the restricted installation
window prevents the SMS client from attempting to catch up and
apply the software updates at the wrong time.
Dynamic package configuration Enables distribution of one package with multiple installation
parameters, so that the package can be conditionally installed to
different collections according to defined criteria. For example, the
same package can be distributed to different collections using a
different scheduled installation setting for each collection.
Reference computer inventory Allows specification of a reference computer to generate baseline
template software update templates, enabling faster authorization, package
administration, and package deployment.

The process of managing software updates is described in more detail in Chapter 3,


“Understanding SMS Features.” For more information about software update management with
SMS 2003, see Chapter 6, “Managing Software Updates,” in the Microsoft Systems Management
Server 2003 Operations Guide.
SMS 2003 Features and Enhancements 9

Software Metering
It is important to efficiently manage the software products, services, and applications that are
deployed in your organization. SMS 2003 does this with its software inventory and software
metering features. The focus of software metering in SMS 2003 is collecting and reporting
software program usage data. You can use SMS 2003 software metering data to identify:
u Which software applications are being used and which users are running them.
u The number of concurrent software application usages.
u Actual software license requirements.
u Redundant software application installations.
u Unused software applications that can be reallocated.
Software metering has been completely redesigned in SMS 2003. It is now fully integrated with
all other SMS components, and has a new user interface accessed through the
SMS Administrator console. In addition, SMS 2003 software metering data is now stored in the
SMS site database with other SMS data.
SMS 2003 software metering includes software usage history, and enables trend analysis and
audit reporting. You can use this information to track software license usage and produce license
compliance reports. As an SMS site administrator, you can fully configure this process.
You can also configure SMS 2003 to track software usage on managed SMS client computers on
and off the network. SMS clients record software usage even when they are disconnected from
the network, by uploading usage reports either on a schedule or the next time a connection is
available to the SMS site.
The following table summarizes the core SMS 2003 software metering features.
Table 1.6 SMS 2003 Software Metering Features
Feature Description
Scalable SMS 2003 software metering is more scalable than in SMS 2.0 and can
scale to large client deployments.
Site-specific rules Different rules can be set for each SMS 2003 site. A rule can also be set
that flows to the entire SMS hierarchy.
Offline metering Software usage can be tracked on Legacy Clients and Advanced Clients
(even while disconnected from the network). The usage report is collected
when the computer reconnects with the network.

(continued)
10 Chapter 1 Introducing Systems Management Server 2003

Table 1.6 SMS 2003 Software Metering Features (continued)


Feature Description
Usage monitoring Summary and detail reports can be generated describing which
applications were used by which users, for how long, and on which
computers. Usage can be tracked by user or computer. Reports can be
created comparing concurrent usage data to current license ownership
(compliance reports). This is useful for reconciling purchased software with
used software to support future purchasing decisions.
Terminal Server monitoring SMS 2003 monitors application usage across Windows Terminal Services
sessions. Administrators can easily determine who is running Terminal
Server applications, when, and for how long.

For more information, see Chapter 8, “Software Metering,” in the Microsoft Systems
Management Server 2003 Operations Guide.

Remote Tools
SMS Remote Tools provide help desk assistance and troubleshooting support to clients in an
SMS hierarchy. The Remote Tools suite is summarized in the following table.
Table 1.7 SMS 2003 Remote Tools Suite
Tool Description
Remote Control Remotely operates a client computer from the site server.
Remote Reboot Remotely restarts a client computer.
Remote Chat Remotely chats with a user at the Advanced Client computer.
Remote File transfer Remotely transfers files between an Advanced Client and the site server.
Remote Execute Remotely runs commands and programs on a client computer.
SMS Client Diagnostics Remotely runs diagnostic utilities on a client computer.
Ping Test Remotely determines the network connection quality between a site
server and a client computer.

For more information, see Chapter 3, “Understanding SMS Features.”


SMS 2003 Features and Enhancements 11

SMS Site Maintenance and Upgrade Tools


SMS 2003 offers additional tools to support SMS site maintenance and upgrade:
u Deployment Readiness Wizard
u Network diagnostic tools
u Performance monitor counters

Deployment Readiness Wizard


You must use the SMS 2003 Deployment Readiness Wizard before you begin an upgrade from
SMS 2.0 to SMS 2003. This tool is run from SMS Setup and identifies potential problems before
SMS 2003 is installed.
Network Diagnostic Tools
Network diagnostic tools include:
Network Discovery
Network Discovery gathers information about network devices, such as IP addresses, computer
names, and operating systems.
Network Trace
Network Trace creates a network map of SMS site systems.
Network Monitor
Network Monitor is a Windows tool that you use to detect and troubleshoot problems on local
area networks (LANs), wide area networks (WANs), and serial links running Microsoft Remote
Access Server (RAS). Network Monitor analyzes captured data and provides information for
solving network problems.
Performance Monitor Counters
SMS 2003 provides a wide range of performance monitor counters which are accessed using the
Windows System Monitor. These counters are helpful for maintaining SMS, identifying problem
areas, tuning SMS systems, and troubleshooting. System Monitor gathers information about
growth patterns which you can use to plan for future hardware growth.
For more information, see Chapter 13, “Maintaining and Monitoring SMS Systems,” in the
Microsoft Systems Management Server 2003 Operations Guide.
12 Chapter 1 Introducing Systems Management Server 2003

Reporting
SMS 2003 provides a comprehensive set of predefined, secure reports with information about the
client computers across the SMS hierarchy and the current state of managed systems across an
organization. You can provide management and other SMS users with reports which can be
viewed using Internet Explorer. Reports include a wide range of information including:
u Hardware and software inventory.
u Computer configuration details and status.
u Software deployment, deployment errors, and usage status.
SMS reports are expandable, so you can generate custom views and reports. You can use the
SMS Administrator console to create and manage reports. All reports are based on Structured
Query Language (SQL). Administrators and other users (such as help desk specialists or business
decision-makers) who do not have access to the SMS Administrator console can run reports by
using Report Viewer in Internet Explorer.
You can export and import reports by using the Export Object Wizard and Import Object Wizard
in the SMS Administrator console. Use exported report files to share reports with other SMS
administrators or to import reports obtained from another SMS administrator.
You can also create dashboards, which are sets of reports displayed in a grid, in a single window
using Report Viewer, to monitor information about a variety of SMS objects or systems.
For more information, see Chapter 11, “Creating Reports,” in the Microsoft Systems
Management Server 2003 Operations Guide.

Product Compliance
The SMS product compliance feature helps ensure that software used by clients complies with
corporate guidelines, requirements, or standards. For example, there can be an organizational
requirement to use only a certain version of a software product.
The product compliance feature works with the software inventory feature. The software
inventory feature tracks software that is installed on client computers. Inventory data can show
required critical software patches that are not yet deployed to specific computers. The product
compliance feature identifies which software complies with corporate guidelines, requirements,
or standards, and which does not. After noncompliant software is identified, you use software
distribution to upgrade the software to bring it into compliance.
Instead of relying on software databases to map discovered files to known applications,
SMS 2003 scans the resource headers of program files or binary files to build a complete picture
of the software that is installed on each managed client computer. Such an approach is inherently
scalable and automatically identifies new applications when they are released.
You can use the SMS 2003 software update management tools to check installed software on all
managed systems against a Microsoft online database of available critical updates. You can then
automatically download and deploy the latest patches to those systems that require them.
SMS 2003 Features and Enhancements 13

You can gather product compliance data and store it in the SMS site database. Each product
compliance record must include product information such as the product name, product version,
and product .exe file name. The following key data items are required:
u Compliance type (type of product guideline or standard)
u Compliance level (compliance level associated with a compliance type)
You create and run queries and reports that evaluate software inventory data against product
compliance data in the SMS site database.
For more information, see Chapter 3, “Understanding SMS Features.”

Status System
The SMS status system monitors and reports the overall health of SMS sites and site hierarchies
with the following status summaries:
u Component status (describes the SMS server components status at an SMS site)
u Site system status (describes the site systems status at an SMS site)
u Package status (describes software packages and distribution points status at an SMS site)
u Advertisement status (summary report of clients having received and run an advertisement)
The SMS status system is particularly useful in troubleshooting an SMS site
For more information, see Chapter 14, “Using the SMS Status System,” in the Microsoft Systems
Management Server 2003 Operations Guide.

SMS Administrator Console


SMS 2003 Administrator console is the primary interface that you use to access, configure, and
run SMS features and tools, and accomplish daily tasks that are required to administer an SMS
system. The SMS Administrator console supports SMS sites configuration, site database
maintenance, and SMS hierarchy status monitoring.
SMS 2003 uses the Microsoft Management Console (MMC) and makes administrative functions
consistent with other Windows operating system management tools.
For more information, see Chapter 16, “Using the SMS Administrator Console.” For more
information about MMC, see MMC Help (accessed from within the Microsoft Management
Console).

Advanced Client
The corporate workforce is becoming increasingly mobile. Systems management solutions and
services must be consistent among mobile and desktop users.
14 Chapter 1 Introducing Systems Management Server 2003

SMS 2003 addresses the need for mobile computing with the Advanced Client. The Advanced
Client supports the full SMS feature set (software distribution, asset management, and remote
troubleshooting). You can manage mobile users and desktop users without differentiating
between them. The Advanced Client uses a Windows technology called Background Intelligent
Transfer Service (BITS) to provide connectivity for all management operations.

Security
SMS 2003 includes enhancements that increase overall system security while simplifying
administrative tasks that are involved in systems management security. Because SMS uses the
Windows operating system security subsystem, you can delegate administrative privileges
granularly to ensure that IT staff have only those permissions that are required to perform
assigned tasks. You can also assign privileges and grant other SMS users access to a subset of an
SMS feature set. This allows different IT administrators to handle different aspects of system
support without granting everyone full rights to the SMS system.

Standard Security
Standard security mode allows SMS 2003 to function like SMS 2.0 for organizations that have
not yet implemented Active Directory. Standard security mode sites do not require their SMS
servers to be in Active Directory. Standard security mode relies on regular user accounts to run
services, make changes to computers, and connect between computers.

Advanced Security
You can run SMS 2003 in advanced security mode. In this mode, all SMS services run under the
Local System security context, using the host computer account to access other network
resources. This eliminates the need to maintain multiple account passwords on each site, ensuring
compliance with local security policies.
Advanced security sites can coexist with standard security sites. However, advanced security
mode is available only if all SMS server computers within a site are in Active Directory and
Active Directory is available at all network locations.
In advanced security mode, services run in Local System context, thereby eliminating the need
for SMS to create user accounts and for SMS administrators to manage these accounts. Computer
accounts are used for secure communication between servers.
For more information about security, see Chapter 5, “Understanding SMS Security,” and
Chapter 12, “Planning Your SMS Security Strategy.”
SMS 2003 Features and Enhancements 15

Active Directory
Active Directory integration makes it possible for you to identify software deployments and run
reports, based on organizational units. SMS 2003 is not restricted to users and groups. SMS site
boundaries can be logically defined to mirror Active Directory topologies, rather than being
strictly limited to IP subnet ranges.
Active Directory support is accomplished by using WMI to import directory objects into the
SMS 2003 database as collections. You can customize directory synchronization by choosing
different schedules and which directory tree objects are to be transferred.
You can extend the Active Directory schema, which results in the following advantages:
u Advanced Clients can perform global roaming
u Automatic secure key exchange between SMS sites
SMS 2003 Active Directory features are summarized as follows.
Table 1.8 Active Directory Features in SMS 2003
Feature Description
Active Directory synchronization An Active Directory structure of both clients and systems can be
automatically discovered and imported.
Active Directory-based site Site boundaries can be based on Active Directory site names rather than
boundaries on IP subnets, which simplifies the enterprise infrastructure for enterprises
that are using Active Directory and also reduces operating costs.
Active Directory discovery SMS 2003 can discover the Active Directory properties of both clients and
systems, including organizational unit container and group level
membership. Software packages can then be identified based on these
Active Directory attributes. This directory-enabled management allows
enterprises with an investment in Active Directory to use SMS 2003 to
manage their enterprise according to how their business is organized.
While SMS 2003 can use Active Directory where it is available, it does not
require it. Organizations that have not yet deployed Active Directory can
still benefit from SMS 2003.

Site Installation
The following table summarizes enhancements to site installation features in SMS Setup.
16 Chapter 1 Introducing Systems Management Server 2003

Table 1.9 SMS 2003 Setup Features


Feature Description
Security mode SMS administrators can select from standard security mode or advanced
security mode depending on their organization’s needs.
Extend the Active Directory Schema The Active Directory schema can be extended on the SMS Active Directory
during and after setup Schema page during setup. This only applies to installations in
Active Directory domains. The Active Directory schema must be extended
when the SMS administrator plans to implement global roaming for
Advanced Clients. Extending the Active Directory schema requires schema
administrator rights.
SQL Server Memory option for This setting adjusts the amount of memory that is used, based on demand.
dynamically configuring SQL Server Before changing this option, see the SQL Server product documentation
memory for performance and tuning information.
Secondary site installation options A secondary site can be installed from the SMS 2003 CD or from an image
of that CD on a mapped network drive, hard disk, or a secondary site
removable drive. A secondary site can also be installed from the primary
site by using the SMS Administrator console. This was an SMS 2.0 feature.

Client Discovery and Installation


Clients must first be discovered before they can be installed. SMS uses various discovery
methods to locate clients prior to installation. SMS 2003 has both Legacy Client and Advanced
Client installation methods. You should appropriately enable, configure, and control client
installation methods to avoid imposing an excessive workload on the network or servers.

Discovery Methods
SMS finds clients and other resources by using its discovery methods. SMS 2003 has the
following discovery methods which support both Legacy Clients and Advanced Clients, and
which can be used individually or in combination:
u Network Discovery
u Heartbeat Discovery
u Windows User Account Discovery
u Windows User Group Discovery
u Active Directory System Discovery
u Active Directory User Discovery
u Active Directory System Group Discovery
For more information about discovery methods, see Chapter 17, “Discovering Resources and
Deploying Clients.”
SMS 2003 Features and Enhancements 17

Legacy Client Installation Methods


You can use the Legacy Client if your organization needs to manage computers that do not meet
the requirements for supporting the Advanced Client. You can enable, configure, and control the
following Legacy Client installation methods:
u Logon Script-initiated Client Installation
u Client Push Installation
u Manual Client Installation
For more information about Legacy Client installation methods, see Chapter 4, “Understanding
SMS Clients,” and Chapter 17, “Discovering Resources and Deploying Clients.”

Advanced Client Installation Methods


If you are using the Advanced Client, you can enable, configure, and control the following
Advanced Client installation methods:
u Logon Script-initiated Client Installation
u Client Push Installation
u Software Distribution Techniques
For more information, see Chapter 4, “Understanding SMS Clients,” and Chapter 17,
“Discovering Resources and Deploying Clients.”

Site Configuration
A new site must be configured after SMS 2003 has been installed. You begin site configuration
by defining site characteristics and configuring site systems at a single site. You build an SMS
site hierarchy after you configure individual sites, by establishing communications between sites
and attaching primary sites to form the site-reporting structure that you designed in the planning
phase.
For more information, see Chapter 15, “Deploying and Configuring SMS Sites.”

Site Boundaries
SMS 2003 site boundaries are defined by IP subnet or Active Directory site name and can be
managed by Active Directory site names instead of, or in addition to, IP subnets.
Roaming boundaries enable SMS to provide software distribution to roaming Advanced Clients.
Using roaming boundaries, an SMS Advanced Client computer can be moved from one location
to another in an organization and still be managed by SMS. Roaming boundaries allow clients
from within site boundaries to use site distribution points as their local distribution points.
18 Chapter 1 Introducing Systems Management Server 2003

The Advanced Client is assigned to a site even if it does not currently reside within that site’s
roaming boundaries. The Advanced Client is not assigned to a site if it is not set to automatically
determine a site and is not set to a specific site. Advanced Clients look in the Active Directory to
match site boundaries.
For more information, see Chapter 2, “Understanding SMS Sites,” and Chapter 10, “Planning
Your SMS Deployment and Configuration.”
Client Configuration
Legacy Client computers compare their SMS configuration against the client access point (CAP)
settings each time they are rebooted and every 25 hours. The comparison consumes some
resources; however, there is more substantial activity if software changes are required. Advanced
Clients check for these configuration settings when they check for advertisements. In addition,
Advanced Clients use management points, not CAPs.
For more information, see Chapter 17, “Discovering Resources and Deploying Clients.”

Site System Roles


The following are important site system roles that are new or enhanced in SMS 2003:
u Client access point
u Distribution point
u Management point
u Server locator point
u Reporting point
SMS 2003 does not support logon points, a site system role that was available in previous
versions of SMS. .
For more information, see Chapter 2, “Understanding SMS Sites,” Chapter 8, “Designing Your
SMS Sites and Hierarchy,” and Chapter 15, “Deploying and Configuring SMS Sites.”
Client Access Point
The CAP role is the point of contact between Legacy Clients and the SMS site server. The CAP
passes all Legacy Client data to the site server. Legacy Client computers contact the CAP for
management information from the SMS site server.

Distribution Point
A distribution point is a site system role that stores software package files so clients can access
them during the software distribution process. Distribution points handle significant client
network activity. It is a best practice to assign this role to one or more computers other than the
site server.
SMS 2003 distribution points use Background Intelligent Transfer Service (BITS) to
automatically detect the client network connection capacity and adjust transfer rates efficiently.
BITS can be enabled on any SMS 2003 distribution point that is running IIS.
SMS 2003 Features and Enhancements 19

Management Point
The Advanced Client communicates with SMS sites by using management points.
Like CAPs, management points provide Advanced Clients with configuration details and
advertisements. They also receive inventory, software metering, and client status information.
To be a management point, the server must have IIS installed and enabled.
Server Locator Point
The server locator point locates CAPs for Legacy Clients and management points for Advanced
Clients at client logon time. The server locator point replaces the SMS 2.0 logon point and
eliminates most traffic between SMS and domain controllers.
Server locator points are supported only at primary sites and are used for installation of both
Legacy Clients and Advanced Clients. The number of server locator points included in a site
depends on the number of clients in that site.
Reporting Point
A reporting point is a site system role that hosts the Report Viewer code and any supplemental
reports. To be a reporting point, the server must have IIS installed and enabled.
Reporting points are implemented on primary sites. Large organizations with numerous report
users should plan for multiple reporting points at different hierarchy levels. You use multiple
reporting points to provide different reporting-point access URLs to different sets of users for
accessing reports.

Backup and Recovery


SMS 2003 provides robust and efficient backup and recovery features, including:
u You can now back up secondary sites.
u The backup control file is more user friendly and easier to use. The backup control file
parser and syntax checking has also been improved.
u The backup task is more efficient and no longer backs up the entire site. Rather, it only backs
up what will be necessary during site restoration. This reduces the backup cycle time and the
amount of space necessary to store the site backup.
u Backup error logging has been improved.
u New tools for backup and recovery.
For more information, see Chapter 13, “Planning for Backup and Recovery.” Also, see
Chapter 15, “Backup and Recovery,” in the Microsoft Systems Management Server 2003
Operations Guide.
Recovery Tools
The following new backup and recovery tools are integrated into SMS 2003.
20 Chapter 1 Introducing Systems Management Server 2003

Recovery Expert
The Recovery Expert is an essential recovery tool that collects information about a site failure
scenario and produces a list of tasks to be performed for site recovery. Any site server on which
the Recovery Expert Web will be installed must have IIS enabled. You can later use Internet
Explorer to connect to the Recovery Expert Web site and to run the Recovery Expert. For more
information, see Chapter 13, “Planning for Backup and Recovery.” Also see Chapter 15,
“Backup and Recovery,” in the Microsoft Systems Management Server 2003 Operations Guide.
Repair Wizard
You can perform complicated recovery tasks by using the Repair Wizard, which is integrated
with the Recovery Expert. The Recovery Expert instructs you when to use the Repair Wizard.
ACL Reset
ACL Reset is a command-line tool that runs on the site server and is used for resetting access
control lists on files and registry keys. You can run ACL Reset manually from the command line,
or you can run it by an automated script.
Hierarchy Maintenance Utility
The Hierarchy Maintenance Utility is used to diagnose problems in a site, repair a site, or stop all
SMS services at a site. For example, if an SMS site is removed incorrectly by removing a child
site from its parent site without detaching it first, you can use the Hierarchy Maintenance Utility
to bypass the SMS Administrator console and delete the incorrectly removed site from the parent
site database.
P A R T 2

Concepts

This part of the Microsoft® Systems Management Server 2003 Concepts, Planning, and
Deployment Guide describes fundamental Systems Management Server 2003 concepts, such as
planning your SMS implementation and developing your security strategy.
C H A P T E R 2

Understanding SMS Sites

This chapter describes conceptual information about the fundamental organizational units of
Microsoft® Systems Management Server (SMS) 2003, called SMS sites, and how they are
connected to build an SMS hierarchy. It is important that you understand these concepts before
you design your SMS sites and hierarchy.
In This Chapter
u SMS Sites
u SMS Hierarchy
u Site Communications
24 Chapter 2 Understanding SMS Sites

SMS Sites
When you first install SMS, you install a single SMS site. This is the fundamental administrative
unit in SMS. It defines the computers, users, groups, and other resources that are managed by
SMS.
An SMS site is bounded by a group of subnets that are defined by the SMS administrator using
IP subnets and/or Active Directory® site names. This means that you arrange SMS sites based on
subnet addresses of computers or Active Directory site membership. An SMS site is identified by
a three-character code that is assigned by the SMS administrator when the site is installed. Site
codes cannot be changed after installation and must be unique across an SMS hierarchy. The
configuration of a site is stored in an ASCII text file (Sitectrl.ct0) called the site control file.
The SMS product is installed on the SMS site server, which manages the SMS site and all of its
components and services. The SMS site server is the primary point of access between you and
the SMS site database, which is a Microsoft SQL Server™ database that stores information such
as client data that is discovered and inventoried by SMS and configuration and status
information.
An SMS site system is a server that provides SMS functionality to the site. The functionality
contributed by a site system is indicated by its assigned site system roles, which are tasks that a
site system performs in an SMS site.
The relationship of all SMS sites in your organization is an SMS hierarchy, as described later in
this chapter.
To understand how SMS sites are created and attached to form a hierarchy, you should be
familiar with the information in the following sections:
u Site Types
u Parent-Child Site Relationships and the SMS Hierarchy
u Site Elements
u Site Boundaries
u Roaming and Roaming Boundaries

Site Types
An SMS site consists of a site server, site systems, clients, and resources. SMS provides two
types of sites:
u Primary site
u Secondary site
By default, the first SMS site you install is a primary site.
SMS Sites 25

Primary Site
A primary site stores SMS data for itself and all the sites beneath it in a SQL Server database.
This is called the SMS site database. Primary sites have administrative tools, such as the
SMS Administrator console, that enable the SMS administrator to directly manage the site.
SMS Setup creates each primary site as a stand-alone site. Primary sites can have multiple
secondary sites, all of which send data to the primary site.
Secondary Site
A secondary site has no SMS site database. It is attached to and reports to a primary site. The
secondary site is managed by an SMS administrator running an SMS Administrator console that
is connected to the primary site.
The secondary site forwards the information it gathers from SMS clients, such as computer
inventory data and SMS system status information, to its parent site. The primary site then stores
the data of both the primary and secondary sites in the SMS site database.
Secondary sites are particularly useful for locations across a wide area network (WAN) link that
do not have an onsite administrator to perform management tasks. In this situation, set up the
secondary site in a separate location and administer it from the primary site that it reports to.
Figure 2.1 Primary and secondary site relationship in an SMS
Primary
site

Primary
site

Secondary
Secondary site
site
hierarchy

Parent-Child Site Relationships and the SMS Hierarchy


After you install your first SMS primary site, you can add sites above and beneath it. When you
attach a secondary or primary site to another primary site, you create a parent-child relationship.
Both primary and secondary sites report to primary sites. By attaching one site to another, you
create an SMS hierarchy.
Parent Site
A parent site is a primary site that has at least one site attached to it in the hierarchy. Only a
primary site can have child sites. A secondary site can only be a child site. A parent site contains
pertinent information about its lower level sites, such as computer inventory data and SMS
system status information, and controls many operations at the child sites.
26 Chapter 2 Understanding SMS Sites

Child Site
A child site is a site that is attached to a site above it in the hierarchy. The site it reports to is its
parent site. SMS copies all the data that is collected at a child site to its parent site. A child site is
either a primary site or a secondary site.
Central Site
The central site is the primary site at the top of the SMS hierarchy. It is not a child to any other
site. The SMS site database at the central site acquires aggregate inventory and software metering
data from the SMS hierarchy and collects details about any collections, packages, or
advertisements created at the central site. At the central site, you can view and manage all sites
and computers in the SMS hierarchy.

Note
Typically, the central site is located at the logical center of IT administration
for your organization.

Sites are organized into a hierarchy by setting up parent-child relationships between the sites, as
illustrated in Figure 2.2. When attaching sites, you specify one site as the parent site and one site
as the child site.
Figure 2.2 Parent-child site relationship in an SMS hierarchy
Parent site
(central site)

Parent
and child

Child Child

Hierarchy Tiers and Hierarchy Branches


After you install your first SMS site, you build your SMS hierarchy from that site. Each
horizontal layer of SMS sites is a tier. Sites on the same hierarchy tier that are child sites to the
same parent site are called sibling sites. Sibling sites always share the same tier.
A group of SMS sites that are interconnected vertically in the hierarchy, with all sites in the
group reporting up to one primary site, is a hierarchy branch. Sibling sites are included in the
same hierarchy branch.
SMS Sites 27

All of the sites above a child site in the same hierarchy branch are referred to as its higher level
sites. Sites beneath a parent site in the same hierarchy branch are referred to as its lower level
sites. Lower level sites always report inventory information up the hierarchy, all the way to the
central site. For more information, see the “Building the SMS Hierarchy” section later in this
chapter.

Site Elements
The fundamental elements of an SMS site are site system roles and site resources. Site resources
include SMS clients. This section describes these and other elements of the SMS site.
Site System Roles
Each SMS site contains a site server and one or more site systems. A site system is any server
running a supported version of Windows® or a shared folder that provides some functionality to
the SMS site. A site system role is a role that a site system performs in an SMS site. For example,
the client access point (CAP) role provides a communication point between the SMS site and
Legacy Clients. A computer hosting the CAP is a site system.
To decrease the load on your primary or secondary site server, you might want SMS to perform
some server tasks on computers other than the site server.
The SMS administrator can assign site system roles to the primary site server or distribute them
among several different site systems. Some site system roles are assigned during installation.
Other site system roles are assigned through the SMS Administrator console. Servers are often
referred to by their site system role name. For example, a server that performs the distribution
point role is often called a distribution point. This section provides more detailed information
about the site system roles that comprise SMS functionality. These include:
u Site server
u Component server
u SMS site database server
u Client access point
u Distribution point
u Management point
u Server locator point
u Reporting point
28 Chapter 2 Understanding SMS Sites

Site server
The site server hosts the SMS components that are necessary to monitor and manage an SMS
site. When SMS is installed on a computer, that computer is automatically assigned the site
server role. The site server can perform additional roles, such as CAP, management point, or
distribution point. By default, the SMS Administrator console is installed on a primary site server
during SMS setup. A distribution point and a CAP are also installed on the site server by default.

Note
Although a site server can perform multiple site system roles simultaneously,
such a configuration is not recommended for production sites with large
numbers of resources. Using a site server to perform multiple roles in a large
site can create a system resource usage bottleneck at the site server. For
more information, see Chapter 9, “Capacity Planning for SMS Component
Servers.”

The site server runs the following services:


SMS Executive This is the main SMS service. It contains many SMS threads that carry out
specific SMS functions.
SMS Site Component Manager This service ensures that the component server processes are
running properly. It performs the initial installation of components and performs regular checks
to ensure that they are running properly.
Component server
Component servers host one or more SMS components that support the site. For example, when a
sender is installed on a server, or when the CAP role is assigned to a site system, that site system
is automatically assigned the role of component server. A component server is 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.
The component servers are:
u Site server
u SMS site database server
u Client access point
u Management point
u Server locator point
u Reporting point
u Sender server
For more information, see the “Senders” section later in this chapter.
SMS Sites 29

SMS site database server


The SMS site database server is a computer running SQL Server that stores information such as
discovery data, hardware and software inventory data, and configuration and status information
for the SMS site and its lower level sites. It runs the SMS SQL Monitor service. Every primary
site in the SMS hierarchy contains an SMS site database.

Note
To preserve network bandwidth, it is recommended that the SMS site
database be installed on the primary site server itself, instead of on a
different computer running SQL Server.

Client access point


The CAP role is the point of contact between Legacy Clients and the SMS site server. The CAP
passes all Legacy Client data to the site server. Legacy Client computers contact the CAP for
management information from the SMS site server. A CAP serves only one SMS site and is
installed by default on the site server. The CAP also:
u Provides specific configuration instructions and files for the Legacy Client during client
installation and when changes are made after client installation.
u Serves as the location where Legacy Client computers check for advertisements.
u Receives data from Legacy Clients, which it forwards to the SMS site server. For example,
when a client completes either hardware or software inventory and has created an inventory
data file, it sends this data to the CAP. Any status messages originating from the client are
replicated to the CAP.
Distribution point
The distribution point stores SMS package source files that SMS clients use when installing
software programs distributed by SMS. When the SMS administrator advertises a program, the
advertisement and program information are available to clients through a CAP for Legacy Clients
or through a management point for Advanced Clients.
When SMS is set up, the site server is automatically assigned the distribution point role. The
SMS administrator can enable the distribution point to use Background Intelligent Transfer
Service (BITS), which enables incremental package file download to Advanced Clients. For
more information about BITS, see Chapter 3, “Understanding SMS Features.”
Management point
The management point is the primary point of contact between Advanced Clients and the SMS
site server. An SMS site has only one default management point, although multiple management
points can be configured with Windows Network Load Balancing Service. Similar to the
relationship between CAPs and Legacy Clients, a management point:
u Provides specific client configuration details (also known as Advanced Client policy) for the
Advanced Client after client installation.
u Serves as the location where Advanced Client computers check for advertisements.
30 Chapter 2 Understanding SMS Sites

u Locates distribution points for Advanced Clients.


u Receives inventory, software metering, and status information from Advanced Clients and
forwards it to the SMS site server.

Note
If the Active Directory schema is not extended for SMS, you must register the
management point in WINS.

Server locator point


The server locator point locates CAPs for Legacy Clients and management points for Advanced
Clients. The server locator point is mostly used in client installation. The server locator point:
u Locates a management point for the Advanced Client if the Advanced Client is configured
for automatic SMS site assignment.
u Provides Advanced Clients with the location of the management point during Logon Script-
initiated Client Installation and insufficient-rights installation.
u Provides SMS site assignment for the Legacy Client and locates CAPs during Logon Script-
initiated Client Installation.

Note
If the Active Directory schema is not extended for SMS, you must register the
server locator point in WINS.

Reporting point
A reporting point is a server that hosts the code for Report Viewer and any supplemental reports.
A reporting point communicates only with its SMS site database server.
For more information about site system roles, see Chapter 8, “Designing Your SMS Sites and
Hierarchy.”
Resources and Clients
A resource is an object, such as a computer, a router, or a Windows user group, that can be
discovered and potentially be managed by SMS. Resources are easily managed by creating rules
that filter and organize them into collections. Collections provide you with a greater degree of
administrative control when installing the SMS client and sending software programs to SMS
clients.
The SMS client is the most common site resource. An SMS client is a computer that has SMS
client software installed. The client has a TCP/IP address that is identified with an IP subnet. If
Active Directory is enabled and the client has a computer account in Active Directory, then the
client’s TCP/IP address is associated with an Active Directory site name.
SMS Sites 31

Discovery is the process of locating resources and collecting information about them. When SMS
discovers a resource, it creates a discovery data record (DDR) and forwards the DDR to the SMS
site server, where it is stored in the SMS site database. Resources in the database can belong to
collections. If the resource is a supported computer platform, SMS can install the SMS client
software on it. For information about supported platforms, see the “Getting Started” chapter in
this book.
Resource discovery is not the same as client assignment to a site or client installation. These are
separate processes. For more information about resource discovery and client assignment, see
Chapter 4, “Understanding SMS Clients,” and Chapter 17, “Discovering Resources and
Deploying Clients.”

Note
With network discovery or Active Directory system discovery, SMS discovers
a computer without installing the SMS client software. This happens if the
computer is running an unsupported operating system. It also happens if
client discovery is enabled but no client installation methods are enabled.
Computers become SMS clients at SMS client installation time.

SMS Provider
The SMS Provider processes requests for data from the SMS site database. The SMS Provider
role is installed on the same computer as the SMS site server or the SMS site database. It is
recommended that you install both the SMS Provider and the SMS site database on the site
server. The SMS Provider provides access to data for the SMS Administrator consoles installed
in the site.
SMS Administrator Console
The SMS Administrator console is the graphical user interface used to administer SMS. This
interface uses a Microsoft Management Console (MMC) snap-in that is provided with the SMS
product software. The SMS Administrator console is installed by default when you install a
primary site server.

Site Boundaries
SMS sites are bounded by site boundaries. Site boundaries are defined by IP subnets,
Active Directory site names, or both. Clients are assigned to an SMS site based on their IP
address or Active Directory site name and by the SMS site boundary configuration.
Legacy Clients are included in an SMS site if their IP address or Active Directory site name is
within the site boundaries that the SMS administrator has configured for the SMS site.
32 Chapter 2 Understanding SMS Sites

It is recommended that subnets or Active Directory sites are not contained in more than one SMS
site. Overlapping boundaries produce undefined results in SMS. Assign clients to only one SMS
site.

Note
Site boundaries are used to assign clients to a site. They are not used to
specify which computers are assigned site system roles for the site. SMS site
systems do not need to be located within a site’s boundaries. SMS Advanced
Clients are able to communicate with site systems that are members of
another site in the SMS hierarchy. For more information, see the “How
roaming works for software distribution” section later in this chapter.

Roaming and Roaming Boundaries


Some SMS Advanced Client computers are mobile, moving from one network segment to
another. For example, roaming occurs when you remove a laptop from its network connection at
work and plug it into a dial-up connection (or other Internet service provider connection) in your
home or elsewhere. Roaming also occurs when you unplug your laptop from its network
connection in your office, walk down the hallway to a conference room, and connect the laptop
to your organization’s wireless network using a wireless network card.
Roaming is the ability to move a computer running the SMS Advanced Client from one IP subnet
or Active Directory site to another. Roaming always involves an IP address change on the client.
Advanced Clients configured for auto-assignment are assigned to SMS sites based on the site’s
roaming boundary configuration. You can also manually assign the Advanced Client to an SMS
site, regardless of boundaries.
Using roaming boundaries, an SMS Advanced Client computer can move from one location to
another in the organization and still be managed by SMS. Even when a client computer roams, it
might need to receive software packages from SMS. Roaming boundaries enable SMS to provide
software distribution to roaming Advanced Clients. Roaming boundaries are also used to
configure protected distribution points. Access to a protected distribution point is restricted to
only Advanced Clients that are in a specified set of boundaries configured by the SMS
administrator.
SMS Sites 33

Roaming boundaries are specified by IP subnet, IP address range, and/or Active Directory site
name. An SMS site’s roaming boundary configuration controls Advanced Client access to its
distribution points. By default, SMS site boundaries are also configured as local roaming
boundaries.

Important
Do not configure roaming boundaries to overlap one another. If an Advanced
Client is within the roaming boundaries of more than one SMS site, the client
might not communicate with the correct site. If a client roams to a location
that has no roaming boundaries defined, then that client reverts to its
assigned site’s management point and distribution point. In this scenario,
the client treats the distribution point as a remote distribution point. For
more information about remote distribution points, see the “How roaming
works for software distribution” section later in this chapter.

Management points and roaming Advanced Clients


To understand how Advanced Clients interact with management points while roaming, you
should be familiar with the following terms:
Assigned management point The default management point of the site that the Advanced Client
is assigned to. Client data (including status, hardware inventory, and software inventory) is
always sent to the assigned management point unless a proxy management point is available.
Resident management point The default management point for the roaming boundaries of the
site where the Advanced Client is currently located, whether the client is roaming. When the
client is in its assigned site, the site default management point is the client’s resident
management point. As the client roams, the management point it uses as its resident management
point is dependent on the roaming boundaries the client is in.
Proxy management point A secondary site management point that is servicing the Advanced
Clients that are in its roaming boundaries and are assigned to its parent primary site.
The Advanced Client sends package source location requests to its resident management point.
All other requests and data, including Advanced Client policy requests, inventory data, and status
messages, are sent to the proxy management point if one exists or to the assigned management
point if a proxy management point does not exist. Except for Advanced Client policy, all
messages passed between the management point and the Advanced Client are compressed.
The proxy management point passes inventory data and status messages to the secondary site
server. The secondary site server then replicates the data to the primary site. Because the senders
throttle site-to-site communications, this proxy method increases bandwidth usage efficiency. For
Advanced Client policy and package source location requests, the proxy management point
bypasses the secondary site sender and directly accesses the SMS site database or a replicated
SQL Server database.
34 Chapter 2 Understanding SMS Sites

For more information about proxy management points, see the “Management points at secondary
sites” section in Chapter 8, “Designing Your SMS Sites and Hierarchy.”

Note
To reduce network traffic to the SMS site database server, implement
SQL Server database replication. For more information, see the “Planning for
SQL Server Database Replication” section in Chapter 10, “Planning Your
SMS Deployment and Configuration.”

How roaming works for software distribution


Advanced Clients are assigned only to primary sites, not to secondary sites. When an Advanced
Client needs access to an advertised program, it uses Active Directory to locate its resident
management point. If the client is still in its assigned site, then its assigned management point
serves as its resident management point. The client sends package source location requests to the
resident management point. The resident management point determines which distribution points
are available to the client. It also determines whether the distribution points are in the local
roaming boundaries or remote roaming boundaries of the site associated with the roaming
boundary the client is in. This location helps determine how the Advanced Client accesses the
distribution points in that site. For more information about local and remote roaming boundaries,
see the “Roaming to local roaming boundaries and remote roaming boundaries” section later in
this chapter.
The other determining factor for how Advanced Clients access advertised programs on
distribution points in roaming boundaries is how the program advertisement is configured. When
the Advanced Client receives a program advertisement, and a distribution point is available
locally to the client (that is, the client is in a local roaming boundary), the Advanced Client
performs one of the following actions:
u Runs the package directly from the distribution point
u Downloads the package before running it
When the Advanced Client receives a program advertisement, and a distribution point is not
available locally to the client (that is, the client is in a remote roaming boundary), the Advanced
Client performs one of the following actions:
u Does not run
u Downloads from a remote distribution point before running
u Runs directly from a remote distribution point
If the SMS package is not available in the site associated with the roaming boundaries that the
client is in, the client reverts to its assigned site to make a package source location request to its
assigned management point. The management point then provides the locations of the
distribution points that are available. If the package source files are available locally, but are not
accessible, the client does not revert to its assigned site. This functionality protects the WAN
from unplanned traffic if a distribution point fails. If the package is available and the
advertisement is configured to download before running, the client downloads the package in its
entirety before running the package.
SMS Sites 35

Roaming to local roaming boundaries and remote roaming boundaries


When configuring roaming boundaries, the SMS administrator specifies whether a roaming
boundary is a local roaming boundary or a remote roaming boundary. This determines whether
the Advanced Client treats distribution points in the site as being locally available for each
roaming boundary that is configured.
For example, you might want SMS clients in one roaming boundary to download SMS packages
before installing them. In other roaming boundaries, you might want SMS clients to run the
package installation program over the network. The latter scenario is more common if the client
is well-connected to the SMS site associated with the roaming boundaries in which it resides.
The terms local and remote are designed to be used by the SMS administrator as a way to label
well-connected and not well-connected network segments, respectively. If the SMS administrator
defines the roaming boundaries in this way, then the following definitions apply:
Local roaming boundary A roaming boundary in which the site distribution points are locally
available to the Advanced Client and software packages are available to that client over a well-
connected link. Advertisements sent to Advanced Clients specify whether the Advanced Client
downloads the package source files from the locally available distribution point before running
the program.
Remote roaming boundary A roaming boundary in which the site distribution points are not
locally available to the Advanced Client. Advertisements sent to Advanced Clients specify
whether the client downloads the software program from a remote distribution before running it,
runs the package from a remote distribution point, or does nothing and waits until a distribution
point becomes available locally.

Note
A distribution point in remote roaming boundaries is considered to be not
locally available to the client. In other words, the distribution point is a
remote distribution point. If you configure your remote roaming boundaries
to include network segments that are not well-connected to the SMS site,
then the distribution point is truly remote to the Advanced Client in physical
proximity.
A client can roam to a nearby site and still be within the remote roaming
boundaries of that site. In this case, the client treats the distribution points
of that site as remote distribution points. Although the client is using the
closest physically located distribution points, it does not treat them as locally
available distribution points.

In a local roaming boundary, if the client is well-connected to the distribution point, but BITS is
not enabled on the distribution point, SMS packages are downloaded directly using server
message block (SMB). If the distribution point is BITS-enabled, clients download programs in a
throttled manner and use checkpoint restart to automatically recover from network
communication errors. BITS is more efficient than SMB even in an environment where network
connectivity is reliable and fast, such as with local area network (LAN) speeds of 10 Mbps or
greater.
36 Chapter 2 Understanding SMS Sites

If the Advanced Client is not located in any roaming boundaries, it reverts to its assigned site for
Advanced Client policy and all other site communications. In this case, the client is still able to
access package files, but it receives them from a remote distribution point, using BITS to
download packages efficiently. Or, if the distribution points of the site are considered remote to
the client’s location, but a BITS-enabled distribution point cannot be located, then the package
files are downloaded using SMB.
Roaming scenarios
Figures 2.3 and 2.4 illustrate a few potential regional and global roaming scenarios in an
SMS 2003 hierarchy. Each figure is accompanied by a table that describes the Advanced Client’s
roaming path and which management point and distribution points that the client communicates
with in each scenario.
Regional roaming (with WINS) Figure 2.3 illustrates different Advanced Clients that are assigned
to primary site A00 and primary site B00, and that roam to various lower level primary and
secondary sites. Some of the sites that they roam to are configured for roaming boundaries.
SMS Sites 37

Figure 2.3 Regional roaming


Primary
Site A00

Management Client
point A A2
Distribution Client
point A A3
Client
Secondary A1 Primary
Site C00 Site B00

Client
Client A1 A2
Client
Management B1
point B Distribution Client
point B A2

Wireless network,
VPN or RAS
dial-up

Roaming
boundaries of
Secondary Site B00
Site D00

Roaming path
Client B1
Site boundaries
Management
Site boundaries enabled point D and distribution
as local roaming boundaries point D
Client
Remote roaming A3
boundaries
Roaming
boundaries of
Site D00
38 Chapter 2 Understanding SMS Sites

Table 2.1 shows which management point and distribution points that each client uses in each
regional roaming scenario depicted in Figure 2.3:
u Client A1 roams into the site boundaries of secondary site C00 where no roaming boundaries
are defined.
u Client A2 roams into the site boundaries (also the local roaming boundaries) of primary site
B00. Later, client A2 dials up a remote access server (RAS) in the remote roaming
boundaries of site B00.
u Client A3 roams into the local roaming boundaries of secondary site D00.
u Client B1 roams into the site boundaries (also the local roaming boundaries) of secondary
site D00.
Table 2.1 Regional Roaming Scenarios Depicted in Figure 2.3
Which distribution
Location where the Which management points can deliver
client roams and the point the client uses available software
type of roaming and the type of content to the client
Client boundary management point and their availability
A1 Site boundaries of Reverts to management Reverts to distribution
secondary site C00, point A (assigned, point A (remote)
which has no roaming resident)
boundaries
A2 Site boundaries Management point B Distribution point B
(enabled as local (resident) (locally available)
roaming boundaries) of Or, reverts to
primary site B00 distribution point A
(remote)
A2 Remote roaming Management point B Distribution point B
boundaries of primary (resident) (remote)
site B00 Or, reverts to
distribution point A
(remote)
A3 Site boundaries (also Management point D Distribution point D
the local roaming (resident) (locally available)
boundaries) of Or, reverts to
secondary site D00 distribution point A
(remote)
B1 Site boundaries (also Management point D Distribution point D
the local roaming (proxy, resident) (locally available)
boundaries) of Or, reverts to
secondary site D00 distribution point B
(remote)
SMS Sites 39

Global roaming (with Active Directory) Figure 2.4 illustrates three different clients that are
assigned to different primary and secondary sites in the hierarchy and that roam to various lower
level and higher level primary and secondary sites and to sites in another hierarchy branch.
Figure 2.4 Global roaming
Primary
Site E00

Roaming
Distribution boundaries of
point E Site E00

Management
point E

Client G1
Roaming Primary Primary
boundaries of Site G00 Site F00
Site G00

Distribution Client
point G G1
Client Management
point F Distribution
Management G2 point F
point G
Client G3

Client Wireless network,


VPN or RAS
G2 dial-up
Roaming
boundaries of Protected
Site F00 distribution
Secondary point F
Site H00

Roaming path

Site boundaries enabled


as local roaming boundaries
Client G3
Remote roaming
boundaries
40 Chapter 2 Understanding SMS Sites

Table 2.2 shows which management point and distribution points each client uses in each global
roaming scenario depicted in Figure 2.4:
u Client G1 roams up the hierarchy into the site boundaries (also the local roaming
boundaries) of primary site E00.
u Client G2 logs on to the wireless LAN in the remote roaming boundaries of primary site
F00.
u Client G3 roams into the site boundaries (also the local roaming boundaries) of secondary
site H00.
Table 2.2 Global Roaming Scenarios Depicted in Figure 2.4
Which distribution
Location where the Which management points can deliver
client roams and the point the client uses available software
type of roaming and the type of content to the client
Client boundary management point and their availability
G1 Site boundaries Management point E Distribution point E
(enabled as local (resident) (locally available)
roaming boundaries) of Or, reverts to
primary site E00 distribution point G
(remote)
G2 Remote roaming Management point F Protected distribution
boundaries of primary (resident) point F (locally
site F00 available)
Or, reverts to
distribution point G
(remote)
G3 Site boundaries (also Management point F Distribution point F
the local roaming (resident) because, in (remote)
boundaries) of the absence of a
secondary site H00 management point at
H00, the roaming
boundaries at H00 are
an extension of the
roaming boundaries of
F00
SMS Sites 41

Using protected distribution points


If there is a WAN connection between SMS site servers, the SMS administrator must be aware of
and carefully consider bandwidth usage. By default, Advanced Clients choose a distribution
point at random from the list of available distribution points provided by the resident
management point when making package source file requests. To restrict access to a distribution
point that is across a slow or unreliable network link, enable it as a protected distribution point.
By doing so, Advanced Clients that are outside of the protected distribution point’s specially
configured boundaries will not attempt to download or run software packages from the protected
distribution point. This is beneficial at remote locations, where a small number of SMS clients
and a distribution point are connected to the primary site by a WAN.
The protected distribution point excludes Advanced Clients outside of its specially configured
boundaries from downloading or running advertised packages from it.
If configured properly, protected distribution points
Package source file requests and
protected distribution points ensure that Advanced Clients that are well-connected to
To download or run a package
an SMS site do not download packages from a
program, the client sends a package distribution point located across a WAN link.
source file request to its resident For example, you might have a primary site in your
management point. If the client is in
main office and a secondary site at a remote office. The
a set of boundaries that are
configured for a protected
secondary site boundaries are enabled as local roaming
distribution point, the management boundaries. You designate a protected distribution point
point provides the client with a list of at the remote office and include the site boundaries in
distribution point locations that the protected distribution point configuration. Only
contain the requested package Advanced Clients that are in the boundaries of the
source files. If the client is outside ofprotected distribution point use the protected
the boundaries configured for a
distribution point to download or run package
protected distribution point, then the
management point does not provide
programs. These clients avoid using the parent primary
the protected distribution point to site distribution point, unless the advertised package is
the client as a source file location. not available at the protected distribution point. This
can occur if you inadvertently send an advertisement to
clients in the protected distribution point’s boundaries before the package source files are copied
to the protected distribution point. Similarly, Advanced Clients in the primary site do not
download or run package programs from the remote office’s protected distribution point.
The protected distribution point provides bandwidth protection for package run and package
download only. It does not prevent the Advanced Client from communicating with its assigned
management point in the absence of a proxy management point for inventory data, status
messages, and Advanced Client policy requests.
Regional roaming and global roaming
If Active Directory is not available, or if the Active Directory schema for SMS is not extended,
Advanced Clients can roam only to the lower level sites of their assigned site. This is called
regional roaming. In regional roaming, the Advanced Client can roam to lower level sites and
still receive software packages from distribution points.
42 Chapter 2 Understanding SMS Sites

When an advertisement is sent to the Advanced Client, the client receives information about the
advertised package location from its assigned management point. Or, if the client has roamed into
a secondary site, it receives information about the advertised package location from a proxy
management point, if one is available. The client then uses the distribution points of one of its
assigned site’s lower level sites. Which distribution point it uses depends on which roaming
boundary the client is in and whether the advertised package is available on the distribution
point.
Global roaming allows the Advanced Client to roam to higher level sites, sibling sites, and sites
in other branches of the SMS hierarchy and still receive software packages from distribution
points. Global roaming requires Active Directory and the SMS Active Directory schema
extensions. Global roaming cannot be performed across Active Directory forests.

SMS Hierarchy
Most LANs are confined to a single building or group of buildings. However, one LAN can be
connected to other LANs by telecommunication lines. In the simplest LAN environment, it is
possible to manage your entire organization as one SMS site. However, organizations with
100,000 or more clients probably cannot be managed effectively as one SMS site.
With SMS, you can organize your enterprise into several SMS sites interconnected by WAN
links. Each site has an SMS site server. An SMS hierarchy defines the relationship of all of the
SMS sites in an organization that report to one central site.
Because SMS summarizes and compresses data that it passes among sites, it is more efficient to
include a hierarchy of SMS sites if your organization has large networks or networks connected
by slow links. After you install a primary site, you create an SMS hierarchy by adding primary or
secondary child sites.
Figure 2.5 illustrates a three-tier SMS hierarchy with four sites. The Chicago site at the top of the
hierarchy is the central site. The NYC and London sites are both primary sites and both are child
sites of the central site. The Milan site is a secondary site that is a child site of the London site.

Note
It is not always necessary to create an SMS hierarchy. For example, in a
simple LAN environment, it is possible to manage your entire organization
with one SMS site. Generally, each physical location in your organization has
at least one SMS site. For more information, see Chapter 8, “Designing Your
SMS Sites and Hierarchy.”
SMS Hierarchy 43

Figure 2.5 Sample SMS hierarchy


Primary site
Chicago
(parent site)

Central site server


SMS site database
(SQL Server)

Primary site Primary site


NYC London
(child site) (parent site and child site)

Site server Site server


SMS site database SMS site database
(SQL Server) (SQL Server)

Secondary site
Milan
(child site)

Site server

Hierarchy Modeling Concepts


Although it is possible to organize your computers into one large SMS site, or into an assembly
of unconnected sites, most SMS environments are based on a carefully planned hierarchy of
interconnected sites.
44 Chapter 2 Understanding SMS Sites

In general, management and configuration data moves down the hierarchy from higher level
sites. Resource and client data move up the hierarchy from lower level sites. More specifically, a
parent site sends management instructions and data intended for client distribution down to its
child sites. Child sites report their status up to their parent sites. This status includes the
information it gathers from SMS clients, such as computer inventory data and SMS system status
information. Before you plan your SMS hierarchy model, you need to understand some basic
modeling concepts.
The model simplifies viewing and managing large numbers of computers
You can view the SMS hierarchy, including the current site and all of its lower level sites, in the
SMS Administrator console.
The model scales to meet the needs of organizations of all sizes
Some organizations require only a single SMS site. But most organizations, especially those that
are growing and experiencing rapid changes, need to divide the organization into a number of
related sites to simplify systems management.
The model enables you to map SMS to your existing logical network
Each site consists of one or more IP subnets or Active Directory sites. You can set your site
boundaries to permit distributed site management, and to avoid intrasite network traffic over
slower WAN links. For example, if your network structure requires that computers in
Los Angeles be managed independently of computers in New York, you can create an SMS
hierarchy to support this structure.
The model works efficiently across both WAN and LAN links
Management policies, software distribution packages, and inventory information are efficiently
passed between sites, while most actual management tasks are performed within a given site. By
using this approach, you use a LAN for the tasks that require the greatest bandwidth and to
maintain centralized management over WAN links. Remote site installations with a slow or
unreliable network connection to the rest of the organization can also receive software
distributions through the SMS Courier Sender.
The model is conducive to a phased SMS deployment
You can install primary sites individually and verify that each site is working satisfactorily
before combining the sites into a hierarchy. By using this method, you build the hierarchy when
you are ready or as your needs require it.

Flat vs. Deep Hierarchy Model


Organize your site structure to fit your organization and management requirements. An SMS
hierarchy can be flat or deep, and it can have few or many sites.
Flat A hierarchy that has relatively more secondary sites (or primary sites that do not have any
child sites) reporting to the central site than it has primary sites with child sites reporting to the
central site. Typically, this type of hierarchy has three or less tiers, with many site servers at the
upper tiers.
SMS Hierarchy 45

Figure 2.6 Sample flat hierarchy


Central Site
NY1

Primary Secondary Secondary Secondary Secondary Secondary


Site Site Site Site Site Site

Secondary Secondary
Site Site

Deep A multitiered hierarchy made up of child primary sites with a small number of secondary
sites reporting directly to each primary site. A deep hierarchy usually contains three or more
tiers, with fewer site servers at each tier. The more tiers and the fewer child sites in your
hierarchy, the deeper it is.
Commonly, sites in a deep hierarchy are large sites. There might be multiple sites on the same
LAN due to scalability limitations or because your organization does not grant the scope of
control of the entire enterprise to a single IT team.
46 Chapter 2 Understanding SMS Sites

Figure 2.7 Sample deep hierarchy


Central Site
CH1

Primary Primary
Site Site

Secondary Primary Primary


Site Site Site

Secondary Secondary
Site Site
Site Communications 47

Building the SMS Hierarchy


The first site you install becomes your initial administrative site. It does not need to become your
central site or remain your administrative site. You continue to attach primary sites, install
secondary sites, or both until you have created the hierarchy you want.
Building a hierarchy involves choosing a primary site to serve as the central site and then making
the central site the parent to other primary sites. This creates a hierarchy branch. The bottom of
the branch is the lowest child site. The top of the branch extends to and ends at the central site.
Figure 2.6 has six hierarchy branches. Figure 2.7 has three hierarchy branches.
A site cannot have more than one parent, and a site cannot be its own parent or child. Also,
secondary sites cannot have child sites.

Site Communications
This section includes information about communications within an SMS site and about site-to-
site communications. When you design your SMS sites and hierarchy, you should also design the
communications methods between sites. Based on the type of network link that is used between
sites, you specify senders for site-to-site communications. For senders to transmit data properly,
you must also specify addresses, which are used by senders to locate sites.

Senders
Within a single site, SMS uses existing LAN connections for communication between site
systems. No special configuration is necessary. However, for site-to-site communications, the
link between site servers is presumed to be slow and potentially unreliable. SMS uses senders to
provide reliable communication between sites.
48 Chapter 2 Understanding SMS Sites

Senders are communication routines that are used to transport information from one site server to
another site server in the hierarchy. For example, a child site sends inventory data, discovery
data, and status information to its parent site by way of a sender. A parent site sends package
information, advertisements, collections, and configuration data to its child sites by way of the
sender.

Note
There are some types of site-to-site communications that do not use senders
or abide by sender scheduling. These include:
u SMS Administrator console connectivity to a site elsewhere in the
hierarchy.
u Remote Tool connectivity to clients of other sites.
u Communication between clients and the server locator point.
u Communication between Advanced Clients and their assigned
management point.
u Communication between a proxy management point and the SMS site
database.

Senders do not provide a physical connection to another site. They use existing network
connectivity systems to manage connections, ensure integrity of transferred data, recover from
errors, and close connections when they are no longer necessary.
When you attach one site to another, you must configure the senders that the site uses to
communicate with other sites. Table 2.3 shows the different types of senders that SMS supports.
Table 2.3 Types of Senders
Sender Description
Standard Sender Used in all LAN communications. Standard Sender
is also used for WAN communications when routers
are used to connect LAN segments.
RAS Senders Used to operate over remote access service (RAS)
connections. There are four types of RAS senders:
Asynchronous RAS For RAS communications over
an asynchronous line.
ISDN RAS For RAS communications over an ISDN
line.
SNA RAS For Systems Network Architecture (SNA)
communications over a RAS line.
X25 RAS For RAS communications over an X.25
line.
Courier Sender Used to send and receive SMS packages through
CDs, floppy disks, or tapes. Courier Sender is
typically used to send large volumes of data when
available bandwidth is insufficient to transport the
data.
Site Communications 49

If a sender requires another communications service to connect to other sites, you must install
that service on a computer at the site. For example, to use the SNA RAS Sender, you must install
RAS and Microsoft SNA Server on a computer running Windows 2000 or an operating system in
the Windows Server™ 2003 family, and then configure the computer running SNA Server to use
RAS over SNA.

Addresses
For an SMS hierarchy to function properly, the sites in the hierarchy must communicate with
each other. In particular, each site must communicate with its parent site and with its immediate
child sites. Occasionally, a site might also need to communicate with other sites in the hierarchy.
For example, you might need to send a package from a primary site to an indirect child site.
Senders are useless without addresses. Addresses tell senders where to find the site servers of
destination sites. An address is an identifier for a network node that differentiates it from other
nodes on the network.
Addresses are sender-type specific, which means that the sending site needs both a different
address for each destination site and a different address for each type of sender that is used. To
ensure that data is sent and received if the first address is not available, you configure multiple
SMS addresses for each site.
For software distribution, SMS 2003 sites communicate using package routing. During package
routing, communications are passed down a hierarchy from site to site. This means that a site
requires addresses for its parent site and child sites but not for other higher level or lower level
sites.
For more information about choosing senders and planning for addresses, see Chapter 10,
“Planning Your SMS Deployment and Configuration.”

Note
If a site loses its connection to other sites, the site continues to collect
inventory and software metering data, distribute software, and maintain
contact with and run scheduled instructions on its client computers. When
the connection is restored, the site synchronizes its status and data with its
higher level sites.
C H A P T E R 3

Understanding SMS
Features

This chapter describes how the primary features of Microsoft® Systems Management Server
(SMS) 2003 work and how you can use each of those features to benefit your organization. After
explaining each feature individually, this chapter describes how features are integrated to
perform common tasks in an organization.
This chapter introduces several primary features of SMS, such as software and hardware
inventory. It also includes features that help monitor the activity of SMS and maintain healthy
SMS sites, such as backup and recovery.
The implementation of some features on the Advanced Client is different than on the Legacy
Client, specifically taking advantage of the Advanced Client architecture. This chapter describes
those differences for each primary feature.

In This Chapter
u Collections and Queries
u Hardware and Software Inventory
u Software Distribution
u Software Update Management
u Software Metering
u Remote Tools
u Reporting
u Product Compliance
u Status System
u Backup and Recovery
u Network Monitoring Tools
u Integrating Features
52 Chapter 3 Understanding SMS Features

This chapter assumes that you are familiar with SMS hierarchies, site systems, and SMS clients.
For information about SMS hierarchies and site systems, see Chapter 2, “Understanding SMS
Sites.” For information about SMS clients, see Chapter 4, “Understanding SMS Clients,” and
Chapter 17, “Discovering Resources and Deploying Clients.”
For more information about the features introduced in this chapter, see the respective chapters in
the Microsoft Systems Management Server 2003 Operations Guide.
Collections and Queries 53

Collections and Queries


SMS collects and uses a large amount of data to manage sites. That data is stored at each primary
site’s database. Different SMS administrative tasks require different sets of data from the SMS
site database. Queries are run against the site’s database and retrieve specific data according to
the criteria of the query. SMS provides many predefined queries. If required, you can create
additional queries. A query can retrieve information about a specific client or summary
information about multiple clients.
SMS manages resources, such as users, user groups, and client computers. Each resource is
associated with a unique set of attributes. Data about resources and their attributes is stored in the
site’s database. Collections are logical groups of SMS resources that satisfy criteria defined by
the administrator. Collections are designed to gather resources into useful groups that you can
manage within your site hierarchy.
You can create a collection by defining rules that add individual resources to the collection. More
often, you define rules that are based on a query for an attribute that resources have. This creates
a collection of resources with one or more common attributes. The rules that you use to define
the collection’s member list are referred to as the collection’s membership rules.
Query-based collections are dynamic objects. If a resource no longer meets the collection’s
query, it is automatically removed from the collection. And if a resource that originally did not
meet the collection’s query has changed in a way that it now meets the collection’s query, it is
automatically added to the collection. This behavior greatly reduces and simplifies the
administrative work of managing the clients.
SMS 2003 includes several predefined collections that query for Windows®-based operating
systems. An important predefined collection is the All Systems collection, which is defined to
include all resources in the site. This means that every new resource in the site automatically
becomes a member of the All Systems collection. It is recommended that you do not modify the
definition of this collection.
Collections and Queries Throughout the Site Hierarchy
When you create a collection, SMS evaluates the membership rules to determine which resources
should become members of that collection. If the collection is based on a query, SMS runs the
query against the site database. In an SMS hierarchy, primary site databases do not contain data
about resources from upper level sites. The current site’s collections cannot contain resources
from upper level sites.
When you create collections at a parent site, SMS propagates them to lower level primary and
secondary sites. You can modify or delete collections only at the site that they were created in. At
child sites, you cannot modify collections that were propagated from an upper level site. Queries
are not propagated to lower level sites.
54 Chapter 3 Understanding SMS Features

When SMS propagates a collection, primary child sites receive only the definition of the
collection. This includes the collection’s general data and its membership rules, but it does not
include the actual list of clients that are members of that collection. Each primary child site
evaluates the propagated collection’s membership rules. If the collection is based on a query, the
query runs against the current SMS site database. This process generates the member list for the
propagated collection, which has two advantages:
u Less information is transmitted over the network.
u It is easier for SMS to keep the membership list of the collection up to date at child primary
sites.
When SMS propagates a collection, secondary child sites receive only the list of clients that are
members of the collection. They do not receive the collection definition. Because secondary sites
do not maintain their own database, the secondary site’s parent site evaluates the collection’s
membership rules for the secondary site and generates the membership list. The membership list
includes resources from only the secondary site. When a collection is re-evaluated at the parent
site, the parent site sends updated membership lists to its secondary sites.
Occasionally, you might want to share a collection or a query with administrators of SMS sites to
which the collection or the query is not automatically propagated. To accomplish this, you can
use the Export Object Wizard to export collection and query object definitions from your SMS
site database to a Managed Object Format (MOF) file.

Note
MOF is a standard text file that contains computer management information
in a standard format that can be loaded into the SMS site database.

You can use the Import Object Wizard to import these MOF files back into the site’s database or
into another site’s database. However, when running a query that was imported from another site,
it runs against the current site’s database.
Benefits of Collections and Queries
Some SMS features can operate on clients only if they are members of a collection. For example,
to distribute software to clients in the hierarchy, you must first create a collection that includes all
the clients that need to receive the distributed software. For other features, such as inventory, the
resources must be members of a collection to view their inventory data in Resource Explorer.
Resource Explorer is an application that you can launch from the SMS Administrator console to
view inventory data for resources in the hierarchy.
Often, the collection’s membership rules are based on a query. You create a query with the
criteria that the desired set of resources will satisfy, such as all clients that are running Microsoft
Windows XP. Then you define a collection that is based on the query. The query searches the
SMS site database. All the resources in the site’s database that satisfy that query become
members of the collection. By using the Windows XP query, all clients running Windows XP
become members of that collection.
Hardware and Software Inventory 55

SMS provides a number of predefined queries that you can use. You can modify a predefined
query or create new queries. By running queries, you can retrieve the list of all clients running a
specific operating system or all clients with an almost full hard disk drive. This information helps
you anticipate software and hardware upgrades and can help you make other administrative
decisions.
With SMS 2003, you can leverage Active Directory® domains, organizational units, groups, and
sites when defining collections. If Active Directory is deployed with logical organization units,
sites, and security groups, and if a large number of computers are running Microsoft
Windows 2000 or later, then you can benefit from this capability by creating collections based on
Active Directory containers. These collections can be used for software distribution.

Hardware and Software Inventory


The SMS inventory feature inventories data from the site’s clients. The inventory feature refers
to both the hardware inventory and the software inventory features.
The SMS hardware inventory feature automatically collects detailed information about the
hardware characteristics of clients in an SMS hierarchy. By using this feature, you can collect a
wide variety of information about client computers such as memory, operating system,
peripherals, services, and processes that are running on the client computer.
The hardware inventory feature collects data from client computers by querying several data
stores on client computers such as the registry and the Windows Management Instrumentation
(WMI) classes. Hardware inventory does not query for all possible WMI classes, but it does
provide approximately 1,500 hardware properties that include data such as the device ID of a
tape drive, the manufacturer of a CD-ROM drive, the current size of the registry, and the primary
partition of a disk.
By using hardware inventory, you can also collect basic information about client software. You
can collect information about the applications listed in Add or Remove Programs in Control
Panel. By using software inventory, you can collect a significantly larger amount of information
about client’s software.
The software inventory feature collects detailed file information, and can copy files, from clients
in an SMS site to the site server. By using software inventory, you can gather information such as
file size, file date, file path, and the name of the product that a file is part of. Software inventory
can also store copies of client files at the site server, so that you can view these files later.
SMS can collect a comprehensive inventory that includes all the information about all the files
from all the client’s hard disk drives, it can collect information from a narrow set of files, or it
can collect information from a single file. You can restrict the file information that is collected to
certain details, and you can restrict the inventory collection to specific file names or specific file
extensions by using wildcards and environment variables. You can further narrow the inventory
collection by excluding specific disk drives, specific directories, and compressed or encrypted
files.
Hardware and software inventory provide the same functionality on the Advanced Client and on
the Legacy Client.
56 Chapter 3 Understanding SMS Features

How Hardware Inventory and Software Inventory Work


You can enable or disable hardware inventory or the software inventory for an SMS site. When
either feature is enabled for the site, you can configure it to accommodate your organization’s
requirements.
When you enable and configure hardware inventory or software inventory at the primary site,
SMS installs the appropriate client agent components on all Legacy Clients in the site (these
components are preinstalled on Advanced Clients) and starts to collect inventory according to the
specified schedule. The Hardware Inventory Agent and the Software Inventory Agent run on
Legacy Clients. The Inventory Agent runs on Advanced Clients. These client agents primarily
collect data from the client computers. They also perform other inventory-related tasks on clients.
Hardware inventory is configured by using the file SMS_def.mof, which includes the hardware
attributes that are collected by SMS. Administrators can customize the SMS_def.mof file so that
SMS collects the hardware attributes that are needed by the organization. This file is stored in the
\SMS\Inboxes\Clifiles.src\Hinv directory on site servers, at the site’s database, and in an up-to-
date copy of the file that is stored on the site’s Legacy Clients.
SMS uses the SMS_def.mof file that is stored in the SMS site database to create the appropriate
Advanced Client policy for Advanced Clients. Advanced Clients retrieve from management
points Advanced Client policies, which were sent from the site server. Advanced Client policies
contain site configuration information and other information that Advanced Clients need.
u When the Hardware Inventory Client Agent runs on the Legacy Clients to collect inventory,
it reads the SMS_def.mof file and collects only the attributes that are enabled in the
SMS_def.mof file.
u When the Inventory Client Agent runs on Advanced Clients, it uses the Advanced Client
policy (that was generated based on the SMS_def.mof file) to collect only the attributes that
are enabled in the SMS_def.mof file.
Software inventory uses inventory rules to determine what inventory data needs to be collected.
Administrators can customize software inventory rules, so SMS collects software information
needed by the organization.
SMS uses these inventory rules to create the appropriate Advanced Client policy for Advanced
Clients. The Software Inventory Client Agent is configured by using these inventory rules. When
the Software Inventory Client Agent runs on Legacy Clients, it uses the inventory rules to collect
only the requested inventory data. When the Inventory Client Agent runs on Advanced Clients, it
uses the Advanced Client policy to collect only the requested inventory data.
During the collection of inventory data on the client, SMS creates an inventory data file, in which
the inventory agents store the collected data. The inventory data file and copies of any collected
files are sent from Legacy Clients to a client access point (CAP) and from Advanced Clients to a
management point, and then to the primary site server. At the primary site server, the file is
processed and the data is entered into the SMS site database. Copies of collected files are stored
at the site server.
Hardware and Software Inventory 57

With every hardware inventory collection, SMS updates the database with changes, while
keeping track of every change. This builds hardware inventory history for each client. With every
software inventory collection, SMS updates the most recent inventory data in the SMS site
database; thus, keeping only the current software inventory data for each client.
During the first data inventory collection, the inventory agents perform an initial inventory
collection. This is a complete inventory collection, which includes a complete hardware
inventory as specified in the SMS_def.mof file and a complete software inventory as specified by
the software inventory rules. The initial inventory establishes the baseline for future inventory
collections.
Subsequent inventory collections are performed at the specified schedule; however, these are
usually delta inventories. During delta inventory, only changes since the last inventory collection
are stored in the inventory data file. This greatly reduces the network traffic because the delta
inventory data is usually only a fraction of a complete inventory collection.
Rarely, there is a need to perform a complete inventory collection again. However, if delta
inventory data is determined to be out of synchronization with the latest inventory data, then
instead of performing the usual delta collection, SMS performs an inventory resynchronization
and re-establishes the inventory baseline. This corrective action happens when:
u Inventory rules (either SMS_def.mof or the software inventory rules) have changed since the
last inventory collection. This affects Legacy Clients only. Advanced Clients do not perform
a resynchronization inventory at the event of inventory rules change.
u An attempt is made to update inventory data that does not exist in the SMS site database.
This can happen if, for example, there are network problems or if a client has been
disconnected for a long time and the inventory reports are arriving out of order.
u The inventory data is corrupted.
u A client has changed sites since the last inventory collection.
u A client upgrades from SMS 2.0 to SMS 2003.
Because changes to inventory rules do not trigger a resynchronization on Advanced Clients,
Advanced Clients have much less resynchronizations compared with the Legacy Client.
58 Chapter 3 Understanding SMS Features

Figure 3.1 Inventory process


Central site

Primary site Site server/


Site database server

Site
server Site
database
server

Management
point

Advanced Client
CAP Inventory Client Agent

Legacy Client
Primary site Hardware Inventory Client Agent
Software Inventory Client Agent

Site
server Site
database
server

Management
point

Advanced
CAP Client

Legacy
Secondary site Client

Site
server

CAP
Legacy
Client
Hardware and Software Inventory 59

Figure 3.1 illustrates the components that participate in the hardware and software inventory
process. It describes how the inventory data file moves through the SMS hierarchy.
1. When you enable hardware inventory or software inventory for a site, SMS enables these
features on the site’s clients:
u SMS installs the Hardware Inventory Client Agent or the Software Inventory Client
Agent on all Legacy Clients in the site (the agent is preinstalled on Advanced Clients).
u SMS sends to management points the Advanced Client policy that enables the Inventory
Agent on Advanced Clients.
2. SMS configures the inventory client agents according to the settings in the SMS_def.mof
file, software inventory rules, and the schedule as follows:
u SMS stores information on CAPs about the site server settings for inventory. Legacy
Clients later download this information and use it to configure the Hardware Inventory
Client Agent or the Software Inventory Client Agent.
u SMS stores (at the SMS site database) Advanced Client policies that correspond to the
server settings for hardware inventory or software inventory. Management points then
retrieve these policies from the SMS site database on requests made by Advanced
Clients. Advanced Clients use the policies to configure the Inventory Agent.
3. The inventory agents start to run according to the specified schedule. Every time they run,
they collect inventory data from the clients and store that data in an inventory data file.
4. On Advanced Clients, the inventory data file is sent to a management point. On Legacy
Clients, the inventory data file is sent to a CAP.
The CAP or management point sends the inventory data file to the site server. If the site is a
secondary site, then the inventory data file is propagated to upper level sites.
5. The primary site server processes the inventory data file and stores the information in the
site’s database.
If the primary site server is not the central site server, then it sends the inventory data file to
its parent site. The site also sends inventory data that it received from any lower level sites
on which inventory is enabled. This step is repeated until the inventory data reaches the
central site.
At the end of this process, every primary site contains the inventory data of the site’s clients
and of clients of lower sites in the hierarchy.
60 Chapter 3 Understanding SMS Features

6. You can view hardware or software inventory data in the SMS Administrator console and
use it to create queries, collections, and reports. When viewing hardware inventory data, you
can view the history of each class as it has been reported during previous hardware inventory
collections. When viewing software inventory, only the current state is displayed. Software
that was previously installed on a client, but currently is not installed, is not displayed.
Each site contains inventory data from the site’s clients and from all lower level sites’ clients
(the central site contains inventory data from clients A, B, C, D and E, while the midtier
primary site contains inventory data only from clients C, D and E).
Several capabilities that are unique to Advanced Clients are leveraged in the implementation of
software and hardware inventory. These capabilities are very useful in unique situations that
Advanced Clients might often encounter, such as non-continuous connectivity to the network and
slow link connection.
u Inventory is always collected on the Advanced Client according to the specified schedule.
However, if the client is unable to send the inventory data file to a management point
because the client’s computer is offline, the inventory data file is sent as soon as connectivity
is re-established.
u The Advanced Client leverages Background Intelligent Transfer Service (BITS). When an
inventory data file is larger than 50 KB, BITS is used to send the file as a message
attachment.
Hardware Inventory and Software Inventory Throughout the Site Hierarchy
The hardware and software inventory features are configured per site. When you enable either
feature for a site, SMS collects inventory data from all the clients assigned to that site. SMS
stores that data at the SMS site database and propagates it up the hierarchy, from one primary site
to its parent, until it reaches the central site. The inventory data is stored in the database of each
primary site to which it was propagated. At the end of this process, every primary site contains
the hardware inventory data of the site’s clients and of clients of lower sites in the hierarchy.
You can then use any of the client’s upper level sites to perform management tasks that require
the client’s hardware or software inventory data, for example, running the All Systems with
Hardware Inventory Collected query. You can use the central site, which has inventory data of all
the clients in the hierarchy, to perform management tasks that require inventory data on any
client in the hierarchy.
See Figure 3.1 to see how inventory data propagates up the hierarchy and which client’s data
inventory is stored at each site in the hierarchy.
Benefits of Hardware Inventory
You can use hardware inventory data to effectively perform many administrative tasks in your
organization, the most important one being helping to manage IT assets. Use hardware inventory
to administer tasks such as maintaining corporate hardware standards, tracking asset
depreciation, locating computers, troubleshooting computers, and distributing software.
Hardware inventory provides you with important information, such as the configuration and
location of computers, which computers require an operating system upgrade, and which
computers have the hardware that is required for a software upgrade.
Hardware and Software Inventory 61

You can access the hardware inventory data that is collected by SMS in various ways. You can
view current and historical hardware inventory data for individual clients in the SMS
Administrator console by using Resource Explorer. Viewing recent changes to a client’s
hardware can assist in diagnosing client problems. From the SMS Administrator console, you can
run a query to search for specific hardware inventory data or run a predefined report to display
hardware inventory data in an organized report format. SMS provides many predefined reports
that can display hardware inventory data, but these reports are meaningful only if the SMS site
database contains hardware inventory data from clients.
The hardware inventory feature can help maintain corporate standards for computer hardware.
For example, if an organization has a processor speed standard, the administrator can use
hardware inventory to collect information about the processors of clients and then generate a
report that shows which clients are not in compliance with that standard.
In large organizations, physically locating a specific computer can be a time-consuming task.
Using hardware inventory data such as IP addresses, subnets, and domain names can help you
easily track the physical location of every computer in the organization. This can be important if,
for example, computers are leased and must be located and returned on a certain date.
Hardware inventory data can be used to create collections where members have a common
hardware characteristic that you specify. You can then distribute software to these collections.
For example, you might want to distribute software only to clients that meet the minimum
hardware requirements for that software.
Customizing hardware inventory
The SMS_def.mof file provides a wide range of information that you can collect about client
hardware. However, in your organization, you might need data that is not readily provided by the
hardware inventory feature. In this case, you can extend the inventory set by using custom MOF
or custom Management Information Format (MIF) files.
u Custom MOF files allow you to add WMI classes that are not included in the original
SMS_def.mof file.
u Custom NOIDMIF MIF files extend the current inventory set by adding new inventory
properties to each client. By using NOIDMIFs, you can collect additional information about
each computer, such as asset number or office number.
u Custom IDMIF MIF files extend the current inventory set by adding new architectures to the
database. By using IDMIFs, you can collect information about new entities such as a shared
network printer.
By using custom MIF files, hardware inventory can help in tracking asset depreciation by
collecting purchase dates of the computers in the organization. By using this data, the
administrator can determine the total depreciation of assets in the organization. This can prevent
paying unnecessary taxes on assets that have depreciated and help plan future hardware
purchases.
62 Chapter 3 Understanding SMS Features

Benefits of Software Inventory


You can use software inventory data to effectively manage software in your organization.
Software inventory data provides you with important information, such as how many copies of a
specific software application exist in your organization or on how many computers in your
organization have the latest antivirus program installed. Collected files can help troubleshoot
client problems. For example, if a client is experiencing problems, you can open at your desktop
a copy of the client’s recent log files that were previously collected.
You can view software inventory data and a list of collected files in the SMS Administrator
console by using Resource Explorer. The software inventory data that is displayed in Resource
Explorer reflects the current state of the client. Unlike the hardware inventory feature, no
historical data is available. You can view software inventory data organized by files or by
products, and you can open at your desktop any file that was colleted from clients.
You can run queries to retrieve selected software inventory data from the SMS site database and
run a report. SMS provides predefined reports that are meaningful only if the database contains
software inventory data from the site’s clients. Use reporting to display software inventory data
from the entire organization in an organized report format.
The software inventory feature is useful for software distribution. Software inventory data can be
used to create collections that are based on file or product data. You can then distribute software
to these collections. For example, you might want to distribute an antivirus program only to
clients that do not have this program installed.

Software Distribution
The SMS software distribution feature automates the distribution of programs to SMS clients.
These programs run on the client computers to perform tasks such as installing software or
scanning the client’s hard drives for viruses.
Using software distribution eliminates the inefficient process of providing thousands of software
CDs to users, along with programs and instructions. The automated process of program
distribution eliminates user errors such as entering incorrect values in prompts, running incorrect
programs, or entering incorrect arguments. By using software distribution, clients can
successfully run programs and install software without needing to know how to run these
programs or which setup options are best for them. Clients do not need to manage their own
software installations. Instead, you centrally define and control how and when programs run on
client computers. You can choose how little or how much users manage.
Central management of the software distribution in your organization allows you to monitor the
distribution process from beginning to end. SMS generates detailed status messages that allow
you to monitor individual clients and to provide assistance to those clients that are having
difficulties running a program.
Software Distribution 63

For clients with Windows Terminal Services (Remote Administration mode or Application
Server mode) enabled, software distribution icons and messages are limited to the console
session. On clients that are remote controlled by using Remote Assistance, Remote Desktop, or
SMS Remote Control, software distribution icons function regularly. Software distribution
functionality to site systems that have Windows Terminal Services enabled is limited.
Using collections for software distribution
You can easily make software products available to as many computers in your organization as
you want. The clients that need to receive the program must be members of a collection (referred
to as the target collection). The target collection can contain a single client, all the clients that are
assigned to a specific site, or any subset of clients. When the program is distributed to the target
collection, all the clients that are members of that collection receive the program. This allows you
to distribute programs to specific users, specific user groups, and any group of client computers
that share a common set of hardware or software attributes.
If Active Directory is implemented in your organization, you can target a collection that is based
on Active Directory containers. You can create a collection that targets systems based on
organization units, domains, site, and/or group membership, or you can create a collection that
targets users based on domains, organization units, and/or group membership. To target systems
for software distribution, using active directory containers, at least one of the Active Directory
discovery methods must be enabled at the site.
Collections, in which membership rules are based on queries, are dynamic. After the initial
membership list is created, clients are automatically added to or removed from the collection, as
appropriate. Client computers that initially did not meet the collection’s criteria, but meet the
criteria now, automatically become members of the collection. Clients that initially meet the
collection’s criteria, but then no longer meet the criteria, are automatically removed from the
collection (this does not result in the clients being uninstalled). In a dynamic environment, SMS
keeps collections current, thus ensuring that only the appropriate clients receive distributed
programs.
The following scenario illustrates the benefits of this behavior:
1. You distribute a program to the “All Windows XP Systems” collection.
2. Only client computers running Windows XP receive the program.
3. A few client computers running Microsoft Windows 98 upgrade to Windows XP.
4. The newly upgraded clients automatically become members of the “All Windows XP
Systems” collection.
5. The program that you distributed to the “All Windows XP Systems” collection automatically
becomes available to the newly upgraded clients (along with any other programs that are
available to the “All Windows XP Systems” collection).
Software distribution objects
The purpose of using the software distribution feature is to automatically make a program
available to target clients. A program can be a file name (SMS uses file association to run such
programs) or anything else that can run from a command line, such as a batch file, a Windows
Installer command line, or a utility developed by your organization.
64 Chapter 3 Understanding SMS Features

Programs often need to download files to the client when they run, for example, installation
programs must download installation files. The files that a program requires when it runs are
called package source files.
Sometimes, more than one program can be associated with the same set of source files. For
example, there can be several variations of a setup program that install the same software by
using the same source files. However, each setup program runs differently and provides different
setup options, such as running without user intervention or performing an upgrade rather than a
full installation. To provide clients with all these setup options, you need to define several
programs for the same set of source files.
A copy of the source files must be distributed to one or more servers, accessible to clients, so that
when the program runs on client computers, it can access the files that it requires. The
distribution point is an SMS site system that has that role. The administrative task of copying the
package source files to distribution points is called package distribution. Some programs are not
associated with source files. In this case, either the programs use files that are already stored on
the client computers or access to the required files is coordinated outside of the SMS software
distribution. For example, the command line Defrag.exe might not be associated with source
files. In this case, when the program runs on client computers, a local copy of Defrag.exe runs.
Programs, source files, and source file paths are the main components that make up a software
distribution package. A package is the basic unit of software distribution.
Packages vary widely, depending on their purpose. A package might have source files associated
with it. A package typically has at least one program and can have as many programs as needed.
Programs have a wide range of configurable options such as security context, supported
platforms, and environment requirements. The program’s command line can be anything from
setup programs to simple batch command lines.
Another object that is associated with software distribution is the advertisement. Advertisements
are the objects that make programs available to clients. You must advertise a program before
clients can run it. A variation of an advertisement is an assignment, which is a mandatory
advertisement that must run on the client’s computer. Advertised programs appear at the client
both in the SMS user interface and in Add or Remove Programs in Control Panel.
Package definition files
You can create a package by defining the package’s properties in the SMS Administrator
console. An alternative, non-interactive way to create a package is by using a package definition
file.
A package definition file is a specially formatted file that includes all the necessary information
about an SMS package. A package definition file typically has an .sms file name extension (.pdf
in previous versions of SMS). You can also create software distribution objects by importing an
.msi file (Windows Installer) in the same way that you would import an .sms file.
To use a package definition file, you use the Create Package from Definition Wizard to import
the file. SMS then creates the package and program objects that are defined in the file. Microsoft
products and third-party applications often include a package definition file that you can use with
SMS. If a package definition file for a specific package does not exist, you can use SMS Installer
to generate one.
Software Distribution 65

SMS Installer
SMS Installer is a tool that you can use to create software installation packages. These packages
are known as SMS Installer-generated executable files, which are self-extracting files that
contain everything that is necessary to install the software. You can use SMS Installer to create a
setup program if one does not exist or to create Windows Installer (.msi) files. You can then use
software distribution to distribute these packages to clients.
SMS Installer creates a modifiable installation script that runs on client computers and controls
the installation. An installation script can have commands to perform tasks such as gather
information about the client’s system; install, search, and delete files; prompt users for
information; and update both system files and the registry. By using these commands, you have
full control of the installation process. SMS Installer provides status reporting in addition to what
SMS provides and creates package definition files.
How Software Distribution Works
To distribute a program to clients, you need to create a software distribution package and
programs and then you need to advertise the program that you want the clients to run.
Advertising the program makes a program available to a specified target collection. The
advertisement contains the name of the program, the name of the target collection, and the
scheduling configuration (such as when to run the program or when will the program expire).
However, the site’s clients will not be able to receive advertised programs until you enable the
software distribution client agents on the site’s clients. The Advertised Programs Client Agent on
Legacy Clients and the Software Distribution Client Agent on Advanced Clients perform the
software distribution related tasks on the clients. This primarily allows clients to receive and run
programs that you advertised.
You can enable or disable the software distribution feature for an SMS site by enabling the
software distribution client agents. When the feature is enabled, you can configure the software
distribution client agents and create packages, programs, and advertisements to deliver the
programs that clients need.
To use software distribution, perform the following tasks. After completing the first step, you can
perform the rest of the tasks as required.
1. Prepare the site for software distribution:
u Configure the software distribution client agents.
u Prepare CAPs, management points, and distribution points.
u Prepare collections.
u Prepare security.
2. Create packages.
3. Specify distribution points.
4. Create programs.
5. Create advertisements.
66 Chapter 3 Understanding SMS Features

Figure 3.2 Software distribution process


Central site

Primary site Site server/


Site database server

Site
(A)
server
Management
point

Distribution
point

CAP (A) Advanced Client


Software Distribution Client Agent

(A) Legacy Client


Primary site Advertised Programs Client Agent

Site (B)
server
Management
point

Distribution
point

CAP (A,B) Advanced


Client

Secondary (A,B) Legacy


site Client

Site CAP
server

Distribution
point (A,B) Legacy
Client
Software Distribution 67

Figure 3.2 illustrates the components that participate in the software distribution process. It
describes how site systems interact and how data that is related to software distribution
propagates through the hierarchy.
1. When you enable software distribution for a site, SMS enables software distribution on the
site’s clients as follows:
u SMS installs the SMS Advertised Programs Client Agent on all Legacy Clients in the
site (the agent is preinstalled on Advanced Clients).
u SMS sends the appropriate Advanced Client policy that enables the Software
Distribution Client Agent on Advanced Clients.
2. When you create a package and advertise a program, SMS stores information about the
package, program, and advertisement on CAPs and management points.
If the site has child sites, SMS propagates information about the package, the program, or
the advertisement to lower level sites. Each child site repeats that step until the information
reaches a site that has no child sites. In Figure 3.2, the clients that are assigned to the highest
primary site receive advertisement A. Clients of the secondary site receive advertisements A
and B.
3. When you choose distribution points for your package, SMS copies the package source files,
if source files exist, to the specified distribution points and updates the CAPs and
management points with the new information about the distribution points for the package.
4. The Advertised Programs Client Agent on Legacy Clients periodically checks the CAP to
determine if any advertisements are applicable to the client.
u The Advertised Programs Client Agent runs assignments automatically.
u The Advertised Programs Client Agent maintains a list of the programs that are not
assignments, allowing the Legacy Clients to individually schedule them to run at their
own convenience by using the Advertised Programs Wizard and the Advertised
Programs Monitor in Control Panel.
5. Advanced Clients periodically check the management point to determine if any
advertisements are applicable to the client.
u The Software Distribution Client Agent runs assignments automatically.
u The Software Distribution Client Agent maintains a list of the advertisements that are
not assignments, allowing the Advanced Clients to individually run them at their own
convenience. Advanced Clients can view and run programs by using either Add or
Remove Programs or Run Advertised Programs in Control Panel. Advanced Clients
cannot schedule programs to run.
68 Chapter 3 Understanding SMS Features

6. When the program runs, it might need package source files. The Advertised Programs Client
Agent checks the CAP or the management point for the list of distribution points that contain
the package source files and selects one.
u On Legacy Clients, the client agent connects to a distribution point and runs the
specified program’s command line.
u On Advanced Clients, the client agent connects to a distribution point. Depending on
different settings, it may download the package source files to the local machine before
running the specified program’s command line.
If there are no package source files, the client agent runs the program’s command line
without making any connections.
Software distribution on Advanced Clients
Some software distribution settings and capabilities are supported only on Advanced Clients.
With these settings and capabilities, Advanced Clients can better handle situations such as non-
continuous connectivity to the network and slow link connections.
u You can configure Advanced Clients to download package source files to the local computer
before running a program that requires those files. When the program runs, it gets the files
from the local computer rather than from a distribution point.
u Advanced Clients manage their download cache. When Advanced Clients download package
source files in advance, the package source files are stored in the client’s download cache.
The Advanced Client can set the cache location and size. SMS uses these settings with its
cache management logistics to attempt to allocate sufficient space when new requests to
download packages arrive.
u You can enable BITS on distribution points. BITS allows SMS to download package files
from the distribution point to the client incrementally. If a file transfer is stopped
unexpectedly, BITS can resume the file transfer from the point that it was stopped. BITS
throttles file downloads so they do not interfere with the other local applications that are
using the network. BITS uses HTTP, so that the Advanced Client can send and receive files
in any situation where an HTTP link can be established.
u If a roaming Advanced Client requires files for programs that are advertised to it, and those
files are available from any local distribution point, the Advanced Client can use a local
distribution point to access those files, without changing the client’s site assignment. This
reduces the Advanced Client’s use of the wide area network (WAN).

Note
To reduce the load on the WAN, you can specify a distribution point as a
protected distribution point. When specifying boundaries to a protected
distribution point, it prevents access to that distribution point from clients
roaming outside the specified boundaries. By using this configuration, you
can conserve bandwidth and protect a distribution point from being
overloaded.
Software Distribution 69

Software Distribution Throughout the Site Hierarchy


Any site can originate a software distribution for itself and its child sites. Package, program, and
advertisement definitions replicate automatically down the site hierarchy, whether or not the
distribution includes distribution points or target clients in the child sites. Administrators can
advertise propagated programs to clients of their site or to clients of their child sites. However,
administrators cannot modify propagated packages, programs, or advertisements. It is possible to
distribute a propagated package to local distribution points, but the originating site always
remains the owner of the package and has full control over all of its objects.
Although collections, packages, programs, and advertisements propagate to child sites, package
source files do not. Because Legacy Clients cannot cross site boundaries to gain access to
distribution points, you must specify at least one distribution point for the package in each site
containing target clients. If the package does not contain source files, then distribution points are
not involved in this process.
When a distribution point in a child site is first added to a package’s distribution point list, the
package source files are compressed and sent to the child site’s site server. There, the source files
are decompressed and copied to the specified distribution points in that site. The compressed
version of the source files is kept at the child site, and if a new distribution point in that site is
specified for the package, the child site server again decompresses the package source files and
copies them to the new distribution point.
Figure 3.2 shows how software distribution objects propagate down the hierarchy.
When there are changes to source files of a package and you need to update the package source
files on the sites that already contain the package, SMS minimizes network traffic by sending
only the updates through the network, rather than sending the entire set of source files.
Using fan-out
When distributing packages to child sites, you can reduce the workload on the initiating site by
using the fan-out feature. The fan-out feature allows sites to distribute package content to lower
level sites through child sites, rather than directly. Fan-out distribution occurs automatically if the
initiating site does not have an SMS address for the destination site. For example, if a site needs
to distribute a package to its child site and to its grandchild site, the originating site has two
options:
1. Distribute the package to the child site and to the grandchild site. This happens if the
initiating site has addresses to both sites.
2. Use the fan-out feature and distribute the package only to the child site. The child site then
distributes the package to its child site, which is the grandchild of the originating site. This
happens if the initiating site has the address of the child site and only the child site has the
address of the grandchild site.
Besides reducing the workload of the initiating site, this also reduces the load on the network link
between the initiating site and the rest of the sites, which is often a significant issue. This is
especially efficient when distributing large software packages such as Windows XP. Figure 3.3
describes the added load on the central site when fan-out is not used.
70 Chapter 3 Understanding SMS Features

Figure 3.3 Software distribution with and without fan-out

Central Central
Site Site

Site Site Site Site


ABC DEF ABC DEF

Site Site Site Site Site Site


MNO PQR STU MNO PQR STU

With Fan-out Without Fan-out

Benefits of Software Distribution


With software distribution, you can centrally manage software in your organization in an
efficient manner. You can simultaneously upgrade all the computers in your site with a new
software installation, run a virus scan utility on all client computers on a regular basis, or
distribute a licensed application to a small subset of your users. You can distribute a Windows
Installer package that is configured with the elevated rights install mode and SMS will then run
the administrator setup portion under administrative context (localsystem) and the user setup
portion under the current user context.
SMS provides a wide set of settings for the distributed programs. This gives you flexibility in the
type of programs that you can advertise and in the way these programs run on the client
computers.
You can specify an event that must happen before a program runs, such as a user logon. You can
specify an action that will be automatically performed after a program completes, such as a
reboot or a user log off. This is useful especially with operating system upgrades, but you can use
it with any program that requires a restart to complete.
Programs are available to clients through Add or Remove Programs in Control Panel. This
allows software that is distributed by SMS to be added or removed from the client’s computer in
the same manner that other, non-SMS distributed programs are added or removed. You can
define categories for your programs so that users can filter on those categories in the Add or
Remove Programs dialog box and find the programs that they need faster.
Software Distribution 71

Many scheduling options are available for advertised programs. You can schedule an
advertisement centrally, so it runs at a specified time on all clients. This program is referred to as
an assignment. This is useful for mandatory programs such as a virus scan that clients must run at
a certain time. Legacy Clients can schedule programs individually to run at their own
convenience. You can combine these two capabilities and allow clients to individually schedule
programs, but after a specified time, the program becomes mandatory for clients that did not run
the program yet. A powerful scheduling option is a recurring schedule. When you configure an
advertisement with a recurring schedule, SMS automatically runs the assigned program on a
periodic basis, as specified.
Some programs require the completion of another program before they can successfully run. The
software distribution feature allows you to configure program dependencies. This can be very
useful in setup programs in which one portion can run in the user context and another portion
requires the system context. For example, you can advertise a program to install WinZip on the
client’s computer and specify that it must complete successfully before a .zip program can run.
If a program can run unattended, you can schedule it to run on client computers at a time when
no users are logged on to the network.
Some setup programs must perform tasks that require administrative rights, but they also must
perform tasks that require the user’s context, such as adding icons to the user’s desktop. You can
create a program, which is a Windows Installer script, and configure the program to run with
administrative credentials but in the user’s context. Even if the logged on user does not have
administrative credentials, the program can run.
You can use the capabilities of the software distribution feature to perform many administrative
tasks. Some common tasks are:
u Install software on client computers, providing different installation options for the same
software.
u Use Add or Remove Programs in Control Panel to add or remove programs.
u Copy data files to client computers.
u Run utilities such as virus checks or disk defragmentation.
u Perform any function that can run from a command line.
u Distribute the Skpswi.dat file that clients can use to prevent software inventory collection
from a specific drive or a specific directory.
u Bring new computers in the organization to a corporate standard. After installing only the
operating system and SMS on a new computer, you can use software distribution to install
the rest of the required software to bring the computer up to the required standard.
u Perform an unattended Windows XP installation on all client computers. You can create a
Windows XP installation package that includes the appropriate answer file. Clients will then
perform an unattended operating system upgrade.
72 Chapter 3 Understanding SMS Features

Software Update Management


The SMS software update management feature allows administrators to audit, deploy, and track
updates for various software applications throughout the organization. Specifically, the feature
allows you to manage updates to software such as Microsoft operating systems, Office, Internet
Explorer, Microsoft SQL Server™, and Exchange.
Software update management relies on software update catalogs published by Microsoft, which
contain the up-to-date list of necessary software updates. Because Microsoft continues to release
software updates, keeping all computers in an organization compliant with those updates is an
ongoing administrative task. Ensuring that clients are up to date with security updates is an
especially critical task.
By using the software update management feature in SMS 2003, you can automate and simplify
deployment of software updates in your organization. Additionally, the synchronization
component provides an easy way to create a standardized routine for ongoing software update
compliance throughout your enterprise with minimal manual steps.
The software update management client components are slightly different on the Legacy Client
and on the Advanced Client. Some features, such as persistent notification and scheduled
installation, are available only on the Advanced Client.
The software update management feature consists of several components, some of which use
primary features of SMS, such as hardware inventory, software distribution, and reporting. The
software update management feature consists of the following components:
u Software update inventory tools
u Distribute Software Updates Wizard
u Software Updates Installation Agent
u Reports
Those components are described in the following sections.
Software update inventory tools
Software update inventory tools scan the client computers in your organization and create a
detailed inventory of the installed and applicable software updates. This helps to identify the
clients in your organization that require updates to software such as security, operating system,
and Microsoft Office. Software update inventory tools also ensure that only necessary software
updates are deployed on clients.
The software update inventory tools are:
u The Security Update Inventory Tool, which handles security software updates for software
such as Microsoft operating systems, Internet Explorer, SQL Server, and Exchange.
u The Microsoft Office Inventory Tool for Updates, which handles software updates for
Microsoft Office.
Software Update Management 73

Those tools are not dependent on each other. You can use either tool without using the other or
use both. Software update inventory tools are not installed on SMS sites by default. Instead, you
must download them from http://www.microsoft.com/smserver/downloads.
The inventory data provided by the Security Update Inventory Tool and the Microsoft Office
Inventory Tool for Updates provides detailed information in a central location about the
compliance level of your SMS clients. This information includes:
u A list of currently installed updates and service packs.
u Software updates that are available and applicable.
u The date and time the update was posted.
u The date and time the update was installed (if applicable).
Additionally, the software update inventory data includes a link to Microsoft Knowledge Base
articles on the applicable updates. This allows you to access relevant information that helps you
correctly evaluate the need of those updates in your organization.
Each of the software update inventory tools consists of an installer program to install the tool and
two additional components:
Synchronization component This component runs on an Internet-connected SMS site server or on
an Internet-connected SMS client. It is responsible for keeping software update catalogs and
software update inventory tools up to date. To accomplish this, the synchronization component
monitors the Microsoft Download Center Web site at a specified interval. It synchronizes the
site’s copy of the security catalog or the office catalog with the latest catalogs posted by
Microsoft. It updates the site’s software update inventory tools scan components by downloading
any new versions posted by Microsoft.
Scan component This component runs on SMS clients. It scans client computers for installed
software updates. It then evaluates the client’s existing software updates against the latest
catalogs to determine which updates are installed and which updates are applicable for the client.
The scan component stores the results of this evaluation in WMI on the client. From that point
on, the SMS hardware inventory feature processes this information as part of the client’s
hardware inventory data.

Software Updates Installation Agent


The Software Updates Installation Agent facilitates the deployment of software updates on
clients, ensuring that only the necessary updates are installed. It compares the list of authorized
and available software updates to the list of applicable software updates on the client. It then
determines which updates need to be installed on the client to bring it into compliance.
The Software Updates Installation Agent consists of a few executable files, the main one being
Patchinstall.exe. The Distribute Software Updates Wizard ensures that Patchinstall.exe is
included in every software update package. Patchinstall.exe is specified as the program file for
the software update program. When the advertised software update program runs on the client
computer, Patchinstall.exe runs and starts the software update deployment.
74 Chapter 3 Understanding SMS Features

When the Software updates Installation Agent runs on the client, depending on the parameters
specified for Patchinstall.exe, the agent can perform tasks such as:
u Displaying dialog boxes that allow users to postpone the installation.
u Installing the software updates.
u Controlling the computer’s restart behavior.

Distribute Software Updates Wizard


The Distribute Software Updates Wizard is installed on SMS site servers and on remote
SMS Administrator consoles by default. The Distribute Software Updates Wizard provides an
intuitive interface that simplifies the software update deployment process. By using the software
update inventory data that is provided by the software update inventory tools, the Distribute
Software Updates Wizard helps you create the software update packages, programs, and
advertisements.
By using the wizard, you can evaluate applicable software updates, access additional information
about those updates, and then select the software updates that clients need. You can prioritize the
software updates, specify installation parameters, and customize branding for the software
updates. You can specify the deployment schedule and other installation parameters such as
whether to enforce the update deployment. By using the wizard, you can also attach an RTF file
to software update programs. Those RTF files can contain important information for users, such
as information about the software updates contained in the package and specific usage
instructions.
The Distribute Software Updates Wizard helps you complete the process of updating client
software, from downloading the updates source files to advertising the software update program
to the appropriate clients. It specifically performs all the software distribution related tasks as
follows:
u Creates and manages software update SMS packages.
u Downloads software update source files from the Internet to a specified local package source
share.
u Distributes software update source files to specified distribution points.
u Creates software distribution programs for software update packages.
u Creates advertisements for the software update programs.

Reports
SMS 2003 includes several predefined software update-related reports for tracking software
update compliance throughout your organization. They display information such as applicable
software updates and installation status for a specified software update.
How Software Update Management Works
Microsoft releases information about software updates in the form of catalogs and Web
downloads. The security update catalog and the Microsoft Office update catalog are periodically
updated as new software updates and are released.
Software Update Management 75

The software update management feature in SMS 2003 uses these catalogs as references to
evaluate clients. Software update management performs a detailed inventory of the installed and
applicable software updates on all of the SMS client computers in your enterprise. Software
update inventory tools scan clients and determine what updates are needed to bring the client up
to date and then administrators use the Distribute Software Updates Wizard to deploy necessary
updates.
Managing software updates consists of the following phases:
1. Initiating the software update inventory cycle. The administrator starts this phase by
downloading and running the installer program for one or both of the software update
inventory tools on the site server. The installer program:
a. Sets up the synchronization host.
b. Creates the packages, collections, programs, and advertisements for installing the
software update inventory tools’ scanning components on the clients.
2. Software update inventory tools scan the SMS clients and provide information about
installed and applicable software updates.
3. Administrators use the Distribute Software Updates Wizard to assess, authorize, and deploy
software updates.
4. The synchronization host periodically updates the site’s local catalogs (weekly by default)
and scans components.
76 Chapter 3 Understanding SMS Features

Figure 3.4 describes in detail how the various components of the software update management
feature are used to manage software updates.
Figure 3.4 Managing software updates process
Setup Phase
Internet

Synchronization Inventory tools SMS Site


host synchronization Server
component

Inventory tools scan component

Synchronization Software Update Process


Process
Software
distribution
Software
Software distribution
Internet distribution

Synchronization Inventory Clients


host tools scan
component
updates Distribute
Software
Updates Software
Wizard Updates
Catalog
updates

SMS Site
Server

Package source
Internet share host
Software Update Management 77

Figure 3.4 illustrates the process of managing software updates. The detailed steps are as follows:
1. Starting the software update inventory cycle:
a. The SMS administrator downloads from the Microsoft downloads site the Security
Update Inventory tool, the Microsoft Office Inventory Tool for Updates, or both.
b. The administrator runs the respective installer program on the SMS site server.
c. Each inventory tool installer program creates the necessary packages, collections, and
advertisements for distributing the software update inventory tools’ scan components to
the site’s clients.
d. Each inventory tool installer program creates the necessary packages, collections, and
advertisements for distributing the synchronization component to the designated
synchronization host.
e. SMS leverages the software distribution feature to distribute the software update
inventory tools’ scan components to the site’s clients.
f. The clients run the advertised program and install the software update inventory tools’
scan components.
2. The scan component of one or both software update inventory tools starts to run on SMS
clients at the specified interval. The default interval is every seven days.
Every time a scan component runs, it analyzes the current state of software updates on the
client and generates a list of software updates that are installed and software updates that are
applicable to the client. The scan component then stores that information in the
Win32_PatchState property in WMI.
This information is now treated as hardware inventory data. It is collected during the next
hardware inventory cycle and propagates up the hierarchy along with the rest of the
hardware inventory data.
The time it takes for the information to reach the site server depends on the scan component
configuration, hardware inventory agent schedule settings, and site server load.
3. The SMS administrator runs the Distribute Software Updates Wizard to view, evaluate, and
authorize applicable software updates. The information that the wizard displays is based on
the software update inventory data that was collected during the scanning phase.

Important
The Distribute Software Updates Wizard will not display information until the
hardware inventory cycle has fully completed and the hardware inventory
data is stored in the SMS site database.

4. The Distribute Software Updates Wizard downloads from the Microsoft downloads site the
source files for the specified software updates.
5. The Distribute Software Updates Wizard stores software update source files on a specified
package source share.
78 Chapter 3 Understanding SMS Features

6. The Distribute Software Wizard creates or updates the necessary packages, programs, and
advertisements for distributing the software updates to SMS clients. To every package that
the wizard creates or updates, it appends the necessary Software Updates Installation Agent
components and the necessary program to initiate that component.
7. The Distribute Software Wizard copies the required source files from the package source
share to the specified distribution points.
8. SMS leverages software distribution to advertise the software updates programs to clients.
9. The advertised programs run on the clients. The Software Updates Installation Agent runs
and deploys the software updates. The agent runs the scan component to ensure that only the
required software updates are deployed.
10. The synchronization component synchronizes the software update inventory tools’ scan
components and software update catalogs:
a. Periodically (weekly by default), the synchronization component checks the Microsoft
Download Center Web site for updates to the software update inventory tools’ scan
components and software update catalogs. The synchronization component downloads
any new updates.
b. The synchronization host updates the local copy of software update catalogs.
c. The synchronization host updates the packages, programs, and advertisements that are
associated with the software update inventory tools’ scan components.
d. SMS leverages the software distribution feature to advertise to clients the programs
that update software update inventory tools’ scan components.
e. Clients run the advertised programs and update their software update inventory tools’
scan components.

Benefits of Software Update Management


The software update management feature provides an end-to-end solution for centralized
software update management. Assessing and maintaining the integrity of system software in a
networked environment through a well-defined software update management program is critical
for successful information security, regardless of existing controls over physical access to a
system.
The software update management feature gives you full control over the software updates
distribution process, allowing you to successfully complete administrative tasks such as:
u Deploying mandatory software updates without user interface.
u Defining multiple scopes for the same package, where the same package is distributed with
different runtime parameters to multiple collections.
u Applying updates within specified beginning and end times on the Advanced Client.
u Using software update templates that are imported from reference computers to expedite the
deployment of critical software updates.
Software Metering 79

The predefined software update reports provide you with an easy way to access the status of
software update deployment throughout your enterprise. You can use these reports to view the
global compliance level for each authorized patch and reported potential security problem. This
is particularly useful in tracking the status of critical software updates, such as those protecting
against the actions of a harmful virus. These reports also make it possible for you to create
collections of computers to which specific software updates should be applied or to delete
collections for which software updates are no longer necessary. By using the dashboard feature in
SMS 2003, you can build dashboards that provide a complete view of software updates
compliance throughout the organization.
The predefined collections, packages, and advertisements that are created by software update
inventory tools are designed to simplify the workflow for your software update deployment. This
provides you with an easy way to distribute the software updates to a test collection before
deploying them in a production environment.
By carefully planning your software update strategy, you can create and maintain software
update packages and distribute them based on any criterion. For example, you can create a
package with stringent enforcement rules that contains only critical updates, another that contains
recommended updates and has moderate enforcement rules, and a third with lenient enforcement
rules that contains optional updates. You can also create packages that contain only updates for
specific operating systems or versions, such as Windows NT® 4.0 and Windows 2000, to
simplify migration scenarios.
You can use the software update inventory data to perform specific queries, such as querying for
clients that have properties that meet criteria in the vulnerability matrix for a given software
update. This data can be useful in determining if the patch should be deployed and who might be
affected, for example, how many computers are running Internet Information Services (IIS) but
are not actually hosting line of business Web sites.

Software Metering
The software metering feature allows you to monitor program usage on client computers. By
using software metering, you can collect data about software usage in your organization.
Software metering data can be conveniently summarized to produce useful reports that can help
you monitor licensing compliance and plan software purchases in your organization. Software
metering collects detailed information about the programs that you chose to monitor. This
includes information about program usage, program users, the program start time, and the length
of time it is used.
Software metering is supported on Legacy Clients, Advanced Clients, and SMS clients that are
running Terminal Services. Software metering rules are enforced on all remote desktops with an
open session to the terminal server that is an SMS client. Software metering data is collected
from these desktops. However, all programs that run on the Terminal Server will be reported
with the same computer name, which is the Terminal Server computer name.
80 Chapter 3 Understanding SMS Features

How Software Metering Works


You can enable or disable software metering for an SMS site. When the feature is enabled for the
site, SMS starts to collect software metering data according to the specified software metering
rules and other configuration data.
To monitor software usage on your clients, you need to define software metering rules. A
software metering rule represents a program that you want to monitor. In each rule you specify
an executable’s file name, a version, and a language. The software metering rules are stored in
the SMS site database, on CAPs, and on management points. The Software Metering Client
Agent, running on clients, uses the information in software metering rules to identify the
software that it needs to monitor.

Note
In a software metering rule, you can identify an executable by its original file
name. This allows you to monitor software even if the user has modified the
executable’s file name.

The Software Metering Client Agent performs the software metering-related tasks on the clients,
primarily collecting metering data from the client computers. When you enable and configure
software metering at the site, SMS installs the Software Metering Client Agent components on
all Legacy Clients in the site (these components are already installed on Advanced Clients) and
starts to collect software metering data according to the software metering rules that you
specified.
Software Metering 81

Figure 3.5 Software metering process


Central site

Primary site Site server/


Site database server

Site
server Site
database
server

Management
point

Advanced Client
CAP
Software Metering Client Agent

Legacy Client
Primary site Software Metering Client Agent

Site
server Site
database
server

Management
point

Advanced
CAP Client

Legacy
Secondary site Client

Site
server

CAP
Legacy
Client

Figure 3.5 describes how software metering rules propagate down the hierarchy, and how
software metering data that is collected at client computers propagates up the hierarchy.
82 Chapter 3 Understanding SMS Features

When you enable software metering for a site, SMS enables software metering on the site’s
clients as follows:
1. SMS installs the Software Metering Client Agent on all Legacy Clients in the site (the agent
is preinstalled on Advanced Clients).
2. SMS sends to management points the Advanced Client policy that enables the Software
Metering Client Agent on Advanced Clients.
3. When you create software metering rules, SMS stores them in the SMS site database, on
CAPs, and on management points. Clients access these rules as follows:
u Legacy Clients download these rules from the CAPs.
u Advanced Clients receive the rules through an Advanced Client policy that is published
by management points.
Secondary sites operate in the same manner, but the metering rules are stored in a file. When
you define a rule that applies to lower level sites, SMS replicates the rule to the appropriate
sites.
4. SMS configures the client agents with the schedules specified on the site server, as follows:
u SMS stores on CAPs the Software Metering Client Agent configuration settings. Legacy
Clients later download this information and use it to configure their Software Metering
Client Agent.
u SMS stores on management points the Advanced Client policies that correspond to the
Software Metering Client Agent configuration settings. Advanced Clients later use these
policies to configure their Software Metering Client Agent.
5. The Software Metering Client Agent collects metering data according to the software
metering rules. The agent downloads rules and uploads collected data according to the
specified schedule.
On Advanced Clients, the metering data is sent to a management point. On Legacy Clients,
the data is sent to a CAP.
The CAP or management point sends the metering data to the site server. If the site is a
secondary site, the metering data is sent to the site’s parent site.
6. The primary site server processes the metering data and stores the information in the SMS
site database. Periodically, the site summarizes its software metering data.
If the primary site server is not the central site server, then the site sends recently
summarized software metering data to its parent site. The site also sends data that it received
from any lower level sites on which software metering is enabled. This step repeats until the
metering data reaches the central site.
At the end of this process, every primary site contains metering data of its own clients and of
clients in lower level sites in the hierarchy.
Software Metering 83

7. The SMS site database contains the software metering data, and you can run software
metering related reports to view that data. You can also create queries that are based on
software metering data. Note that each site contains software metering data from the site’s
clients and from all lower level sites clients. (The central site contains metering data from
clients A, B, C, D, and E, while the midtier primary site contains metering data only from
clients C, D, and E.)
When software metering is enabled, SMS collects information about program activity on the
clients. The data is stored at the site database. The data accumulates rather quickly and it can
consume significant space. To reduce space consumption in the site database, SMS provides
predefined software metering maintenance tasks that can summarize the data. Other software
metering maintenance tasks can then delete the raw data, which has been summarized.
Benefits of Software Metering
By using software metering, you can closely monitor software usage in your organization. You
can track which users ran which software programs and for how long. By using that data, you can
determine which programs are used most often and which programs are not used at all. This
helps when planning software purchases. Administrators can examine software metering data and
determine which clients, or groups of clients, are in most need of a software upgrade.
Software metering helps you determine whether the organization is in compliance with terms of
software licenses. Software metering data shows which programs are in great demand and which
programs are not used at all. This helps justify the purchase of additional licenses and helps
determine that a specific software license can be canceled.
When using client-server applications, software metering can help you ensure that clients are
running the application version that is compatible with the server’s version. You can identify
clients that are running incompatible versions.

Note
You can also use software inventory to ensure compatibility between the
server and the client applications when using client-server applications.

SMS provides predefined reports that display the summarized data in meaningful and helpful
report formats. If software inventory is enabled at a site, you can create reports that are based on
both software inventory and software metering data. For example, you can create a report that
shows which clients have installed Microsoft Publisher, but have never used the program.

Software Metering Throughout the Hierarchy


Any software metering rule can apply to the current site or to any lower level sites. If you specify
that a rule should apply to any lower level sites, SMS sends that rule to the specified sites. The
current site’s set of rules consists of the site’s own rules, in addition to any rules that were sent
from higher level sites. When a rule is received at a child primary site, it is added to the SMS site
database. It is also evaluated to determine whether it should be replicated to child sites.
84 Chapter 3 Understanding SMS Features

Software metering data that is collected from clients is compacted and stored on the client and
then sent to the site server. Secondary sites send their data to their parent sites. Primary site
servers store the data in the SMS site database. Periodically, the site server summarizes the data
and then sends the summary to its parent site. This summary is replicated up the hierarchy until it
reaches the central site. When the data appears at a parent site, each record is marked with the
appropriate source site code. This allows you to produce organization-wide software metering
summarization reports.

Remote Tools
SMS Remote Tools is a suite of tools that you can use to provide help desk assistance and
troubleshooting support to clients in an SMS hierarchy. With Remote Tools, it is not necessary to
physically be at the client’s location to provide assistance. Remote Tools give you full control
over the client’s computer and allows you to perform any operation as if you were physically at
the client’s location.
In addition to SMS Remote Tools, SMS 2003 integrates Remote Assistance and Terminal
Services into the SMS Administrator console for assisting supported clients. You can also use the
SMS Administrator console to remotely configure Remote Assistance settings for supported
clients and then launch Remote Assistance session. From the SMS Administrator console, you
can also start a Remote Desktop Connection session to supported clients.

Note
It is strongly recommended that you use the Windows Remote Assistance
and Remote Desktop Connection features of Windows XP and Windows
Server 2003 rather than SMS Remote Control on computers running those
platforms. Windows Remote Assistance and Remote Desktop Connection
are more secure technologies and are built-in features of the operating
system.

The Remote Tools suite consists of the following tools:


u Remote Control, to remotely operate a client’s computer by sending mouse clicks and
keyboard strokes from the SMS Administrator console. You can work with a client’s
computer just as if you were physically at the client’s desktop.
u Remote Reboot, to remotely restart a client’s computer.
u Remote Chat, to chat with a user at the Advanced Client computer.
u Remote File Transfer, to transfer files between an Advanced Client and your site server.
Remote Tools 85

u Remote Execute, to run programs on a client computer.


u SMS Client Diagnostics, to run diagnostic utilities on a client.
u Ping Test, to determine the reliability and speed of the network connection between the site
server and a client.
The greatest advantage of Remote Tools is that you can perform all these important
administrative tasks from your desktop, saving time and minimizing travel.
You can use Remote Tools across a WAN or use Microsoft Remote Access Service (RAS) links
to assist clients in remote locations. Remote Tools supports RAS connections with a minimum
speed of 28.8 Kbps. You can also establish a connection into your organization and then access
clients on your network.
How Remote Tools Work
Before you can use Remote Tools, you must prepare the clients by enabling the Remote Tools
Client Agent. When you enable and configure the Remote Tools Client Agent in a site, SMS
installs the remote tools client agent components on all clients in the site.
When you need to use a remote tool to provide assistance to a client, a connection must be
established between the site server and the client. When the connection is established, you can
use any tool from the Remote Tools suite to provide assistance to clients. The Remote Tools
feature allows you to establish up to four Remote Tools connections so you can provide
assistance to up to four clients simultaneously from a single SMS Administrator console.
Depending on how you configured Remote Tools, Remote Tools operations might require the
client’s approval. For example, when you establish a remote connection to a client and start the
file transfer tool, you might need client approval before you can transfer files between the client
and your desktop.
86 Chapter 3 Understanding SMS Features

Figure 3.6 Remote Tools process


Central site

Primary site

Site server/
Site database server
Site
server Site
database
server
Management
point
Advanced
Client
CAP
Legacy
Client

Remote
Primary site
tools

Site
server Site
database
server
Management
point
Advanced
Client
CAP
Legacy
Client

Secondary site

Site
server

CAP

Legacy
Client
Remote Tools 87

Remote Tools works as follows:


1. SMS collects discovery data from the site’s clients.
2. Discovery data is processed and propagated up the hierarchy as follows (this is similar to
how software and hardware inventory propagate up the hierarchy):
u Secondary sites send discovery data to their parent sites.
u On primary site servers, SMS processes the discovery data and stores the information in
the site database.
If the primary site server is not the central site server, it sends the discovery data to its parent
site. The site also sends discovery data that it received from any lower level sites. This step
is repeated until the discovery data reaches the central site.
At the end of this process, every primary site contains the discovery data of the site’s clients
and of clients of lower level sites in the hierarchy.
3. When you enable Remote Tools and remote assistance for a site, SMS enables Remote Tools
on the site’s clients as follows:
u SMS installs the Remote Tools Client Agent on all Legacy Clients in the site (the agent
is preinstalled on Advanced Clients).
u SMS sends the appropriate Advanced Client policy that enables Remote Tools on
Advanced Clients.
4. You can now use Remote Tools to access a client from any of its parent sites that contains
the client’s discovery data.
Remote Tools Throughout the Site Hierarchy
At a primary site server, you can use Remote Tools to access any client in the hierarchy whose
discovery data is stored at the site’s database. Because discovery data propagates from clients up
the hierarchy, you can run Remote Tools to access a client from any of the client’s parent sites.
From the central site, which has discovery data of all the client’s of the hierarchy, you can run
Remote Tools to access any client in the hierarchy.

Benefits of Remote Tools


By using one or a combination of remote tools, you can detect, diagnose, and successfully repair
a wide range of problems with a client computer. You can assist clients with hardware issues,
software issues, and problems with the operating system.
By using the Remote Control tool, you can take control of a client by displaying a duplicate view
of the client’s desktop in a window on your desktop. You can view the client performing a
problematic task and identify errors, or you can use your keyboard and mouse to simulate
keyboard and mouse strokes to the client computer to demonstrate the correct way to perform
that task. You can also view error messages exactly as they appear on the client’s screen, instead
of depending on the user to paraphrase the error message.
88 Chapter 3 Understanding SMS Features

You can use Remote File Transfer to transfer a corrupted file from the client to the site server for
investigation. You can replace a corrupted file on a client by transferring a correct version of the
file from the site server or from another healthy client. You can examine a healthy client and
compare registry settings to the registry settings on the client that is having troubles. You can use
Remote Reboot to complete a software upgrade and to see any restart-related problems that occur
on the client.
From your desktop you can use Remote Execute to run a command line on a client, such as a
virus checker or a hard disk drive defragmenter (in the security context of the administrator’s
computer).

Reporting
The reporting feature displays site information by retrieving specified sets of data from the SMS
site database and displaying it in an organized format.
By using reporting, you manipulate reports. A report is an SMS object that consists of a set of
properties that describe the report, such as the report’s name. The primary property in a report’s
definition is its SQL statement, which specifies the data that needs to be retrieved from the SMS
site database and then be displayed.
SMS 2003 provides many predefined reports. These reports can display a variety of information,
such as hardware inventory data, software inventory data, and status messages data. You can use
predefined reports to retrieve and display data about your site, such as clients that are low on disk
space, or clients that have a specific network card. You can also create new reports that display
other information that is useful to your organization.
You can create, configure, and manage reports by using the SMS Administrator console. You can
run reports by using Report Viewer, which is a browser-based application that runs in Internet
Explorer 5.5 or later. By using Report Viewer, users can run reports without accessing an
SMS Administrator console.
Reporting also supports dashboards, which are sets of reports in a grid that you can display in a
single window of Report Viewer. You can use a single dashboard to monitor information about a
variety of SMS objects or systems.
You can also extend the reporting feature by creating supplemental reports. Supplemental reports
can be custom Active Server Pages files, HTML files, text files, or any file that you can display
by using Internet Explorer 5.5 or later. You can use any tool, including tools that are external to
SMS, to create a supplemental report.
To create or modify the SQL statements of reports, you need to have a basic understanding of
SQL. You also need to understand the underlying SMS data classes, which are presented in the
SQL Server views that reporting uses to obtain information.
Reporting is supported only on primary sites, because secondary sites do not have a database
server.
Reporting 89

How Reporting Works


To use reporting, you must set up at least one reporting point in the site. A reporting point is an
SMS site system that hosts Report Viewer and where you can store supplemental reports. IIS 5.0
or later must be enabled on the reporting point site system server.
When you set up a reporting point, SMS creates a designated URL that users can use to access
that reporting point. If you anticipate heavy demand for reports in your site, you can create more
than one reporting point and then point different groups of users to the different reporting point
URLs.
After the site has a reporting point, you can run and manage reports. You use the SMS
Administrator console to create, modify, delete, export, and import reports. In the SMS
Administrator console, you can filter the list of reports by categories. You can then sort the list to
quickly locate a specific report.
You use Report Viewer to display the list of available reports and to run reports. When Report
Viewer runs, it displays only the reports that the user has permission to view. The reports are
categorized to help you locate a specific report that you need to run.
When a user runs a report, the results are based on the data that is retrieved by the report’s SQL
statement. The SQL statement accesses read-only SQL Server views, instead of SMS site
database tables. The report retrieves the specified data and displays it in an Internet Explorer
window.
You can start Report Viewer either from the SMS Administrator console or by typing the
designated URL for a reporting point in the Address box of Internet Explorer.
Benefits of Reporting
You can use reports to view selected data from the site’s database in a clear and organized
format. When considering solutions, decision-makers in your organization need different sets of
data, at different detail levels, presented in different ways. By using reporting, you can create
reports that present necessary data in a way that is most beneficial to your organization. This
helps you to make correct decisions.
Reporting is also useful for site maintenance. You can run reports as you need them, or you can
schedule reports to run on a regular basis to help detect and diagnose problems early. For
example, if there is a problem with a specific client, you can run a report that displays that
client’s recent errors. To ensure continued site health, you can regularly run a report that displays
site status. Other reports, such as reports that display software distribution status and software
usage, can also help with site maintenance.
A report can link to other related information, such as another report, or a URL. Links provide
quick access to additional relevant information. For example, you can link a report that lists
discovered computers to a report that provides recent error messages. Every discovered computer
that is displayed has a link to error messages associated with that computer.
90 Chapter 3 Understanding SMS Features

A report can also have prompts. You can use prompts to limit the report’s scope based on
information that the user enters when the report runs. For example, you can specify a report that
retrieves all the clients running a certain product and you can include a prompt for the user to
provide a product name. Every time that the report runs, the user enters a product name and the
report displays the clients that are running the specified product.
Reports can display a single data set based on a single SQL Select statement or multiple data sets
based on multiple SQL Select statements.
After running a report, you can do a number of things with the displayed data. For example, you
can display the data as a chart, you can save the data as a comma-delimited (.csv) file, or you can
add the report to your list of favorites in Internet Explorer.
Reporting Throughout the Site Hierarchy
Reports do not propagate up or down the SMS hierarchy, and they run against the current SMS
site database only. Because primary sites contain data from lower level sites, when a report
retrieves data from the SMS site database, it might retrieve data that was propagated from a
lower level site, if appropriate.
Occasionally, it might be useful to share reports between SMS sites. For example, administrators
who are familiar with SQL can write reports and share these reports with administrators who are
not familiar with SQL. To accomplish this, you can export report object definitions from your
SMS site database to a MOF file. You can import MOF files back into the current SMS site
database or into another SMS site database. When running a report that was imported from
another site, the report runs against the current SMS site database.

Product Compliance
The product compliance feature helps you ensure that software used by clients, complies with
corporate guidelines. Your organization might set product guidelines and standards. For example,
there can be a requirement to use only a certain version of a product or there can be a guideline
banning the use of an unauthorized product. Product compliance can help you ensure that
software products that are installed on client computers comply with these guidelines.
Product compliance works with software inventory. Software inventory tracks software that is
installed on client computers, and product compliance helps you detect which of that software
complies with corporate software guidelines.
After you identify noncompliant software, you can use software distribution to upgrade the
software or to distribute patches that bring that software into compliance.
How Product Compliance Works
To use product compliance, the SMS site database must contain:
u Software inventory data.
u Product compliance data.
Product Compliance 91

u Queries and reports that analyze compliance based on software inventory data and product
compliance data.
Software inventory data Software inventory data is collected from clients when the software
inventory feature is enabled. The collected data is then stored in the SMS site database. Software
inventory gathers .exe header information from files, and this information can then be compared
against the compliance data. For more information about software inventory, see Chapter 2,
“Collecting Hardware and Software Inventory,” in the Microsoft Systems Management
Server 2003 Operations Guide.
Product compliance data Product compliance data is a collection of the software guidelines and
standards that are set in your organization. SMS 2003 does not contain any predefined product
compliance data. You generate this data according to product guidelines and standard
requirements in your organization.
After gathering the product compliance data, you need to store it in the SMS site database as
product compliance records. Each product compliance record contains details of a product that
you would like to include in the product compliance analysis. Every product compliance record
must include information about the product such as the product’s name, the product’s version,
and the product’s .exe file name. It must also include the following two important data items:
Compliance type A type of product guideline or standard. You can create as many
compliance types as required in your organization.
Compliance level A possible compliance level that is associated with a compliance type.
Typically, several compliance levels are associated with a single compliance type.
For example, your organization might set a requirement to use only the latest versions of Office.
To detect compliance with this standard, you can define an “Office standard” compliance type.
For that compliance type, you might define the following compliance levels: “compliant,”
“noncompliant,” and “compliant with issues.” By using these definitions, you can create the
following product guidelines:
u Office XP is “compliant” with the “Office standard” compliance type.
u Office 2000 is “compliant” with the “Office standard” compliance type.
u Office 97 is “noncompliant” with the “Office standard” compliance type.
Queries and reports Queries and reports analyze product compliance. Create and run queries and
reports that evaluate software inventory data against the product compliance data in the SMS site
database to detect compliance issues.
If you identify any software compliance issues in your organization, you can resolve them by
using the software distribution feature. You can create collections with the clients that run
noncompliant software and use software distribution to advertise software upgrades or patches to
these clients to bring software into compliance.
Benefits of Product Compliance
You can use the product compliance feature to maintain product guidelines in your organization.
You can identify noncompliant software used in your organization.
92 Chapter 3 Understanding SMS Features

You can detect banned software by creating a product compliance record for the banned product.
To maintain corporate standards, you can create a product compliance record for each product
version that is known to be nonstandard in your organization.

Status System
SMS generates status messages to report the activity of components on site systems and clients.
A status message is a text string, generated by a component, describing a specific activity
performed by the component. In addition, each status message contains important information
such as which component generated the message, the exact time that the message was generated,
and the severity of the message.
Status messages are sent from clients and site systems to the site server and are stored in the SMS
site database. You can then view status messages in the SMS Administrator console. Viewing
status messages in the SMS Administrator console helps you monitor the activity of the various
components, determine the health of SMS, and identify issues that might require your attention.

Backup and Recovery


Ensuring that SMS site servers continually operate without disruption is critical to the
organization’s daily operation. Because computers can fail unexpectedly for various reasons,
such as hardware failure or software corruption, organizations must be prepared for a quick site
recovery.
To be prepared, SMS provides functionality that you can use to back up and recover a site. You
can back up the site’s data on a regular basis and then use recovery and repair tools to restore that
shadow copy backup and to recover the site to its original state. The backup and recovery feature
ensures that the site loses minimum amount of data and that the site continues to operate properly
after it is recovered.
For more information about backup and recovery, see Chapter 13, “Planning for Backup and
Recovery.” See also Chapter 15, “Backup and Recovery,” in the Microsoft Systems Management
Server 2003 Operations Guide.

Network Monitoring Tools


SMS components generate large amounts of data, which propagate within the site and up and
down the hierarchy. To ensure that the data propagates as fast as possible, you must monitor and
maintain the network on which SMS sites are installed.
Integrating Features 93

SMS provides network maintenance and monitoring tools that help you ensure that the network
is performing as expected. Network maintenance and monitoring tools help you monitor, capture,
and interpret network data. By using those tools, you can diagnose network problems, monitor
and analyze patterns of network activity to avoid network problems, and identify optimization
opportunities.

Integrating Features
You can complete tasks in your organization by using SMS features individually. However, SMS
features are well integrated and are usually used together to achieve core tasks in an organization.
This section describes how to integrate SMS features to achieve common organizational tasks.

IT Asset Management
Using hardware inventory and reporting integrally helps an organization to effectively manage its
IT assets.
By using these features, administrators can ensure that corporate standards are met. You use
hardware inventory to collect data from the clients such as BIOS revision, processor speed, or
any other data to which corporate standards exist. Use the reporting feature to compare the
collected data against the corporate standards and to generate reports of individual computers
compliance with the required standards.
Administrators can also track asset depreciation in their organization with these features. Use the
hardware inventory feature to collect purchase dates of the client computers, and use reporting to
display that data. Then, you can use these dates to determine the total asset depreciation in the
organization. This can help reduce the amount of tax paid on assets that have depreciated.

Software Management
Using inventory, software metering, software distribution, product compliance, software update
management, and reporting integrally helps an organization to effectively manage its software
and to maintain software standards. You can eliminate the use of older versions of software by
distributing software that is required by corporate standards and then enforcing client upgrade.
You can also enforce specific software configurations according to corporate standards.
When using the software update management feature, you leverage software distribution and
inventory to ensure that the latest software updates from Microsoft are quickly and efficiently
deployed throughout the organization. This minimizes security risks and ensures that client
software is up to date.
94 Chapter 3 Understanding SMS Features

By using software distribution, you can deploy software in your organization from a central
location. By using data that is collected by hardware inventory, software inventory, or both, you
can build lists of clients that need to receive specific software deployments. By using software
distribution, you can then deploy software to those clients. For example, you can upgrade the
client operating system or Office suite, deploy service packs, distribute new software, or
distribute the latest antivirus signature file on a regular basis.
Inventory data helps you build the lists of clients that require specific software. For example,
using software inventory data, you can build a list of clients that do not have an antivirus
program installed. By using hardware inventory data, you can build a list of clients with at least
500 MB of free disk space and then distribute software only to those clients.
To distribute software to clients that have at least 500 MB of free disk space
1. Collect hardware inventory data, including data about clients’ hard disks.
2. Create a query that retrieves all the clients that have at least 500 MB of free disk space.
3. Create a client collection that is based on that query (you can perform steps 2 and 3
together).
4. Advertise the software to that collection.
5. Run a report that displays the advertisement deployment status for every client.
Or, you can use software inventory to collect information about clients’ current version of the
Office suite and then distribute an Office XP upgrade only to clients that have the appropriate
version that needs to be upgraded.
To distribute an Office XP upgrade to clients with earlier versions of the Office suite
1. Collect software inventory data, including information about installed products on client
computers.
2. Create a query that retrieves all the clients that have Office 2000 or Office 97 installed.
3. Create a client collection that is based on that query (you can perform steps 2 and 3
together).
4. Advertise the Office XP upgrade to that collection.
5. Run a report that displays the Office XP deployment status for every client.
In the same manner, you can use data that is collected by both the software and hardware
inventory features to create a list of clients that are running an older version of the Office suite
and that have sufficient disk space for the upgrade. You can then distribute the Office upgrade
only to clients that meet both requirements.
After distributing the Office upgrade, you can use the reporting feature to generate a report that
shows the clients that have successfully installed the new Office suite. This ensures that all
intended clients installed the updated application.
You can also use software metering to monitor program usage. For example, during the Office
suite upgrade, you can use software metering to monitor clients using older versions of Office
and then force these clients to upgrade. You can run predefined reports that display information
about software metering usage to help you monitor software usage in the organization.
Integrating Features 95

You can create the appropriate Windows XP answer file and include it in a Windows XP
installation package. Use the hardware inventory data to create the collection of clients that have
sufficient hardware resources to support the operating system upgrade. Advertise the
Windows XP upgrade program to that collection, and then the clients will perform an unattended
operating system upgrade.
When defining software metering rules, you can examine the site’s software inventory data to
determine which programs you want to monitor. Comparing data from all existing software on a
client computer (collected by software inventory) against usage data (collected by software
metering) shows what software is installed on client computers, but is not used.
You can also use product compliance to detect banned software that is installed on client
computers. When product compliance detects non-compliant software, you can use software
distribution to distribute updates to bring the non-compliant software into compliance.

Help Desk
All of the following features can help an organization’s help desk be more effective:
u Remote Tools
u Software inventory
u Hardware inventory
u Reporting
The various tools included in the Remote Tools suite are the main resources when
troubleshooting client problems. The hardware and software inventory features can also assist.
When troubleshooting clients, it might be important to know the client’s current software and
hardware configuration or to know about recent changes.
As hardware inventory data is collected, hardware inventory history is built up. By browsing
through a client’s history of hardware inventory, you can determine how the client’s hardware
has changed and this can help in diagnosing problems.
By using the software inventory feature, you can store copies of files from the client’s computers
at the site server. When clients experience problems, you can examine these files to help
determine the cause of the problem.
C H A P T E R 4

Understanding SMS
Clients

You deploy Microsoft® Systems Management Server (SMS) 2003 in your organization for one
primary reason — to centrally manage the computers in your organization. To be able to manage
those computers, the SMS client software must be installed on them. By doing so, those
computers become SMS clients. Ideally, all the computers in your organization are SMS clients,
which allows you to use SMS for all your computer change and configuration management.
After you install and configure an SMS 2003 site server and the necessary site systems, you can
begin to deploy the computers in your organization as SMS 2003 clients. Computers must be
SMS clients before you can distribute software, collect hardware and software inventory, use
software metering, or use Remote Tools. This chapter describes the concepts of the SMS client
and the client deployment process.
For information about other SMS client related topics, see the following chapters:
u For information about how sites support roaming and how clients operate within sites, see
Chapter 2, “Understanding SMS Sites.”
u For information about which client type to use or how to plan the deployment of SMS
clients, see Chapter 10, “Planning Your SMS Deployment and Configuration.”
u For detailed client deployment procedures, see Chapter 17, “Discovering Resources and
Deploying Clients.”
u For information about supported platforms and configurations for SMS clients, see the
“Getting Started” chapter.
u For information about upgrading clients to SMS 2003, see Chapter 11, “Planning an
Upgrade,” and Chapter 14, “Upgrading to SMS 2003.”
u For information about international clients, see Appendix D, “Using SMS in International
Organizations,” in the Microsoft Systems Management Server 2003 Operations Guide.

In This Chapter
u SMS Clients
u Client Deployment
u Client Maintenance
u User Control of Clients
98 Chapter 4 Understanding SMS Clients

SMS Clients
Any computer running an SMS 2003-supported operating system that has a connection to your
organization’s network can potentially become an SMS 2003 client. A computer becomes an
SMS client after the SMS client software is deployed on that computer.

Note
There might be independent software vendors that provide support to
computers that are not supported by SMS. For more information, see the
Microsoft SMS Web site at http://www.microsoft.com/smserver.

SMS 2003 includes two client types:


u Advanced Client
u Legacy Client
The Advanced Client is a new client type introduced in SMS 2003. The Legacy Client is based
on the SMS 2.0 client. Both client types can be deployed on desktop computers, mobile
computers, and remote computers; however, the Advanced Client is the recommended client type
to deploy on all computers running Windows 2000 or later. The Advanced Client is especially
recommended for mobile and remote computers because the Advanced Client has features that
are specifically designed to support those types of computers.
For many administrative and end-user purposes, the two client types appear to be identical. For
that reason, you can often administer SMS with little consideration as to which client type is
deployed on individual computers. Both client types support the primary features of SMS, such
as software distribution and inventory collection, with only minor differences.
However, because the Legacy Client is based on the earlier technology of the SMS 2.0 client, it
relies heavily on domain accounts to carry out key tasks on the SMS client computer such as
installing software in an administrative context when the logged-on user account does not have
the appropriate security credentials. The Advanced Client, though, is engineered to use the local
system security context and the computer account to carry out these same key tasks, making the
Advanced Client a much more secure. It is strongly recommended that you install the Advanced
Client as the preferred client on all your SMS client computers running the Windows 2000 or
later operating system.
If you are upgrading an existing SMS 2.0 site to SMS 2003, you are required to run the
Deployment Readiness Wizard (DRW), which indicates whether the existing site meets all the
prerequisites to be upgraded. See Chapter 11 for more information about upgrading to SMS 2003
and running the DRW. The DRW will generate a warning message if it finds that the SMS 2.0
client is installed on any computers in the SMS site that run Windows 2000 or later operating
systems. When you upgrade the SMS 2.0 site to SMS 2003, the Legacy Client is installed on
those computers. This client is supported on Windows 2000 and later platforms primarily to
assist with your migration of these clients to the Advanced Client rather than as a long-term
enterprise solution. It is strongly recommended that you install the Advanced Client as soon as
SMS Clients 99

possible after the upgrade is complete so as to take advantage of the enhanced security and other
benefits provided by the Advanced Client on these platforms.
In fact, the SMS 2003 status message system is designed to periodically notify you that such
client configurations — Legacy Clients installed on computers running Windows 2000 or
later — exist within your SMS site and should be upgraded to the Advanced Client. In addition,
you can run the report or query named Computers Recommended for Advanced Client Upgrade
that displays a list of these computers. You can use the query to create a collection to which you
can advertise the Advanced Client installation to facilitate upgrading all your Legacy Clients to
the preferred Advanced Client.

WARNING
Microsoft currently plans to discontinue support for the SMS Legacy Client
on computers running the Windows 2000 or later operating system
platforms with the release of SMS 2003 SP1.

Remote and mobile computers


In the basic scenario, SMS clients are well-connected to the SMS site systems, and they always
remain in their originally assigned site. In this case, the clients always work with the same site
systems over a local area network (LAN) connection. However, the reality in most organizations
is that many of the computers do not exist in this ideal state.
It is common for users to travel with their computers from one SMS site to another, or to travel to
locations in which SMS sites do not exist, such as a hotel room. Those computers are referred to
as mobile computers. It is also common for small bank branch offices or retail outlets to have
computers at a location that is too small to justify an SMS server to provide local SMS services
to clients. Those computers are referred to as remote computers.
Mobile and remote computers also require management support. Both the Advanced Client and
the Legacy Client support that requirement, as described later in this chapter.

Advanced Client
The Advanced Client is a newly developed SMS client, and is the preferred client type for all
computers running Windows 2000 or later in your organization. The Advanced Client is
especially recommended for mobile and remote computers because its architecture is optimized
for enhanced support for those types of computers.
Advanced Clients use management points to send and receive data from the site server. To
receive configuration and advertised program details, Advanced Clients use policies, which are
sent from management points. The Advanced Client policies are unique to SMS and are not
related to policies associated with Active Directory®.
Advanced Clients cannot be assigned to secondary sites. However, they can use proxy
management points at secondary sites to upload data and to download Advanced Client policies.
100 Chapter 4 Understanding SMS Clients

The Advanced Client provides the following advantages:


u Better support for mobile computers.
u Better support for remote computers.
u Enhanced security. For more information about security, see Chapter 5, “Understanding
SMS Security.”
u Use of Background Intelligent Transfer Service (BITS) to transfer data such as package
source files and inventory data. For more information, see the “How the Advanced Client
Benefits from BITS-enabled Software Distribution” section later in this chapter.
u The Advanced Client can download the package source files to the local computer before
running an advertised program.
u Access to SMS package source files on local distribution points at a site, which the
Advanced Client is temporarily roaming to, without being assigned to that site. This includes
access to distribution points at SMS 2.0 secondary sites, whose parent site is an SMS 2003
site.
u The site server sends to the Advanced Client data that contains only changes to such items as
configurations, advertisements, or software metering rules. This reduces the amount of data
that is transferred on the network.
u The Advanced Client is highly scriptable, which allows for the automation of Advanced
Client configuration and operations.
u Extensive use of Windows® Management Instrumentation (WMI), which allows access to
many Advanced Client internal details for troubleshooting purposes.
u The client agents, such as the Hardware Inventory Client Agent, are installed when the core
SMS client components are installed. This ensures that the Advanced Client always has the
client agents. This also eliminates the need for the extra bandwidth that would be necessary
to download the client agents when enabling a feature.
u When downloading the Advanced Client software during installation, the Advanced Client
installation programs continue to run even if the network connection occasionally becomes
unavailable.
u When deploying Advanced Clients, you can complete the installation of the Advanced Client
software without assigning the client to any site. This allows you to complete the installation
of a large number of computers in a staging area, and then transport the installed computers
to their destination in the production environment. Those computers can then be assigned to
a site and become fully deployed SMS clients.
u The Advanced Client is installed from a Windows Installer package, which provides all the
benefits of Windows Installer.
Advanced Client Support for Mobile Computers
The Advanced Client includes features that are specifically designed to support mobile
computers, so that users of mobile computers can receive management services while roaming
from location to location.
SMS Clients 101

The Advanced Client is particularly effective for mobile computers because it:
u Can access package source files on distribution points in a site that the client is not
assigned to.
u Uses BITS-enabled transfer of package source files, status messages, and inventory.
Advanced Client Support for Remote Computers
The Advanced Client includes features that are specifically designed to support remote
computers. Because the Advanced Client provides BITS-enabled transfer of packages, transfer of
inventory, and updates of client software distribution, SMS client software upgrades do not have
an adverse effect on clients at remote locations.
If you use Advanced Clients at your remote offices and you also have a distribution point at the
remote offices, then you can use protected distribution points to prevent access to the protected
distribution points over slow or unreliable network links. For more information about protected
distribution points, see Chapter 2, “Understanding SMS Sites.”
How the Advanced Client Benefits from BITS-enabled Software Distribution
Background Intelligent Transfer Service (BITS) is a Windows component that performs
background file transfers and queue management. SMS submits requests to BITS, and the
requested files are transferred in a throttled manner so that the end user is not affected by
bandwidth consumption. Requests remain active until the files are transferred, and then SMS is
notified of the completion of the request.
BITS provides the following benefits:
u Package downloads from distribution points use checkpoint restarts, so that if the download
process is interrupted, the download resumes without completely restarting the download. If
the package is downloaded by using BITS, and the client resumes the download from the
same distribution point, the download resumes at the beginning of the last network packet
that was being transferred. Otherwise, the download is resumed at the beginning of the last
file downloaded.
u If the user needs to use the network link for other purposes, such as reading e-mail, BITS
makes the link available to the user. BITS uses the link when the user is not using it.
u BITS uses HTTP so that the Advanced Client can send and receive files in any situation in
which an HTTP link can be established.
u BITS can send and receive information by using a virtual private network (VPN), with or
without a firewall that does not do network address translation (NAT). Use of the Advanced
Client with NAT is not supported.
u A download request is not completed if the version of the package changes. The download is
restarted with the new version. If the Advanced Client changes locations during file
download, it can continue the download by using a local server if a local server is available.
102 Chapter 4 Understanding SMS Clients

Legacy Client
Although it is recommended that you deploy the Advanced Client on all the computers in your
organization running Windows 2000 or later, there are two reasons for deploying the Legacy
Client.
u You must deploy the Legacy Client when the client computer is running Windows 98 or
Windows NT 4.0.
u When you upgrade your SMS sites from SMS 2.0 to SMS 2003, the Legacy Client is
automatically installed on SMS 2.0 clients running Windows 2000 or later to assist you with
migrating these clients to Advanced Client. It is strongly recommended that you upgrade
these clients to Advanced Client as soon as possible after you upgrade your SMS site.
The Legacy Client is similar to the SMS 2.0 client. The Legacy Client uses a client access point
(CAP) to communicate with the site server. The Legacy Client sends inventory and status data to
the CAP and receives configuration and advertised program details from the CAP. The Legacy
Client relies heavily on the use of domain accounts to carry out key tasks on the SMS client,
often in an administrative security context.
In scenarios where the Legacy Client must be installed, it provides the following differences:
u The Legacy Client supports operating systems that the Advanced Client does not.
u Legacy Clients at secondary sites use the secondary site (if assigned to it), which ensures
that the wide area network (WAN) link to other sites is used according to SMS address
settings. This is accomplished with Advanced Clients through the use of a proxy
management point.
u Legacy Clients can be automatically assigned to a new site that they move to. Because
automatic reassignment can result in unpredictable behavior, especially in mobile client
scenarios, this behavior was removed from Advanced Clients. The Advanced Client can be
easily reassigned to new sites in cases of permanent moves with a script or an SMS package.
u Legacy Client software is automatically removed if the client is unassigned from its site.
This can happen if you remove the site boundaries from the site configuration or if the client
moves out of the site boundaries of its assigned site, unless travel mode is enabled. Because
automatic removal can result in unpredictable behavior, especially in mobile client scenarios,
this behavior was removed from Advanced Clients. This activity also makes it more difficult
to prestage the SMS client as part of a computer image and then join an SMS site later.
u With the implementation of SMS features being slightly different on both client types, the
Legacy Client supports some functionality that is not supported on the Advanced Client. For
example, on the Legacy Client, a user can schedule advertised programs to run at a specified
time. The Advanced Client must run advertised programs immediately.Legacy Clients can
make sounds to alert users to the use of remote tools and for software distribution events.
SMS Clients 103

Legacy Client Support for Mobile Computers


In some cases, it might be necessary to deploy the Legacy Client on mobile computers. For more
information, see the “Managing SMS Mobile and Slow-Link Clients” white paper at
http://www.microsoft.com/smserver/techinfo/administration/20/maintaining/mblslw.asp.
Although this white paper refers to the SMS 2.0 client, it is relevant to the SMS 2003 Legacy
Client because the two client types are very similar.
The most significant Legacy Client support mechanism for mobile computers is travel mode.
Travel mode can prevent a Legacy Client from automatically changing its site assignment when
roaming.
When travel mode is turned on and the user starts the client on a different subnet in a different
SMS site, SMS asks if the user wants to unassign the client from its assigned SMS site. When a
client installation method or Client Configuration Installation Manager (CCIM) client cycle later
runs on the client, it prompts the user as to whether the user wants to assign the client to the new
site. If the user declines assignment to the new site, SMS does not prompt the user again for the
same site for 30 days, even if the user roams to that site again.
The Travel Mode option for the client is set on the General tab by clicking Systems
Management in Control Panel. Selecting the This computer connects to the network from
different locations check box enables travel mode. On computers running Microsoft
Windows NT®, Windows 2000, Windows XP, or an operating system in the
Windows Server™ 2003 family, the user must have administrative credentials on the client to
enable or disable travel mode. The user does not need administrative credentials to respond to the
prompt.
The Set Client Travel Mode tool (CliTravl.exe) allows you to set and check the travel mode
options on the client by using a command-line tool. The Set Client Travel Mode tool is useful if
the users of the mobile computers do not have administrative credentials on their computers. In
this case, you can create an SMS package for the tool and advertise the Set Client Travel Mode
tool as an SMS program that is configured to run with administrative credentials. The Set Client
Travel Mode tool is also useful if you want to prevent SMS from prompting the user each time
the client roams to a new site.
The Set Client Travel Mode tool is included in the SMS 2.0 Service Pack Support Tools and is
available from the Microsoft Web site at http://www.microsoft.com/smserver/.
Legacy Client Support for Remote Computers
In some cases, it might be necessary to deploy the Legacy Client on remote computers. For
information about using Legacy Clients for remote computers, see the “Managing SMS Mobile
and Slow-Link Clients” white paper at
http://www.microsoft.com/smserver/techinfo/administration/20/maintaining/mblslw.asp.
If you deploy the Legacy Client on remote computers and you have CAPs or distribution points
at the remote site, an important issue that you should consider is setting the preferred CAP for
those clients and enabling a protected distribution point at the remote site.
104 Chapter 4 Understanding SMS Clients

You can use the Set Preferred Distribution Point and CAP tool (PrefServ.exe) to specify a
preferred distribution point or CAP for the Legacy Client. When the client needs to access a
distribution point or CAP, the client first tries the servers that are specified by this tool. For
information about the Set Preferred Distribution Point and CAP tool, see the Microsoft SMS
Web site at http://www.microsoft.com/smserver.

How Clients Find and Use Site Systems and


Domain Controllers
SMS sites use various site systems when deploying and managing the clients in the site. Clients
need to find and use those site systems for various reasons. SMS clients also must use domain
controllers for security reasons. The following sections describe how SMS clients find and use
SMS site systems and domain controllers.
Client Access Points and Management Points
To manage the clients in a site, data must be transferred between the SMS clients and the site
server. To send data (such as inventory data and status messages) to site servers and to receive
data (such as client configuration data), Advanced Clients use management points and Legacy
Clients use CAPs.
Clients must find and use management points and CAPs during client deployment for the
following reasons:
u When installing Legacy Clients, SMS obtains the Legacy Client software from CAPs.
u When installing Advanced Clients, SMS obtains the Advanced Client software from a
management point.
Clients must find and use management points and CAPs for regular client operation for the
following reasons:
u Legacy Clients use CAPs and Advanced Clients use management points to obtain
configuration details and advertised programs that are sent from the site server.
u An Advanced Client finds advertised programs from the management point of the site to
which it is assigned.
u A Legacy Client finds advertised programs from the CAPs at the sites to which the Legacy
Client is assigned.
u Clients also use CAPs and management points respectively to send inventory and status
information to the site server.
u Advanced Clients use management points to locate a distribution point for an advertised
program. If an Advanced Client is not at its assigned site, but it is at a site that its
management point knows about, its management point can find a locally available
distribution point for the client.
SMS Clients 105

Legacy Clients cannot use CAPs or distribution points in SMS sites that the clients are not
assigned to. However, if you have multiple CAPs or distribution points in a site, and one or more
of those site systems is closer than other systems, you should use PrefServ.exe to indicate that the
closer systems should be used. For more information, see articles 205406 and 235873 in the
Microsoft Knowledge Base at http://support.microsoft.com.
How Advanced Clients find management points
In an Active Directory environment, the client queries Active Directory for a resident
management point. It does this by searching the Active Directory global catalog for a site code,
which has been registered (by a site server) with a matching Active Directory site name or IP
address range. If the client does not find a resident management point or it reverts to the assigned
site because the required content is not available at the local site, then the client uses the site code
of its assigned site. In both cases, the client needs to query Active Directory again to find the
appropriate management point for that site code.
If there is a single default management point at the site, the client gets the name of that
management point from Active Directory. If there are multiple management points behind a
Windows Network Load Balancing cluster, the client gets the IP address of the Windows
Network Load Balancing cluster.
The client might also find that it is within the boundaries of a secondary site with a proxy
management point for its assigned site and use that management point instead of its assigned site
management point.
In a Windows Internet Name Service (WINS) environment, without Active Directory, the client
must query the management point of the assigned site. The client locates the IP address of a
management point by doing a WINS lookup that is based on the site code. This returns the IP
address of the default management point or the virtual IP address of the Windows Network Load
Balancing cluster.
The client makes a special call to determine whether it is within the boundaries of a secondary
site of its assigned site with a proxy management point. If it is within the boundary, the client
finds the proxy management point address in the same way and uses that instead.
Advanced Clients must also determine a management point to use as their assigned management
point. This is done in several ways:
u When the Advanced Client is installed and an SMS site is specified, the Advanced Client
automatically uses the default management point for the site.
u When the Advanced Client is set to automatically determine an SMS site and it finds a site,
the client uses the default management point for that site.
u When a client refresh cycle runs (25 hours after the last client refresh cycle), the Advanced
Client verifies that the default management point for the assigned site has not changed. If the
default management point has changed, the Advanced Client begins using the new default
management point.
106 Chapter 4 Understanding SMS Clients

How Legacy Clients find CAPs


Legacy Clients contain a list of CAPs that are available to them. When the Legacy Client needs a
CAP, it first tries to find a CAP for which there is an existing connection. If none exists, the
client attempts to choose a preferred CAP if one is set. If there is no preferred CAP, the client
randomly chooses a CAP from the CAP list.

Distribution Points
Distribution points can be used during client deployment when using SMS software distribution
to replace Legacy Clients with Advanced Clients. During regular operation, clients use
distribution points to obtain package source files when they are running advertised programs.
Advanced Clients can also use protected distribution points and distribution points at SMS 2.0
secondary sites that report to an SMS 2003 site. Advanced Clients can use distribution points
with BITS enabled, so that they can download package source files in a highly controlled manner
that is suitable for slow or unreliable network connections. For more information about using
SMS 2.0 distribution points, see Chapter 6, “Understanding Interoperability with SMS 2.0.” For
more information about protected distribution points, see Chapter 2, “Understanding SMS Sites.”
How clients find distribution points
The information that is associated with an advertised program includes a list of the distribution
points that clients can use to obtain the necessary package source files. Legacy Clients chose a
random distribution point from that list. If the Legacy Client roams to another site, it can
continue to use the distribution points at its assigned site. The Advanced Client uses a
management point to find a distributions point for an advertised program.
When the Advanced Client roams, it is typically more efficient to download package source files
from the site to which it has roamed than from its assigned site. If the Advanced Client requires
package source files for an advertised program while it is roaming to another site, the Advanced
Client attempts to get those files from a local distribution point. This prevents the Advanced
Client from unnecessarily using slow or unreliable network links. Even though the Advanced
Client is using a distribution point outside its assigned site, it is not assigned to that site.
In an Active Directory environment, SMS queries Active Directory to determine in which site’s
roaming boundaries the Advanced Client is located. Active Directory returns the site code of the
client’s assigned site or of another site in the hierarchy. If the returned site code indicates that the
client is roaming to another site, then SMS queries Active Directory for the management point in
that site. SMS then queries the returned management point for distribution points with the
necessary package source files within that site. If none of the returned distribution points have the
necessary package source files, the client reverts to its assigned site. To find distribution points
within the client’s assigned site, SMS queries Active Directory for the management point in the
assigned site, and then queries the returned management point for distribution points that have
the necessary package source files.
SMS Clients 107

In a WINS environment, the only site code that is available is the site code of the Advanced
Client’s assigned site. SMS queries WINS to find the management point for that site. SMS then
queries the returned management point for a distribution point with the necessary package source
files. Because this site knows about the roaming boundaries and distribution points of all lower
level sites, the management point checks to see in which site’s site boundaries the client is
currently located. This returns the distribution points with the necessary package source files in
that site. If none of the returned distribution points have the necessary package source files, it
returns the distribution points in the client’s assigned site that has the necessary package source
files.

Note
If a management point determines that an Advanced Client is within the
boundaries of multiple sites (because the boundaries overlap), the
management point returns to the client the list of the distribution points in
all those sites. If multiple sites have local distribution points, then the
Advanced Client randomly selects one of those distribution points.

Server Locator Points


Both Advanced Clients and Legacy Clients use a server locator point during client deployment.
The server locator point finds a location that contains the respective client software. However,
each client uses server locator points differently.
Clients must find and use a server locator point during client deployment for the following
reasons:
u Advanced Clients use a server locator point to get information about management point that
they can use to install the client.
u During a low rights installation scenario, Advanced Clients use a server locator point to get
information about a management point that they can send a client configuration request
(CCR) to.
u Legacy Clients use a server locator point to get information about CAPs that they can use to
install the client.
u Advanced Clients can use server locator points for automatic site assignment if
Active Directory has not been extended.
Server locator points have no role during regular client operations.
How clients find server locator points
Clients find server locator points by using Active Directory or WINS, or from the Capinst.exe
command if the /SLP= switch is used.
Domain Controllers
Clients use domain controllers to authenticate domain accounts and to access logon scripts. Some
SMS client installation components might be available on the Netlogon share and be called from
the logon scripts (at the administrator’s discretion).
108 Chapter 4 Understanding SMS Clients

Active Directory Domain Controllers


SMS clients can find server locator points using Active Directory domain controllers. Advanced
Clients can use Active Directory domain controllers to find local sites with distribution points.

Client Deployment
Turning computers into managed SMS clients is referred to as client deployment. Your
organization might have many hundreds or thousands of computers and other resources that you
plan to manage using SMS. Manually deploying SMS on such a large number of computers
could be prohibitively difficult. However, SMS supports several techniques to automate most of
that process.
SMS client deployment consists of the following phases:
1. Discovering resources — locating computers and other types of resources on the network.
2. Installing SMS client software — installing core SMS client components on supported
platforms for both client types and installing client agents on Advanced Clients.
3. Assigning clients to sites — evaluating which SMS site the computer should be assigned to,
if any.
4. Installing client agents — installing the client agent software on Legacy Clients.
On the Advanced Client, the client agents are always installed at the same time that the core SMS
client components are installed (aside from the Remote Control Agent and drivers that can be
installed at a later time). You can configure the Advanced Clients to be automatically assigned to
a site at that time or the client can be manually assigned to a site at another time.
On the Legacy Client, the client is always assigned to a site during the client installation phase,
and the client agents are always installed after the client is assigned to a site.
You can deploy each client type by using different combinations of discovery and installation
techniques. While planning SMS deployment, you must also carefully consider which client type
to deploy and which deployment techniques to use. Concepts of the different client deployment
techniques are described in this chapter. For information about strategies for client deployment,
see Chapter 10, “Planning Your SMS Deployment and Configuration.”

Discovering Resources
Discovering resources is the first phase of the client deployment process. During this phase, SMS
gathers information about resources in your organization’s network and then stores that
information in the SMS site database as discovery data records (DDRs). A resource is any object
found by SMS. Resources can be computers (including mainframes and UNIX workstations),
routers, printers, or user or group accounts.
Client Deployment 109

Note
You can add additional resource types by using details included in the
Microsoft Systems Management Server 2003 Software Development Kit, or
Appendix C, “Scripting SMS Operations,” in the Microsoft Systems
Management Server 2003 Operations Guide.

The information that is gathered during discovery is limited compared to the data that the
inventory feature can later gather. Discovery information includes data such as the name of a
discovered resource, its operating system, and its IP address. Having discovery data in the SMS
site database allows administrators to query the SMS site database for that data. Subsequently,
administrators can include discovery data in reports and include discovered resources in
collections. You cannot use any primary features of SMS, such as inventory or software
distribution, on discovered resources.

Discovery Data Records


The goal of discovery is to locate and gather information about resources on your network.
Although discovery methods behave in different ways and might discover different types of
resources, they all gather information about objects on the network and generate information
about those objects. When a resource is discovered, the discovery component generates a DDR
and forwards it to the SMS site database. Secondary sites forward DDRs to their parent site.
A DDR is a set of information about the discovered resource. DDR properties depend on the type
of resource that is discovered, and on the configuration of discovery methods in the site. For
example, a DDR for a computer has a different set of properties than a DDR for a user account.
A DDR for a computer contains resource properties such as the following:
u SMS unique identifier (GUID)
u NetBIOS name
u IP addresses
u IP subnets
u Operating system name and version
u Domain or workgroup
u Last logon user name
u Agent name (the discovery method that generated the DDR)
u Active Directory container
u Active Directory group
There are other DDR properties. If you have access to Collections in the SMS Administrator
console, you can see the DDR properties for systems and users in the All Systems and All Users
collections by viewing the properties of the resources.
The type of information that SMS gathers depends on the type of resource discovered. For
example, some resources, such as printers, might not have the Operating system name and
version property. The DDR data also varies depending on the discovery method that you use.
110 Chapter 4 Understanding SMS Clients

The operating system name returned by discovery might not be the official product name. The
domain name is not the fully qualified domain name. For better data, use the comparable
properties that are returned by SMS inventory collection.
SMS uses a GUID, if it is available in the DDRs, to match DDRs to existing resources in the
SMS site database. For the system architectures (as seen in the All Systems collection), the
GUID is the SMS Unique Identifier property. If the GUID is not available in the DDR, SMS uses
key properties within DDRs to match incoming discovery information to existing resources. For
the system architecture, the key properties are IP Addresses, AD Site Name, MAC Addresses,
and NetBIOS Name. The DDR might not have all the key properties set, in which case SMS
matches on only the key properties that are set. If a match is made, the existing resource data is
updated. If a match is not made, a new resource record is created.
Discovery Methods
There are several discovery methods that you can use to discover resources. Your choice of
discovery method depends primarily on the types of resources that exist in your organization.
SMS 2003 provides the following discovery methods, which you can enable and configure from
the SMS Administrator console:
u Windows User Account Discovery
u Windows User Group Discovery
u Heartbeat Discovery
u Network Discovery
u Active Directory System Discovery
u Active Directory User Discovery
u Active Directory System Group Discovery
These discovery methods are described in detail later in this chapter.
Other methods to discover resources and to generate DDRs are as follows:
u SMS automatically discovers SMS site systems and site servers. Administrators have no
control over this behavior. This generates discovery data for the site systems and can trigger
their installation as SMS clients.
u SMS automatically generates a DDR when it stores (in the SMS site database) inventory
data from a client for which the SMS site database has no DDR. In this scenario SMS creates
the DDR based on details included in the inventory data. Administrators have no control
over this behavior.
u The Manual Client Installation method always generates a DDR and can discover computers
without installing the SMS client software on them. For more information about Manual
Client Installation, see the “Manual Client Installation” section later in this chapter.
Client Deployment 111

u Writing scripts that generate DDRs. You can write a script that creates DDRs from sources
such as spreadsheets, Active Directory, Microsoft Exchange directories, databases, and even
some unconventional types of resources, such as printers. For more information about
scripting, see Appendix C, “Scripting SMS Operations,” in the Microsoft Systems
Management Server 2003 Operations Guide.
u You can develop logon scripts that generate DDRs for the computers that log on to the
domain.
Although all SMS discovery methods generate discovery data, the different methods discover
different types of resources and serve different purposes, as described in the following sections.
Table 4.1 lists the different discovery methods, which resources they discover, and from where
the discovery data is gathered.
Table 4.1 SMS Discovery Methods
Discovery method Discovered resources Source of discovery data
Windows User Account Windows user accounts Domain controllers
Discovery
Windows User Group Windows user groups Domain controllers
Discovery
Heartbeat Discovery Computers The discovered computer
Network Discovery Computers, routers, and other Network devices
devices that respond to network
requests
Active Directory System Computers Domain controllers
Discovery
Active Directory User Users, user groups, and containers Domain controllers
Discovery
Active Directory System Containers for computers that are Domain controllers
Group Discovery already discovered
Site system discovery Computers serving as SMS site The discovered site system
systems or site servers
Inventory discovery Computers Inventory data
Scripted discovery Computers, users, user groups, or Depending on script
any other kind of resource
(including new resource types)
112 Chapter 4 Understanding SMS Clients

Windows User Account Discovery


When the Windows User Account Discovery method is enabled, SMS polls a domain controller
from each of the specified domains to discover all the domain user accounts (not local user
accounts) that are known to that domain controller. The Windows User Account Discovery
method creates a DDR for each user account.

Windows User Group Discovery


When the Windows User Group Discovery method is enabled, SMS polls a domain controller
from each of the specified domains to discover all the groups that are known to that domain
controller. The Windows User Group Discovery method creates a DDR for each group.

Heartbeat Discovery
When enabled, the Heartbeat Discovery method refreshes SMS client computer discovery data in
the SMS site database. When disabled, client discovery data is refreshed only when another
discovery method is invoked or run on a schedule. The Heartbeat Discovery method is useful for
keeping discovery data up to date without running other discovery methods.
Heartbeat Discovery DDRs are generated on clients during their refresh cycle. The client refresh
cycle runs when you start an SMS client, when you update the SMS client configuration by using
the Systems Management icon in Control Panel, or every 25 hours. When the client refresh
cycle runs, it generates a DDR if the time since the generation of the last DDR is greater than the
frequency at which Heartbeat Discovery is set.

Network Discovery
When enabled, the Network Discovery method gathers information about devices on your
network, like the other discovery methods that are available in SMS do. However, the Network
Discovery method is unique because, besides computers, it also finds network devices such as
printers, routers, and bridges. Basically, the Network Discovery method finds any device on the
network that has an IP address.
You can configure Network Discovery to discover resources in subnets, domains, and Simple
Network Management Protocol (SNMP) devices. If the site is configured with standard security,
you can also configure Network Discovery to discover resources in Microsoft Dynamic Host
Configuration Protocol (DHCP) servers. You can configure Network Discovery to find routers in
an ordered list of community names and specify the maximum number of hops within which to
find routers.
The Network Discovery method can be used to:
u Discover potential SMS clients.
u Collect resource discovery data so that the Client Push Installation method can later install
client components on those resources.
Client Deployment 113

u Gather data so that Network Trace can display a detailed map that includes SMS sites and
the connections between SMS primary site servers and other site systems.
u Collect resource information that you can later use for collections, reports, and queries.
When you enable the Network Discovery method, you can specify the level of detail and the
scope of the discovery information that Network Discovery gathers. These are described in the
following sections.
Discovery Type
You can set the level of details for Network Discovery by selecting one of the following
discovery types: topology; topology and client; or topology, client, and client operation system.
Topology
Network Discovery uses SNMP to discover routers and subnets. SMS Network Trace uses this
data to provide information about the health of network links between SMS site systems. For
more information about Network Trace, see Chapter 10, “Maintaining and Monitoring the
Network,” in the Microsoft Systems Management Server 2003 Operations Guide.
When you select the topology discovery type, Network Discovery discovers subnets and creates
DDRs for network devices that have an SNMP agent. DDRs contain information about each
identified resource.
With the topology discovery type, Network Discovery first connects to the local router (default
gateway) to collect IP addresses from its ipRouteNextHop routing table. Network Discovery uses
this information to find other network devices that are connected to the router.
Network Discovery attempts to query the specified DHCP servers to retrieve the active leases
and defined subnet lists that are configured on that server. Network Discovery then attempts to
resolve the IP address to a name for each network device and subnet that it discovers.
Figure 4.1 illustrates topology discovery.
114 Chapter 4 Understanding SMS Clients

Figure 4.1 Topology discovery


SMS primary
site server

DHCP
server

Local
routers

Router
Bridge

Hub
Router

Topology and Client


Network Discovery uses SNMP, DHCP, and domain browsing to identify routers, subnets,
potential clients, and any other resource, such as printers or gateways, within the specified area of
the network.
With the topology and client discovery type, Network Discovery performs topology discovery
and attempts to discover as many other IP devices as possible within the subnets and domains
that you specify. Network Discovery retrieves the ipNetToMediaTable value from any device
that responds to SNMP. This value returns arrays of IP addresses that are client computers or
other resources such as printers, UNIX workstations, hubs, and bridges.
To establish what the device is, Network Discovery pings the IP address of the device to
determine if it is active. Based on its findings, Network Discovery does one of the following:
u If the device is not active, Network Discovery does not use SNMP to contact the device.
u If the device is active, Network Discovery attempts to use SNMP to determine if it is a
router. If it is a router, Network Discovery retrieves its routing table and gathers any
additional IP addresses in the table. If the device is not a router, but it can still respond to
SNMP, Network Discovery also tries to get any IP addresses that the device has in its table.
Network Discovery then tries to resolve the NetBIOS name. If the name cannot be resolved, the
IP address of the device is used for its name. When the device is displayed under Collections in
the SMS Administrator console, the IP address appears in the Name column.
Client Deployment 115

Network Discovery enumerates the local domain and any other specified domains. Network
Discovery can discover any computer that you can view from your site server when browsing
My Network Places on your Windows desktop. Network Discovery retrieves the IP address and
then pings (using an Internet Control Message Protocol echo request) each device that it finds to
determine which computers are currently active. Network Discovery must find the subnet mask
for the device to create a DDR for it. As a result, domain discovery is not a good source for the
information that is needed to report a device. Figure 4.2 illustrates topology and client discovery.
Figure 4.2 Topology and client discovery

SMS primary
site server

DHCP
server

Domain
controller

Local
routers

Router
Bridge
Printer

Hub
Router
Client

Client

Client Client

Topology, Client, and Client Operating System


Network Discovery uses SNMP, DHCP, domain browsing, and Windows Networking calls to
identify the same items as in the topology and client discovery type and the operating systems of
potential clients within the specified area of the network. This level increases the scope of your
collections by populating collections that are based on operating systems related queries.
However, the extra time that is required to retrieve the operating system information increases
the discovery time and the network traffic.
116 Chapter 4 Understanding SMS Clients

With the topology, client, and client operating system discovery type, Network Discovery
attempts to find devices and IP addresses by using the mechanisms described in the “Topology
and Client” section earlier in this chapter. Network Discovery then performs a LAN Manager call
to each computer to identify the operating system. As a result, Network Discovery successfully
identifies the operating system of any computer supporting LAN Manager calls. The following
platforms support LAN Manager calls:
u Windows NT 4.0
u Windows 2000
u Windows XP
u Windows Server 2003 family
u Windows 95
u Windows 98
u Windows for Workgroups
u Some UNIX workstations
u Some MS-DOS® computers

Note
During network discovery, the operating systems for all computers running
Windows 95, Windows 98, and Windows Millennium Edition are displayed as
Windows 9x in the SMS Administrator console because they all report the
same operating system version through LAN Manager. However, when you
deploy computers running Windows 98 as SMS clients, SMS displays their
operating system correctly.

Figure 4.3 illustrates topology, client, and client operating system discovery.
Client Deployment 117

Figure 4.3 Topology, client, and client operating system discovery


SMS primary
site server

DHCP
server

Domain
controller

Local
routers

Router
Bridge
Printer

Hub
Router Server

Client

Client Client
(Windows 98) (Windows XP)

Discovery Scope
Network Discovery can use various methods to gather information about resources on your
network. You can configure Network Discovery with a discovery scope to control the methods
that are used. Discovery scope can include subnets, domains, SNMP devices, and, if the site is
configured with standard security, DHCP servers. Depending on the specified discovery scope,
Network Discovery can discover resources such as computers, gateways, routers, IP addresses,
subnet masks, and media access control (MAC) addresses. When Network Discovery searches
for system resources, it processes these combined options to gather the required information and
to generate a single DDR for each discovered resource.
118 Chapter 4 Understanding SMS Clients

By default, Network Discovery attempts to enumerate the computers in the local domain by
using the Windows Computer Network Browser service (that is, browsing). You can also specify
additional domains to discover. Network Discovery can discover computers in the same domains
that can be discovered by using the site server to browse My Network Places.

Note
Although Network Discovery can gather data about resources in domains, a
DDR is created only for devices that have an IP address within the discovery
scope.

To gather data from SNMP devices, Network Discovery uses specified SNMP community names
to access the SNMP devices. Each community name must have Read access to at least some of
the devices to gather information. By default, Network Discovery uses the SNMP default
community name public. If your SMS site server has multiple network interface cards, then
Network Discovery attempts to connect to all of the local SNMP devices.
To discover routers on the local network, Network Discovery uses the Router Information
Protocol and SNMP and listens for Open Shortest Path First (OSPF) multicast addresses.
Network cards typically support the filtering of multicast addresses, and the operating system
registers with them when an application registers with Winsock. If an application fails to register
because the network card cannot support any more multicast filters, the operating system
typically clears out the filters, registers for all multicast addresses, and performs the filtering
itself. In cases where no more slots exist on a network card, Network Discovery cannot use
OSPF. As a result, the router is only discovered if it has SNMP enabled.
You can specify a hop count to limit the number of routers from the default gateway that
Network Discovery tries to discover. If the hop count is set to zero, Network Discovery searches
only the default gateway. If the hop count value is greater than zero, Network Discovery contacts
each of the devices within the range of the specified hop count, establishes whether they are
routers by using the ipForwarding scalar on the router, and then retrieves data from their routing
tables. Network Trace uses this information to build diagrams of SMS site systems.
Figure 4.4 illustrates the router hop count process. Each time that you increment the hop count,
you extend the discovery to another set of gateways. Incrementing the hop count is an effective
method of enabling discovery for your entire network.
Client Deployment 119

Figure 4.4 Router hop count


Server 1

Router C

Router B
0 1
2
Router A
1 2 Router F
1
2
Router E

Router D

If your site server is also a DHCP client, DHCP discovery is automatically enabled for its DHCP
server. The DHCP server managing this process stores:
u A database of the MAC addresses belonging to computers requesting IP addresses.
u The IP address of each computer.
u The name of each computer.
u The configuration information for the DHCP server.
The DHCP server uses its configuration information to determine which networks it is managing.
Network Discovery retrieves information from the DHCP server in the form of remote procedure
calls made directly to the database on the DHCP server.
Static IP addresses are not always discovered when Network Discovery enumerates the DHCP
server. Network Discovery neither finds IP addresses that are configured as part of an excluded
range of IP addresses on the DHCP server nor discovers IP addresses that are reserved for
manual assignment. If your network devices use SNMP, Network Discovery can use SNMP to
find their static addresses.

Active Directory System Discovery


The Active Directory System Discovery method polls the specified Active Directory containers,
such as domains and sites in an Active Directory domain controller, to discover computers.
Active Directory System Discovery can also poll the specified Active Directory containers
recursively. Active Directory System Discovery connects to each discovered computer to retrieve
details about the computer. The Active Directory domain can be in mixed mode or native mode.

Note
Active Directory System Discovery does not create a DDR for computers to
which it cannot connect. The DDR is created during a subsequent polling
when connecting to the computer is possible.
120 Chapter 4 Understanding SMS Clients

The Active Directory System Discovery method gathers discovery information such as:
u Computer name.
u Active Directory container name.
u IP address.
u Active Directory site.
Active Directory System Discovery does not include the computer’s operating system in its
DDR. Other discovery methods (such as Heartbeat Discovery) set the operating system property
for the resource.
SMS must have Read access to the containers that you specify for Active Directory System
Discovery by using the SMS Service account or the site server computer account, depending on
the security mode that SMS is running in. When the SMS Service account or site server computer
account is used in domains other than the domain in which the site server is located, the account
must have user rights on those domains. The account must at least be a member of the Domain
Users group or local Users group on the domains.

Active Directory User Discovery


The Active Directory User Discovery method polls an Active Directory domain controller to
discover users and the user groups of which they are members. Active Directory User Discovery
can also poll the specified Active Directory containers recursively. The Active Directory domain
can be in mixed mode or native mode. You specify the containers that you want polled (such as
specific domains, sites, organizational units, or user groups), and SMS routinely polls the
containers (and, optionally, their child containers) for users and their user groups. You can also
adjust the schedule of the polling.
The Active Directory User Discovery method gathers discovery information such as:
u User name.
u Unique user name (includes domain name).
u Domain.
u Active Directory container names.
u Security group and other group names such as groups, global group, or universal group
membership, including nested group membership.User groups (the relationship between the
users and user groups, not just the properties of the users and user groups separately).
SMS must have Read access to the containers that you specify for Active Directory User
Discovery by using the SMS Service account or the site server computer account, depending on
the security mode in which SMS is running. When the SMS Service account or site server
computer account is used in domains other than the domain in which the site server is located,
the account must have user rights on those domains. The account must at least be a member of
the Domain Users group or local Users group on the domains.
Client Deployment 121

Active Directory System Group Discovery


The Active Directory System Group Discovery method polls an Active Directory domain
controller to discover system groups for computer systems that are discovered by other discovery
methods and assigned to the SMS site. In this way, Active Directory System Group Discovery
enhances the discovery data of other discovery methods. If a resource is not assigned to an SMS
site, Active Directory System Group Discovery does not discover system group information for
that resource.
The Active Directory System Group Discovery method gathers discovery information about:
u Organizational unit.
u Global groups.
u Universal groups.
u Nested groups.
u Other non-security groups such as Windows distribution groups.
The Active Directory domain can be in mixed mode or native mode. You specify the containers
to be polled (such as specific domains, organizational units, or user groups), and SMS routinely
polls the containers (and, optionally, their child containers) for the system groups. You can also
adjust the schedule of the polling.
SMS must have Read access to the containers that you specify for Active Directory System
Group Discovery by using the SMS Service account or the site server computer account,
depending on the security mode in which SMS is running. When the SMS Service account or site
server computer account is used in domains other than the domain in which the site server is
located, the account must have user rights on those domains. The account must at least be a
member of the Domain Users group or local Users group on the domains.

Installing SMS Client Software


Installation of the SMS client software is the process of installing the core SMS client
components on computers to allow communication with other systems in the SMS site. You must
install core SMS client components so that SMS can manage those computers and so that SMS
can later use client agents to support SMS primary features such as software distribution and
inventory.
On Advanced Clients, the client software installation phase includes installation of both the core
SMS client components and the SMS client agents. On Legacy Clients, installation of client
agents is a separate process, which occurs after the installation of the core SMS client
components.
122 Chapter 4 Understanding SMS Clients

The Advanced Client is installed from a Windows Installer package. This allows the Advanced
Client installation program to use the installation properties that are supported by Windows
Installer. For example, the SMS 2003 client installation can be completely reversed if the
installation fails before it is completed. This ensures that the computer is left in a safe state even
if the client installation fails. When installing Advanced Clients, you also have several options
for specifying the configuration details for each client. For example, you can specify that the
Advanced Client is installed only on laptops, the site to which the Advanced Client should be
assigned, or that the Advanced Client is installed only on computers with a specified registry
value.

Note
When installing an Advanced Client on a computer with the Legacy Client
software installed, the Advanced Client installation program first uninstalls
the Legacy Client from the computer. If the Advanced Client installation later
fails, the Legacy Client cannot be reinstalled when the computer is reversed
to its preinstallation state.

Typically, there are many computers in a site. SMS supports several client installation
techniques, which you can use to automatically and efficiently install client components on all
computers.
By default, the core SMS client components are installed in the %windir%\MS\SMS directory on
Legacy Clients and the %SystemRoot%\System32\CCM directory on Advanced Clients.
The various client software installation techniques are further described in the following sections.

Client Software Installation Techniques


After SMS discovers resources on the network, you must install the SMS client software on those
computers so that SMS can manage them. Because organizations operate in diverse
configurations, SMS supports several client installation techniques to install SMS client software.
You can choose different combinations of installation techniques to ensure that the SMS client
software is installed on all the computers in the site.
SMS supports the following client installation techniques:
u Using the Client Push Installation method in the SMS 2003 Administrator console
u Initiating a program file at the client to install the client software, as follows:
u Using Logon Script-initiated Client Installation
u Manually running a program file
u Using Windows Group Policy
u Using SMS software distribution or some other software distribution mechanism to
advertise and run a program file
u Installing the Advanced Client on a computer master image and imaging that computer to
other computers
Client Deployment 123

Table 4.2 highlights which client type can be installed by using each client installation method
and how each method is initiated.
Table 4.2 SMS Client Installation Techniques
Installation technique Client type How it is initiated and applied
Client Push Installation Both An SMS administrator enables the Client Push
method Installation method in the SMS Administrator console.
When enabled, on receipt of DDRs from uninstalled
clients, the client installation starts.
Also, SMS administrators run the Client Push
Installation Wizard for a selected collection or query.
Logon Script-initiated Both Logon scripts are customized to run Capinst.exe.
Client Installation
Manually Both A user or SMS administrator initiates Smsman.exe to
install a Legacy Client or Ccmsetup.exe (Advanced
Client Installer) to install an Advanced Client.
Windows Group Policy Advanced Client Windows Group Policy.
Software distribution Advanced Client Advertising an Advanced Client installation program
and then running that program.
Imaging Advanced Client Deploying the Advanced Client on a master image
computer and then imaging that computer to other
computers.

Only the Client Push Installation method requires clients to be discovered before they are
installed. If the computers have not already been discovered when the SMS client software is
installed on them, SMS generates DDRs for those computers.
Client installation executables
The various client installation techniques use one or more of the following executable files:
Client.msi A Windows Installer package containing the Advanced Client software. Regardless
of the installation techniques, this file must be copied to the computer that is being deployed as
an Advanced Client.
SMSMan.exe Runs the Systems Management Installation Wizard to install the Legacy Client
software.
CCMSetup.exe A wrapper to Client.msi. This executable file is referred to as the Advanced
Client Installer.
The Advanced Client Installer is used in all Advanced Client installation techniques except for
Windows Group Policy. When started, Advanced Client Installer installs the Advanced Client by
intelligently pulling Client.msi and a language-specific transform, if available, down to the
computer. The files are downloaded and then stored in the %Windir%\System32\ccmsetup
folder. After the download is complete, it installs the client components on the computer.
124 Chapter 4 Understanding SMS Clients

The download process stops while the user is logged off or while the computer is in a power
standby unless CCMSetup.exe is installed as a service. Advanced Client Installer can install itself
as a temporary service, in which case it continues to install the SMS client even if the user logs
off. If the computer restarts, the service automatically starts. When the user logs on,
the installation runs. When the service completes the installation, it removes itself as a service.
Capinst.exe Locates a server locator point, and then the server locator point returns information
about the CAPs or management points that are available for client installation (for the site to
which the client is to be assigned). Capinst.exe then starts CCMSetup.exe or SMSMan.exe, as
appropriate.
Client Push Installation
You can enable and configure the Client Push Installation method in the SMS Administrator
console. When enabled, this method finds newly discovered and assigned computers and
attempts to remotely connect to them. If the connection is successful, Client Push Installation
installs the specified client type without user intervention on the installed computers. The Client
Push Installation method installs client software on computers running Windows NT,
Windows 2000, Windows XP, or operating systems in the Windows Server 2003 family.
By default, Client Push Installation does not install clients on domain controllers, and onsite
systems. Site systems are discovered automatically by SMS. By default, when a site system is
discovered, SMS does not trigger Client Push Installation to install a client on the site system,
even if Client Push Installation is enabled. However, you can configure Client Push Installation
to install the SMS client on site systems. You can use Client Push Installation to replace a
Legacy Client with an Advanced Client, but you cannot use Client Push Installation to replace an
Advanced Client with a Legacy Client.
Client Push Installation requires that you give administrative credentials on all chosen client
computers to either the SMS Service account (if the site is running in standard security mode) or
Client Push Installation accounts. For more information, see Chapter 5, “Understanding SMS
Security.”
Client Push Installation of Advanced Clients uses CCMSetup.exe as a service.

Note
Client Push Installation requires that the Server service is started on the
client computers, that file sharing is enabled, and that the ADMIN$ share
exists.

Using the Client Push Installation Wizard


By using the Client Push Installation Wizard, you can use Client Push Installation to install the
Advanced Client or Legacy Client on individual computers, or on all the computers that are in a
collection or that are returned in an SMS Administrator console query. You can even use the
Client Push Installation Wizard to install SMS clients on computers that Client Push Installation
is not enabled for, such as domain controllers.
Client Deployment 125

You can also configure the Client Push Installation Wizard to collect status about systems,
without installing client software on those systems. With this configuration, SMS checks whether
systems are online or offline, and whether SMS can access those systems. SMS generates status
messages for systems that are offline, and for systems that are not accessible.
When using the Client Push Installation Wizard to install Legacy Clients, the installed computer
must be assigned to the SMS site to which you are connected in the SMS Administrator console
when you run the Client Push Installation Wizard. The site also must have a CAP available for
Legacy Clients or a management point available for Advanced Clients. You cannot use the Client
Push Installation Wizard to replace an Advanced Client with a Legacy Client.
Logon Script-initiated Client Installation
By using logon scripts, you can deploy Legacy Clients from CAPs or Advanced Clients from
management points. This client installation technique uses the Capinst.exe file and is referred to
as Logon Script-initiated Client Installation.
When set up, Logon Script-initiated Client Installation locates server locator points in either of
the following ways:
u The SMS administrator specifies a server locator point as an argument to Capinst.exe.
u Logon Script-initiated Client Installation locates the first server locator point that is
registered in the Active Directory global catalog.
The server locator point that was found returns information about the CAPs or management
points that are available for client installation. If the user has administrative credentials, Logon
Script-initiated Client Installation installs the client from the CAP or management point as
appropriate. If Logon Script-initiated Client Installation finds multiple sites to which the client
could be assigned, it chooses a site based on the site version, the client types that each site
supports, and the alphabetical order of the site codes of the site.
For Logon Script-initiated Client Installation, after a Legacy Client finds server locator points,
the server locator points returns a site code and a list of CAPs for the site. The client then
chooses a CAP randomly from the list of CAPs.
If an Advanced Client will be installed, CCMSetup.exe is used if the user has administrative
credentials. If the user does not have administrative credentials, a CCR is submitted to the site,
which then initiates the Client Push Installation method.
By default, Logon Script-initiated Client Installation does not install SMS client software on
domain controllers.
Manual Client Installation
You can install the SMS client software manually for both Legacy Clients and Advanced Clients
as described in the following sections.
126 Chapter 4 Understanding SMS Clients

Legacy Client
You can manually run Smsman.exe to start the Systems Management Installation Wizard on
computers that you want to deploy as Legacy Clients. This installation method is referred to as
Manual Client Installation. You can use the wizard to install SMS on computers when you do not
want to use an automated client installation method (for example, when testing SMS in your test
lab).
For Manual Client Installation, the CAP is determined either from the path from which
Smsman.exe is run or by supplying the path to a CAP by using a command-line switch.
Manual Client Installation can be run silently, and it can be run only to discover, not to install,
clients.
Advanced Client
Under certain circumstances, such as when building a computer image or when building a
training lab, you might need to manually install an Advanced Client. You can do this by
manually running the Advanced Client Installer (Ccmsetup.exe) on the computer that you want
to deploy as an Advanced Client.
Using Software Distribution
You can install Advanced Clients by using the same software distribution techniques that you use
when installing any application software.
By using SMS software distribution, you can advertise the Advanced Client components to
collections of SMS Legacy Clients that need to be replaced by Advanced Clients. SMS provides
a package definition file for installing an Advanced Client. The package definition file contains
all necessary object definitions that are needed to advertise an Advanced Client installation
program. You can also use non-SMS software distribution techniques, such as distribution of
CDs, Group Policy or IntelliMirror software distribution, or installation from network shares.
Imaging
You can install the Advanced Client on a client computer master image by installing core SMS
client components without specifying an SMS site code for assignment. All computers that are
later imaged from that master image will contain the Advanced Client software. However, the
imaged computers will not be functional as SMS clients until you assign them to an SMS site.

Assigning Clients to Sites


Each SMS client must belong to an SMS site. The site that a client is belongs to is referred to as a
site assignment. The assignment process determines which SMS site will manage a client
computer. Legacy Clients are automatically assigned to an SMS site during the client installation
phase. Advanced Clients can be automatically assigned to an SMS site during the client
installation phase or at a later time.
Client Deployment 127

Site assignment allows you to manage clients at each site differently from clients at other sites.
For example, you might set the software distribution client agent at your headquarters site to
check for new advertisements once every hour, but set the software distribution client agent to
check daily at remote locations that might use a limited set of applications that rarely change.
Site assignment also allows clients to normally report and receive data from a relatively close
site, usually on the same LAN.
When you configure an SMS site, you specify the site boundaries and roaming boundaries of that
site. During deployment, the installed clients use those settings to determine site assignment.

Note
If a client has multiple network cards (possibly a LAN network card and a
dial-up modem), and therefore has multiple IP addresses, the network card
that is bound first is used for evaluating Advanced Client site assignment

Advanced Clients site assignment


Advanced Clients can be automatically assigned to a site (to primary sites only) during the client
installation phase or manually at a later point. During installation, Advanced Clients can be
configured to be assigned to a specific site or they can be configured with auto-assignment and
automatically determine a site to which to be assigned. If the Advanced Client is not assigned to
any site during the client installation phase, the client installation phase completes, but the client
is dormant. An Advanced Client is considered dormant when it is installed but, because it is not
assigned to any site, it is not functional as an SMS client.
Advanced Clients that are configured with auto-assignment attempt to locate an SMS site from
roaming boundaries that are stored in the Active Directory global catalog. If the Advanced Client
cannot find a site by using the Active Directory data, it tries to find a server locator point that can
find a site for the client. Server locator points are found from Active Directory or from WINS. If
the Advanced Client cannot find a site with roaming boundaries that it is currently in, it checks
the next time it is restarted.
Advanced Clients can be automatically assigned to a site only if they are not currently assigned
to any site. After the Advanced Client is assigned to a site, the client remains assigned to that site
even if it roams to another site. Only an administrator can later manually assign the client to
another site or remove the client assignment.
Legacy Clients site assignment
Legacy Clients are assigned to sites automatically during the client installation phase. The
installation program compares site boundaries from CAPs with the computer’s IP subnet or
Active Directory site assignment. If the computer’s IP subnet or Active Directory site assignment
matches any site’s site boundaries, the computer is assigned to that site and the client installation
continues. If the IP subnet or Active Directory site assignment is not within the site boundaries of
any site, the installation process stops, and the computer does not become a Legacy Client.
128 Chapter 4 Understanding SMS Clients

Legacy Clients evaluate their site assignment during client refresh cycles. The client refresh cycle
runs when the client service restarts, once every 25 hours, or when the user initiates a
configuration update. This evaluation is done in case the computer has changed its IP address or
Active Directory site assignment, or in case the SMS site boundaries have changed. If the client
is no longer within the site’s site boundaries, the client is unassigned from the site and the client
software is removed from that client.

Unassigned Clients
It is possible for computers to be discovered but not assigned to any SMS site. This happens in
locations where both the subnets and Active Directory sites are not included in any SMS site
boundaries or roaming boundaries.
Computers that are discovered but not assigned to a site have the following characteristics:
u The computer is not functional as an SMS client and SMS features (such as software
distribution or Remote Tools) cannot be used on the computer:
u For Legacy Clients, the SMS client software is not installed.
u For Advanced Clients, the SMS client software might be installed, but the client is
dormant.
u In Control Panel:
u The Components tab, which is accessed by clicking the Systems Management icon, is
empty.
u The Sites tab, which is accessed by clicking the Systems Management icon, is empty
for the Legacy Client. For the Advanced Client, the Currently assigned to site code
value on the Advanced tab is blank or Auto.
u When viewing collections in the SMS Administrator console that contain discovered but
unassigned computers, the value in the Assigned column is No.

Note
If a client has a different code page from the servers that receive its
discovery data, the servers might not be able to use the discovery data and
will not assign the client to the site even if it should be.

Installing SMS Client Agents


To be able to use SMS primary features such as software distribution and inventory, the client
computers must contain the respective client agents.
Client Maintenance 129

When installing the Advanced Client software, by default, all SMS client agents are installed,
aside from the Remote Control Agent and drivers that can be installed at a later time. Client
agents on the Advanced Client are then activated or deactivated whenever the administrator
enables or disables the respective feature. When assigning an Advanced Client to a site, SMS
activates client agents, depending on the configuration of the site to which the client is being
assigned.
SMS installs client agents on Legacy Clients when the SMS administrator enables the respective
feature for the site. If the SMS administrator then disables a feature for the site, SMS removes the
respective client agent from the client computer. When assigning a Legacy Client to a site, SMS
installs the appropriate client agents, depending on the configuration of the site to which the
client is being assigned.
After the SMS administrator enables or disables a client agent, the client agent installation or
removal at the Advanced Clients and Legacy Clients occurs at the next client’s refresh cycle.

Client Maintenance
As with any other part of your IT infrastructure, you need to maintain your SMS clients by
configuring, changing, or upgrading them as new versions of the client software become
available. When business needs change, you might need to remove the client software from
computers.
Legacy Clients run a daily client maintenance cycle that uses data on the CAP to verify that the
client has the latest SMS client software. SMS updates the client if newer software is available.
The Advanced Client is always installed, upgraded, or repaired as a Windows Installer package.
Therefore, you can upgrade an Advanced Client only by distributing the Advanced Client
upgrade software by using software distribution techniques. When installing Advanced Clients,
you can store the Advanced Client software wherever you decide is the best location. However, if
a newer version of the software becomes available, you are responsible for upgrading the
locations where the client software is stored.

Configuring Clients
The SMS administrator controls client settings by configuring client agents in the SMS
Administrator console. The SMS administrator enables, disables, and configures the client agents
of the features and other properties of the clients.
The site server sends client configuration details to the clients through the site CAPs and
management points. Client configuration details for Advanced Clients are stored in the Advanced
Client policy on a management point.
Each client in the site is updated with configuration changes at the next client refresh cycle.
During the client’s refresh cycle, the Legacy Client contacts a CAP. The Advanced Client
requests a policy from management points and stores that policy as WMI classes and instances. If
there are any configuration changes, the clients implement those changes at that time.
130 Chapter 4 Understanding SMS Clients

Usually, all clients in the site are configured with the same settings. However, in some instances,
individual clients might need customized configuration. This is possible by doing one of the
following:
u The administrator can allow users to locally control some site-wide settings. Individual
clients can then override the respective site-wide setting with a local setting as required. For
more information, see the “User Control of Clients” section.
u Users on Advanced Clients can, in some cases, override the client site-wide setting. You can
use SMS software distribution (or other means) to distribute scripts or Managed Object
Format files that override the client’s local classes and instances in WMI. For more
information, see the Microsoft Systems Management Server 2003 Software Development Kit.
u If you need to customize configuration for several sets of clients, you can create additional
SMS sites. Assign the clients to the sites, based on their configuration requirements. Ensure
that all clients with similar configuration requirements are assigned to the same site and then
configure the site-wide client settings accordingly. This can be an expensive solution in
terms of hardware, licensing, and maintenance compared to the other solutions.

User Control of Clients


After installing the SMS client software, SMS client services start running on the client
computer. Typically, users of computers that are SMS clients are not aware that their computers
are part of an SMS hierarchy. SMS is designed to be unobtrusive to end users.
The client software includes several icons that allow users to manage the SMS client. The
installation of the core SMS client components adds the Systems Management icon to Control
Panel. The user can use this icon to display various properties of the client and to manage the
client.
When the administrator enables SMS features, the appropriate client agents install on Legacy
Clients in the site. During installation, some client agents, such as the Software Distribution
Client Agent, add icons to the client Control Panel. When the SMS administrator disables the
respective SMS features, the associated icons are removed from the clients. The client
implements those configuration changes during its refresh cycle. SMS features provide icons to
the client’s desktop as follows:
u When software distribution is enabled in the site, each Legacy Client has the Advertised
Programs and the Advertised Programs Monitor icons in Control Panel. Advanced
Clients have the Run Advertised Programs and Program Download Monitor icons in
Control Panel.
Also, depending on the configuration of the Software Distribution Client Agent, the user
might notice the following:
u Advertised programs that become available
u Advertised programs that run or count down before they run
User Control of Clients 131

u When Remote Tools is enabled in the site, each Legacy Client has the Remote Tools icon in
Control Panel. However, with the Advanced Client installed, the Remote Tools icon is
present whether or not Remote Tools has been enabled on the site. Depending on the
configuration of the Remote Control Client Agent, the user might notice it when a request
for a remote control session arrives or when a remote control session is in progress.
By using these icons, the user can configure and control the use of SMS features on their
computer, to the extent that the SMS administrator allows.
Systems Management Control Panel Icon
The Systems Management icon is installed in Control Panel on all SMS clients. Clicking this
icon displays information about the SMS client software that can help when troubleshooting the
client.
To view the Systems Management properties, go to Control Panel and double-click Systems
Management.
On the Legacy Client, the Systems Management Properties dialog box has three tabs. The
General tab shows the discovery data for the computer. The Site tab displays the name of the
site to which the computer is assigned. This tab also shows the last time that the client received
configuration data from the site. The user can refresh the configuration data by clicking Update.
The Components tab displays a list of components that are installed on the client and the status
of each component. The status is either Installed, Repair pending, or Reboot required. If the
client was discovered but not assigned, no components are displayed. The user can repair the
component installation by selecting the component and clicking Repair Installation. This step
reinstalls the component from the site. The user can refresh the status display by clicking
Refresh Status. If a component can be started independently, the user at the client can start it by
selecting it and clicking Start Component.
On the Advanced Client, the Systems Management Properties dialog box has four tabs. The
General tab shows the discovery data for the computer. The Components tab displays a list of
components that are installed on the client and the status of each component. The status is either
Installed or Enabled. Only client agent components can have the Enabled status, which means
that the site that the client reports to has that client agent enabled.
The Actions tab lists actions that can be executed for the client agents. The Advanced tab allows
control of the site code and the software distribution cache.
Starting a client refresh cycle selects Update Configuration on the Sites tab of the System
Management icon in Control Panel.

Manually Starting Client Agents


On some occasions, you might want to manually start the client agents instead of waiting for
their next scheduled cycle. For example, if a client is not receiving software distributions, you
might want to start the software distribution agent to observe what happens when it runs. Or, if
you changed the hardware inventory collection, you might want to start the hardware inventory
agent to verify that hardware inventory is collecting data according to the new settings.
132 Chapter 4 Understanding SMS Clients

You can start client agents from Systems Management in Control Panel. On the Advanced
Client, click the Actions tab, select the action that corresponds to the agent you want to start, and
then click Initiate Action. On the Legacy Client, click the Components tab, select the agent,
and then click Start Component.
On a Legacy Client, to start client agents from the command line or from scripts, use the Set
Client Event tool (SetEvnt.exe) or the Client Utilities tool (Cliutils.exe) from the SMS 2.0
Service Pack Support Tools. For information about how to use those tools, see the Support Tools
documentation. For the Advanced Client, the agents can be started by using scripts. For more
information, see the Microsoft Systems Management Server 2003 Software Development Kit.
You must have administrative credentials on the client to manually start client agents.

Determining Client Version and Type


Determining the version and type of the SMS client software that is installed on a computer is
often important during troubleshooting and for other purposes such as verifying the success of
client deployment. You can check the client version and type from the SMS Administrator
console or on the client’s computer.
From the SMS Administrator Console
In the SMS Administrator console, you can determine the client version and type by viewing the
properties of computers in collections and queries. The ClientType property is 0 if the client is a
Legacy Client and 1 if the client is an Advanced Client. These are properties of the
SMS_R_System class and the v_SMS_R_System view. You can use this information when
creating queries and reports.
From the Client Computer
You can determine the client version by viewing the information on the Components tab of the
Systems Management icon in Control Panel on the client itself.
The client’s version is stored in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\
SMS Client Base Components\Installation Properties|Installed Version
This is useful if you need to determine the client version by using a script or any other
programmatic method.
On the Advanced Client, this client’s version registry key value is set to 99.9.9999.9999. This
value ensures that the Advanced Client software is never overwritten by the Legacy Client
software. To determine the client’s software version, you can check WMI. The client’s software
version is stored in the ClientVersion property of the SMS_Client class in the root\CCM
namespace.
At a client, you can determine the client type by the SMS client installation directory. If a
%Windir%\MS\SMS directory exists, then the client is a Legacy Client. If a
%Windir%\System32\CCM\Clicomp directory exists, then the client is an Advanced Client.
Also, the Systems Management icon in Control Panel on the Advanced Client has an Actions
tab, which the Legacy Client does not have.
C H A P T E R 5

Understanding SMS
Security

Computer management systems such as Microsoft® Systems Management Server (SMS) are
powerful systems and they often involve many, if not all, of the computers in an organization. It
is critical that the security of your management systems does not become compromised. By
properly securing your management systems, you help to ensure that unauthorized persons
cannot use your management systems to access or disable your organization’s computers. You
can also audit the activity of authorized SMS administrators to ensure that they do not misuse
their privileges.
Because SMS security is extremely important and because SMS is used in a wide variety of
environments, SMS gives you a number of security options. You can select a combination of
options that is appropriate for your organization, as described in Chapter 12, “Planning Your
SMS Security Strategy.” But first you must understand SMS security.
To provide all the flexibility, control, and interoperability that are required in the varied
environments that SMS is used in, SMS includes numerous security options. With an overview
of SMS security you can focus on the elements that are most relevant to you, and begin the
security planning process with sufficient understanding to make the appropriate decisions for
your organization.
Documented policies and procedures are beneficial for any system, and they are especially
required for SMS security. By documenting your company’s SMS security policies and the
procedures to be used, all relevant staff and managers can have an opportunity to review those
policies and procedures in a systematic way and ensure that your SMS sites remain secure.
SMS 2003 builds on the strong SMS 2.0 security environment in the following ways:
u Provides an advanced security mode that takes advantage of local system and computer
accounts that are automatically maintained by the operating system
u Provides an Advanced Client that takes advantage of local system and computer accounts to
run client-based tasks
u Uses hashing to ensure the integrity of software distribution packages
u Reduces the impact on domain controllers by eliminating the need for SMS 2.0 logon points
134 Chapter 5 Understanding SMS Security

u Eliminates the requirement that the SMS Service Account have domain administrator rights
u Signs all site-to-site communications between SMS 2003 sites, and between SMS 2003 and
SMS 2.0 sites running Service Pack 5
u Integrates support for Active Director® security environments

Note
Security is easier to manage if you configure it consistently throughout your
SMS hierarchy.

In This Chapter
u SMS Security Environment
u SMS Security Modes
u SMS Accounts and Groups
u SMS Object Security
u SMS Feature Security
SMS Security Environment 135

SMS Security Environment


A combination of technologies contributes to the SMS security environment. You must
understand the security details of each technology well in order to understand their relationship to
SMS and how they might affect SMS security. In addition, you must use the security
technologies in a secure physical environment and establish appropriate policies and procedures
to review and adjust the security environment.
This section describes the technologies that support the SMS security environment, including:
u Operating System Security
u SQL Server™ Security
u Windows Management Instrumentation Security
u Internet Information Services Security
u Network Security
u Physical Security

Operating System Security


SMS is very dependent on the operating systems you use and their security subsystems. Not only
does SMS run on the operating system, but it also uses the operating system’s file sharing to
communicate between SMS sites, SMS component servers, and SMS clients. Understanding
operating system security is fundamental to understanding SMS security. You must become
familiar with the basics of the security of the operating system, including the concepts related to
accounts, groups, and domains. This section identifies specific aspects of the operating system
that affect SMS security. For a detailed explanation of the fundamentals of operating system
security, see any books about the operating systems you use that include a security discussion.

Important
Microsoft Windows® 98 is not considered to be a secure operating system. It
does not have many of the Microsoft Windows NT® 4.0, Microsoft
Windows 2000, Microsoft Windows XP, or Windows Server™ 2003 family
security features, such as the ability to run programs in different security
contexts, the NTFS file system, a local security database, security auditing,
or the ability to authenticate accounts other than during log on. All activity on
computers running Windows 98 is done in the context of the logged–on
user. For these reasons, the client side of the SMS security model does not
apply to computers running Windows 98.
136 Chapter 5 Understanding SMS Security

Account Security
SMS can use many accounts to run its various components, which allows it to have very specific
security for each component, thus minimizing the overall risk of a breach of SMS security. In
order to understand SMS design and how to use SMS accounts properly, you must understand
how your operating system uses accounts.

Accounts and Processes


Computer programs run in processes and each process has a security context assigned to it by the
operating system. The security context includes details about the privileges that are available for
that process to use.
Privileges are given to accounts, and they allow processes that are created for those accounts to
perform specific functions on a computer. Typical rights include the ability to shut down a
computer or to run programs as services. The ability to use these rights, as granted to the account,
is stored in the token when the process (and token) is successfully created.
A common example of a process being created with a new security context is a user logging on to
a computer. The user provides a user name, password, and domain (or computer name), which
are known collectively as credentials. The credentials are authenticated against a database of
accounts. If a match is found, then the user is logged on, and a process is created for the user.
Another example of a process being created with a new security context is when a program is run
as a service. Services are started by the operating system (sometimes at the direction of a
privileged user). Services can be run in the security context of the operating system, but the local
system security context cannot use the network to use resources on other computers. To use
resources on other computers, the computer account or an account with a user name and
password is used, and those are authenticated using the same authentication process as when a
user logs on.
The Legacy Client relies heavily on domain accounts to carry out key tasks on the SMS client
computer such as installing software in an administrative context when the logged on user
account does not have the appropriate security credentials. The Advanced Client, on the other
hand, is engineered to use the local system security context and the computer account to carry out
these same key tasks, making the Advanced Client much more secure. It is strongly
recommended that you install the Advanced Client as the preferred client on all your SMS client
computers, especially those computers running the Windows 2000 or later operating system.

Permissions and Access Control


You set permissions of objects, such as files and folders, at the object level. The operating system
security subsystem evaluates which level of permission to assign to a process when the process
accesses the object. The operating system compares the user name and domain (or computer
name), or the groups the user is in, (as stored in the process token) with the object’s access
control list (ACL). If a match is found, then the operating system determines whether the kind of
access that has been requested is permitted.
SMS Security Environment 137

Access control lists contain access control entries (ACEs). Each ACE specifies a user or group
that can access the object, and the kind of access the user or group is permitted. Operating
systems use a wide variety of objects. SMS objects such as collections, packages, and
advertisements are secured by using ACLs that you set through the SMS Administrator console.

Account Authentication
Operating system account authentication is performed for process and thread creation and when
connecting to other computers. Authentication problems most often occur when a computer
connects to other computers. It is important that you understand how accounts authenticate in a
Windows environment.
When a user runs a process that attempts to connect to a share on another computer that is
running in the Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family,
the computer serving the share must be confident that the user is who they claim to be. With that
confidence, the computer can then ensure that the user is allowed the requested access level, and
it can provide the requested data.
Similarly, SMS clients and servers propagate data through the SMS site and SMS hierarchy by
connecting to SMS shares on SMS servers. For example, SMS Legacy Clients use the logged on
user account or a connection account that you specify to connect to client access points (CAPs).
SMS Advanced Clients use the computer account or a network access account that you specify to
connect to a distribution point or other server share. SMS parent and child site servers, that are
using standard security, use site connection accounts that you define to send information to each
other. In addition, SMS parent and child site servers running advanced security can use each
other’s computer account to send information to each other.
For more information about Windows authentication methods, see the Windows operating
system documentation.

SQL Server Security


SMS uses SQL Server security to provide access to the SMS site database. SQL Server provides
two authentication methods. Windows Authentication is available for all SQL Server network
libraries, and it authenticates access based on the Windows account. SQL Server authentication
uses SQL Server-specific accounts that are maintained within SQL Server. The SQL Server
account must be specified when making the connection to SQL Server. SQL Server
Authentication is present for backward compatibility and for clients running Windows 95 and
Windows 98. Its use is discouraged for servers in an enterprise environment.
Mixed security is not an explicit option for SQL Server. Windows Authentication is always
available. SQL Server Authentication can be enabled and disabled. The effect of mixed security
is achieved by enabling SQL Server Authentication.
SQL Server provides roles, which resemble Windows group accounts that have members.
Permissions are assigned to roles using GRANT, REVOKE, and DENY statements. DENY
explicitly denies permission on an object and takes precedence over all other permissions.
For more information about SQL Server security, see to the SQL Server documentation.
138 Chapter 5 Understanding SMS Security

Windows Management Security


SMS uses Windows Management Instrumentation (WMI) as a standardized management
interface. SMS uses WMI on clients for hardware inventory collection, on servers as an interface
to the SMS site database, and on consoles as an interface to the SMS site database. WMI is also
used for storing some configuration data, such as that used by Network Trace.
WMI supports full security for the Windows NT 4.0, Windows 2000, Windows XP, and
Windows Server 2003 families. WMI supports limited security for Windows 98. WMI security
authenticates a user’s logon information both for the local computer and for remote access. With
the versions of WMI included with SMS and Windows 2000, Windows XP, and operating
systems in the Windows Server 2003 family, you can use WMI to control global permissions on
WMI namespace operations, such as limiting the access of some users to read-only operations.
Each WMI namespace has its own security descriptor, which allows the namespace to have its
own security settings. As with files on the NTFS disk partitions, inheritance might be used to
simplify the administration of security. Each ACE in the namespace security descriptor has a
flags field, which indicates what inheritance, if any, is to be performed. For example, if container
inheritance is allowed, then the ACE of the namespace security descriptor is inherited by child
namespaces.
The security descriptor is constructed when a connection to the namespace is first made. The
security descriptor is constructed from the ACLs of the namespaces in the inheritance chain, as
modified by the inheritance bits of each namespace. By default, the local administrator account
and the local administrators group have rights to all operations, including remote access. The
SMS security descriptor is created in WMI during the installation of the SMS site server.
The security descriptor is also used to control access to WMI services. The security descriptor is
a standard Windows security descriptor, and it contains an ACL. Each ACE grants permission to
run a restricted operation, such as allowing logons, remote access, method execution, and writing
to the CIM Repository (the WMI database). The WMI security descriptors are stored in the CIM
Repository.
In the Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003 family
operating systems, there is no distinction between local and remote access. However, with a
remote connection, users can specify a user name and password, replacing the current user name
and password. With a local connection, users cannot override the current name and password.
In Windows 98, local users are considered administrators and are granted full rights. There is no
authentication. Remote users, however, are validated using instances of WMI system classes.
You can use the WMI Control, available in the System Control Panel icon, to manage WMI
security.

Internet Information Services Security


SMS 2003 relies on Internet Information Services (IIS) to support the management point, server
locator point, and reporting point site systems. Well maintained IIS security helps to ensure the
integrity of these SMS site systems.
SMS Security Environment 139

IIS security is especially important if IIS is installed on SMS site servers when the site is running
in SMS advanced security because:
u The site server’s computer account has administrative privileges on other computers. IIS
runs by using the local system account, which is the only account with the right to use the
computer account. This typically is the case only on site servers.
u When using advanced security, the SMS site server manages its local files and registry
entries by using the local system account. Software running in the local system account
context of IIS has equal access to those files and registry entries.
You can implement three IIS application protection modes: low, medium, and high. High
application protection mode is the most secure and isolates the application files from the IIS files
at the process level. SMS 2003 uses IIS 5.0 high application protection mode.
In IIS 6.0 you can implement application pools, which are similar to high application protection
mode. Application pools are more efficient and enable the use of new IIS 6.0 features, such as
automatic application restarts called the worker process Isolation Mode. To determine which
mode IIS 6.0 is in, right-click the Web Sites node in the IIS administrative tool and select
Properties. The Isolation Mode is indicated on the Service tab.
Recommendations for securing IIS include:
u Use the latest version of IIS that is available. Usually this means using the latest operating
system available.
u Apply service packs and security-related hotfixes as they become available.
u Disable IIS functions that you do not require.
u Put IIS on servers that are separate from other applications, or on servers with few other
functions.
u Use IIS security lockdown and other IIS security tools, as described in the IIS
documentation.

Network Security
You should understand network security concepts so that traffic between SMS sites, SMS site
systems, and SMS clients is kept secure. SMS can use encryption, hashing, and signing
algorithms when sending data across a network connection.
Encryption, Hashing, and Signing
Encrypting data is required to either ensure that data cannot be read or modified by unauthorized
people or programs, or to ensure that it came from a known source. Encrypting data is
particularly important when the data is not always contained within a secure environment, for
example if the data is transferred over a shared network.
A common method for encrypting data involves the use of pairs of public and private keys. The
keys are large, randomly generated, numbers or strings of characters. The private key is securely
kept at the computer where the keys are generated. The public key can be available to any other
computer that can use it.
140 Chapter 5 Understanding SMS Security

The data is encrypted by using either the private key of the originating computer or the public
key of the receiving computer and then sent out. The receiving computer decrypts the data using
the corresponding public or private key, which is the only key that can decrypt data encrypted by
the other key.
Encrypting data by using algorithms based on public and private keys is very slow, especially for
large amounts of data. To avoid this issue, a small amount of predefined data, known as a
signature, can be encrypted and sent with the rest of the data. The receiving computer can decrypt
the signature to ensure it is valid. If it is valid, the rest of the data is valid, even though it is not
encrypted.
If it is important to ensure that the data accompanying the signature has not been changed, a hash
value can be calculated for the data when it is sent and included with the signature. The hash
value is then recalculated when the data is received and the two hash values are compared. If the
hash values are the same, the data has not been modified. Hash values can be calculated in a wide
variety of ways, but generally they are based on the size of the file and regular samplings of the
contents.
SMS 2003 signs all data sent between sites using private/public encryption key pairs. SMS does
not encrypt or hash site-to-site communications, except for the following exceptions:
u Packages have hash values, which SMS signs.
u SMS encrypts SMS account names and passwords.
The sending site signs the data it sends using its private key and places the signature in the
instruction file for the data being sent. The receiving site then verifies the signature by using the
sending site’s public key. If the signature cannot be verified, the data is rejected. SMS 2.0 sites
that have not been upgraded to SP5 do not sign their data, so those SMS 2.0 sites cannot
communicate securely with SMS 2003 sites. If you must support SMS 2.0 sites that are running
SP4 or earlier in your SMS hierarchy, and you do not want to accept any unsigned data sent from
that site to the parent site, then you set that option through the SMS Administrator console.
Navigate to the Advanced tab in the Site Property dialog box for the SMS 2003 site that is the
parent of the SMS 2.0 SP4 site, and enable the option. Do not accept unsigned data from sites
that are running SMS 2.0 SP4 and earlier. This ensures that the parent site only accepts signed
data, but it can result in the loss of some data sent from the SMS 2.0 SP4 or earlier child site.
The keys are generated at each site when the sites are set up. The value of the private key is only
known by the operating system of the site server. The keys change when the SMS Service
Account is changed for the site. The site automatically transfers the new public key to its parent
site and all its direct child sites.
SMS Security Environment 141

Sites can exchange keys most securely by:


u Receiving the intersite key exchange files during the establishment of a parent/child site
relationship and then verifying their validity by reading the public keys from Active
Directory. The serviceBindingInformation attribute of mSSMSSite objects are used to
store the public key for each site. The ability to write public keys to Active Directory
requires significant rights, so this ensures that the site is not a rogue site. This method of key
exchange happens automatically, but it requires Active Directory and that the account being
used to set up the sites has sufficient rights to write to the Active Directory objects. This
method also does not work across forests.
u Manually transferring the keys by running the SMS Preinst.exe tool with the appropriate
switches and then transferring the generated files using your rights. Table 5.1 lists the
relevant Preinst.exe switches. Preinst.exe is in the \SMS\bin\i386\<language code> directory
on your SMS 2003 or SMS 2.0 SP5 site server.
u Enabling the Require secure key exchange between sites option on the Advanced tab in
the Site Property dialog box to ensure that only trusted keys are exchanged between sites.
Table 5.1 Preinst.exe Switches for Exchanging Site Keys
Key Purpose How to use
/KEYFORPARENT Dump this site’s public key into the file Copy this file to the parent site’s
<sitecode>.ct4 at the root of the SMS hman.box inbox (Not
drive. hman.box\pubkey)
/KEYFORCHILD Dump this site’s public key into the file Copy this file to the child sites’
<sitecode>.ct5. hman.box inbox.
/CHILDKEYS Dump this and all child sites’ public Copy this file to the parent sites’
keys into the file <sitecode>.ct6. hman.box inbox.
/PARENTKEYS Dump this and all parent sites’ public Copy this file to the children sites’
keys into the file <sitecode>.ct7. hman.box inbox.

SMB Signing
Server message block (SMB) is a network protocol that is commonly used by Windows systems
and by SMS to transfer files between computers. Without SMB signing, a device could intercept
SMB network packets from an originating computer, alter their contents, and broadcast them to
the destination computer. Where this is a concern, SMB signing should be enabled or required.
SMB signing is available for computers that are running Windows NT 4.0 SP3 or later.
In order to use SMB signing, you must either enable it or require it on both the client and the
server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use
the signed SMB protocol during all subsequent sessions and clients that are not enabled for SMB
signing use the original SMB protocol. If SMB signing is required on a server, then a client
cannot establish a session unless it is enabled for SMB signing. SMB signing is disabled by
default on servers and clients running Windows operating systems.
142 Chapter 5 Understanding SMS Security

The registry values for enabling or requiring SMB signing are:


u On the server:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

Value Name: EnableSecuritySignature


Data Type: REG_DWORD
Data: 0 (disabled, the default), 1 (enabled)

Name: RequireSecuritySignature
Type: REG_DWORD
Value: 0 (disabled, the default), 1 (enabled)
u On the client:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters

Value Name: EnableSecuritySignature


Data Type: REG_DWORD
Data: 0 (disabled, the default), 1 (enabled)

Name: RequireSecuritySignature
Type: REG_DWORD
Value: 0 (disabled, the default), 1 (enabled)

Important
Using SMB signing slows down performance. Use this setting only when
network security is a concern. The decrease in network throughput
performance usually averages between 10 to 15%. SMB signing requires
that every packet is signed and every packet must be verified.

Management Point Communications


Management points and proxy management points communicate with the SMS site database for
policy and assignment data. It might be possible for such communications to be compromised.
Therefore it is recommended that you implement one or more of the following solutions to secure
communications between management points and the SMS site database:
u Install the management point, the SMS site database, and the SMS site server on same
physical computer.
u Isolate the management point, the SMS site database, and the SMS site server on a private
network and secure the private network.
u Run Internet Protocol Security (IPSEC), or SMB signing for communications between the
management point, the SMS site database, and the SMS site server.
It is recommended that you use IPSEC to secure communications between proxy management
points and the SMS site database.
SMS Security Modes 143

Physical Security
Software security is critically important to SMS security, but without appropriate, basic, physical
security, SMS can still be vulnerable. SMS security is designed on the premise that client
computers might not be physically secure, and therefore SMS clients have no functionality that
can be used to compromise SMS security.

Important
This discussion presumes that users use client computers without elevated
privileges on other computers. Privileged users with sufficient knowledge
can easily turn any client computer into a console, If their privileges allow
them to attach to a site server, then they have full access to the SMS
system.

An SMS Administrator console, when connected to an SMS site server, can be used
inappropriately to the detriment of SMS itself or to the computers it manages. Therefore, SMS
Administrator consoles must always be physically secured while the user is logged on. Ideally,
keep computers that run the SMS Administrator consoles in a locked room to protect them from
unauthorized access. However, if this is not possible, secure these computers when
administrators are not physically present by having the operating system lock the workstation, or
by using a secured screen saver.
An SMS site server is also at risk if it is not physically secured while an administrator is logged
on to it and while it is not guarded. Not only do site servers typically have an SMS Administrator
console, but they also have the setup program that runs a site reset.
Like any server, site servers and site systems that are not physically secured can be compromised
using a variety of techniques. After they are compromised, the SMS data and system could be
misused. Therefore it is very important that all SMS site servers and site systems must be
physically secured.

SMS Security Modes


SMS runs in one of two security modes — standard security mode or advanced security mode.
The security mode that you enable affects the type and number of accounts used for SMS
security. Before you can enable advanced security certain prerequisites must be met on the SMS
site server. Each security mode has its advantages, so you must choose the mode that is
appropriate for your SMS sites.
144 Chapter 5 Understanding SMS Security

SMS Advanced Security


SMS 2003 advanced security uses the local system account on SMS servers to run SMS services
and make changes on the server. Advanced security uses computer accounts (rather than user
accounts) to connect to other computers and to make changes on other computers. Computer
accounts can be used only by services running in the local system account context, and only
administrators can configure services. Therefore, advanced security is a very secure mode.
The local system account and computer accounts have several advantages over user accounts:
u The local system account is local to the computer itself so the jurisdiction of the account is
very limited.
u Only the operating system knows the password for a computer account so network users
cannot use computer accounts to access network resources.
u The local system account does not have a password or require one. Local system and
computer accounts do not require any manual maintenance, even in organizations that
require that all passwords be changed on a regular basis because the computer regularly and
automatically changes computer account passwords.
u Domain-level privileges are not required. Privileges are required only on the SMS servers
themselves.
Requirements for Advanced Security
For an SMS 2003 site to use advanced security, the SMS site server and all SMS site systems
must be running Windows 2000 SP1 or later, or an operating system in the Windows Server 2003
family, in an Active Directory domain. It is not possible to use an advanced security site in a
Windows NT 4.0 domain. The SMS site database servers must be running SQL Server 2000 or
later, with any service packs required, as indicated in the “Getting Started” chapter in this book.
The SQL Servers must be in Windows authentication mode only.
The following SMS hierarchy configurations are supported for advanced security:
u SMS 2003 advanced security site reporting to an SMS 2003 advanced security central site
u SMS 2003 standard security site reporting to an SMS 2003 advanced security site
u SMS 2.0 site reporting to an SMS 2003 advanced security site

Note
If you have upgraded from SQL Server 7.0 to SQL Server 2000 or later, you
must restart the computer before changing the SMS security mode to
advanced security. This allows SQL Server to report to SMS that it is now
running a supported version.
SMS Security Modes 145

Migrating to Advanced Security


SMS sites can be set up to use advanced security during installation. For information about
setting up sites with advanced security, see Chapter 15, “Deploying and Configuring SMS Sites.”
Similarly, SMS sites can be set up to use standard security during installation, and then changed
to advanced security, if they meet the requirements for advanced security.
Before an advanced security site server can connect to other SMS sites or SMS site systems, the
relevant computer accounts must be given rights on the appropriate computers. For a new
primary site, this must be done before setting the parent site for the site and before setting up site
systems on computers other than the site server. For a new secondary site, the computer account
or Site Address Account must be given permission to connect to the other site prior to setting up
the secondary site. For an existing site with a parent site or site systems on computers other than
the site server, the computer accounts must be given rights on appropriate computers before
changing the site to advanced security.
You can add computer accounts to a domain group or local group of another computer by typing
the following command:
Net localgroup <group> <domain name or local computer name>\<remote computer
name>$ /ADD
Computer accounts are always extended with a $ sign, which hides the accounts in the account
administration tools.
For information about how to add computer accounts to groups by using the Active Directory
Users and Computers administrative tool, see your Windows documentation.
When you upgrade a standard security site to advanced security, SMS automatically adds the
computer accounts for the CAP and management point site systems to the Site System to Site
Server Connection group, which gives the CAPs and management points access to the site server.
Similarly, the site server’s computer account is automatically added to the Site to Site
Connection group on the parent and child sites.
When installing a new site with advanced security, SMS does not create accounts such as the
SMS Client Connection Account. Legacy Clients use the SMS Client Connection Account to
connect to a CAP and send information, such as discovery data records (DDRs), inventory, and
status messages. If you plan to use Legacy Clients in your advanced security SMS site, you must
create at least one SMS Client Connection Account before installing the Legacy Clients.
To change the security mode
1. Navigate to the site’s node in the SMS Administrator console.
Systems Management Server
X Site Database (site code - site name)
X Site Hierarchy
X (site code - site name)
2. Right-click the site, and then select Properties.
146 Chapter 5 Understanding SMS Security

3. Click Set Security on the General tab of the Site Properties dialog box.
4. Click Yes on the warning message if you are certain the site is prepared to change to
advanced security.
While the change to advanced security is taking effect, SMS components might fail and the error
logs might contain error messages. You should give SMS some time to make the change to
advanced security effective. The components automatically recover.

Important
If a site is erroneously moved to advanced security, it can only be put back
to standard security by using the recovery procedures. For information about
the recovery procedures, see Chapter 15, “Backup and Recovery,” in the
Microsoft Systems Management Server 2003 Operations Guide.

To verify which sites are using advanced security, you can check the properties of each site node
in the SMS Administrator console. Alternatively, you can query or report on the
SMS_SCI_SiteDefinition class. Check each array member of the Props property for a
PropertyName=“Security Mode”. The security mode is the Value1 value. To query the Site
Control Information (SCI) classes, you must specify each site code in the query. Also, the Props
property must be inspected to find the appropriate array element. And SCI classes do not have
equivalent reporting views. Therefore this kind of report must be done using scripts or Active
Server Pages that retrieve WMI data. For more information about writing scripts to report site
configuration details, see Appendix C, “Scripting SMS Operations,” in the Microsoft Systems
Management Server 2003 Operations Guide.

Note
Migrating a site to advanced security does not cause the standard security
accounts to be deleted automatically because clients or other sites might
need them. You can remove the accounts when you are certain they are not
being used anymore.

Adding Site Systems to Advanced Security Sites


Before adding a site system to an advanced security site you must grant the site server computer
account administrative rights on the SMS site system. This can be done with the command:
Net Localgroup Administrators <domain name>\<site server computer name>$ /ADD
SMS automatically adds the computer account of the site system to the Site System to Site Server
Connection group on the site server, allowing the site system to communicate with the site
server.

SMS Standard Security


SMS 2003 standard security is very similar to SMS 2.0 security. Standard security relies on user
(not computer) accounts to run services, to make changes to computers, and to connect between
computers.
SMS Accounts and Groups 147

Advanced security is the recommended security mode. However, you must use standard security
if your site does not meet the requirements for installing advanced security. In addition, use
standard security if you are upgrading directly from an existing SMS 2.0 site. Upgrading from
SMS 2.0 is relatively straightforward because standard security is nearly the same as SMS 2.0
security.
For more information about upgrade and migration strategies, see Chapter 1, “Scenarios and
Procedures for Deploying SMS 2003” in the Microsoft Systems Management Server 2003
Operations Guide.

SMS Accounts and Groups


To strengthen security, SMS can use multiple accounts for different site and client functions.
You can use these accounts to avoid granting domain administrative access across the network.
By granting privileges on a more granular basis, you minimize the risk to all SMS processes if a
single account’s security is breached.
Standard security mode supports and requires a large number of accounts you can use to manage
SMS tasks. Advanced security, by contrast, supports and requires very few accounts. The more
accounts you create in SMS, the harder it becomes to manage those accounts, and the more
complex it becomes to manage SMS security as a whole. To effectively plan and manage SMS
security, it is essential to understand the role of each SMS account.
This section groups the accounts and groups in four categories:
u Those that are used in both advanced security and standard security
u Those that are used with advanced security
u Those that are used with standard security
u Those that are used by Advanced Clients and Legacy Clients

Note
SMS accounts in Windows NT 4.0 domains can have passwords up to 14
characters long. SMS accounts in Windows 2000 or Windows Server 2003
domains can have passwords up to 36 characters long. You should consider
using complex passwords that are as long as possible and include a
combination of letters, numbers, and special characters when setting
passwords for SMS accounts. However, the SMS Administrator console only
allows 36 character passwords (except for the SQL Server passwords, which
can be 30 characters). To set passwords longer than 14 characters on the
SMS accounts, use the SMS account command-line tools.
148 Chapter 5 Understanding SMS Security

The accounts described in this chapter are associated with specific account roles. The SMS
names for these accounts are often only suggestions, and you can use other account names.
Frequently, you can use a single account for multiple roles. For example, you can use the SMS
Service Account for site-to-site communications, site server-to-site system communications, and
remote client installation. Using the SMS Service Account in all these roles is acceptable under
some circumstances, such as small deployments where ease of administration is more important
than tight security.

Complete List of SMS Accounts


Table 5.2 lists all the SMS operating system accounts, groups, database accounts, and access lists
that are used by SMS 2003 at the server level. They are explained in detail in the following
sections. Accounts that are used by both advanced security and standard security modes are
referred to by the term common.
Table 5.2 Complete List of SMS Server-Level Accounts
Account category Account name User or group name
Common server and client Local system N/A
Client Push Installation Administrator’s choice
Site Address Administrator’s choice
Common server
Logged on user (logged on the Varies greatly
SMS Administrator console)
SMS Administrators SMS Admins
Internal client group SMSInternalCliGrp
Reporting Users SMS Reporting Users

Common group Site System to Site Server SMS_SiteSystemToSiteServerCon


Connection nection_sc
Site System to SQL Server SMS_SiteSystemToSQLConnectio
Connection n_sc
Site to Site Connection SMS_SiteToSiteConnection_sc
sa if SQL Server account (might
Site Database vary)
sa if SQL Server account (might
Server Locator Point Database vary)
Common database
sa if SQL Server account (might
Management Point Database vary)
Web Report Application Role webreport_approle
SMS Schema Users smsschm_users

(continued)
SMS Accounts and Groups 149

Table 5.2 Complete List of SMS Server-Level Accounts (continued)


Account category Account name User or group name
Package Access Accounts N/A
Common access list
Remote Tools Permitted Viewers N/A
Advanced security Computer computername$
SMS Service Administrator’s choice
Server Connection SMSServer_sc (can vary)
Standard security
Site System Connection Administrator’s choice
Remote Service SMSSvc_sc_xxxx
Client Configuration Manager
(CCM) Boot Loader (Non-DC) SMSCCMBootAcct&
Common client CCM Boot Loader (DC) SMS#_dc
logged on user (logged on to
clients) Varies greatly
Advanced Client Network
Advanced Client
Access Administrator’s choice
Client Services (DC) SMS&_dc
Client Services (Non-DC) SMSCliSvcAcct&
Client User Token (DC) SMSCliToknAcct&
Legacy Client Client Connection SMSClient_sc
Legacy Client Software
Installation Administrator’s choice
Client User Token (Non-DC) SMSCliToknLocalAcct&

Table 5.3 lists all the SMS operating system accounts that are used by SMS 2003 at the client
level. They are explained in detail in the following sections. Accounts that are used on both the
Advanced Client and Legacy Client are referred to by the term common.
150 Chapter 5 Understanding SMS Security

Table 5.3 Complete List of SMS Client-Level Accounts


Account category Account name User or group name
Client Configuration Manager
(CCM) Boot Loader (Non-DC) SMSCCMBootAcct&
Common client CCM Boot Loader (DC) SMS#_dc
logged on user (logged on to
clients) Varies greatly
Advanced Client Network
Advanced Client
Access Administrator’s choice
Client Services (DC) SMS&_dc
Client Services (Non-DC) SMSCliSvcAcct&
Client User Token (DC) SMSCliToknAcct&
Legacy Client Client Connection SMSClient_sc
Legacy Client Software
Installation Administrator’s choice
Client User Token (Non-DC) SMSCliToknLocalAcct&

Common Server Accounts


Some accounts and groups, and all the access account lists, are common to both standard security
and advanced security. Table 5.4 provides an overview of each common account, the account’s
function, whether SMS creates the account automatically, and whether SMS requires the account.
Table 5.4 SMS Common Accounts Overview
Account Created
Account type Function automatically? Required?
Local system Service Runs SMS Yes Yes
client and
server services
Client Push Client Can be used by No No, but recommended for greater
Installation installation Client security.
Configuration If not specified and if the site is using
Manager to standard security, the SMS Service
install SMS Account is used.
client software
on computers.

(continued)
SMS Accounts and Groups 151

Table 5.4 SMS Common Accounts Overview (continued)


Account Created
Account type Function automatically? Required?
Site Address Server Site to site No Yes, for parent/child site
connection connections relationships, but the site server
computer account or SMS Service
Account can be used for this purpose.
Logged on User To use the SMS No Yes, but already exists.
user Administrator
console

Client Push Installation Account


You use the Client Push Installation Account to install software on clients running the
Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating
systems when the user who is running the installation method does not have local administrative
rights.
You can create multiple Client Push Installation Accounts. If you have clients that are not
members of domains and therefore cannot authenticate domain accounts, you can use accounts
that are local to the clients themselves. For example, if you set up a standard account on each
computer for administrative purposes, all with the same password, then you can define a Client
Push Installation Account as “%machinename%\account”.

Note
The Client Configuration Manager (CCM) checks for changes to the Client
Push Installation Account once every hour. Changes to this account do not
become effective immediately.

Site Address Account


SMS sites use Site Address Accounts to connect to other SMS sites in an SMS hierarchy. The
Site Address Accounts must be able to connect to the SMS_Site share on the destination site
server and must be able to read, write, and enumerate files on the share and its directory. The
account must be verifiable at the destination site server. It does not have to be verified on the
originating site server where the address is defined. This account does not require any other
privileges on the site.
You add the Site Address Account to the Site to Site Connection group on the destination site
server, which has the appropriate privileges on the SMS_Site share. The Site Address Account
does not have to be given privileges to the SMS_Site share directly.
During installation of a secondary site, SMS automatically adds the computer account of the
parent site to the Site to Site Connection group on the secondary site. If you initiate the
installation of the secondary site from the parent site, SMS also adds the computer account of the
secondary site to the Site to Site Connection group on the parent site. Automatically adding the
accounts to the groups simplifies the migration of the site to advanced security.
152 Chapter 5 Understanding SMS Security

Common Server Groups


The SMS groups can be domain groups or local groups. Local groups are preferred because they
do not have to be replicated to all domain controllers, and the scope of their privileges is limited
to the computer. However, domain groups can be used on all sites for those groups that do not
include the site code in the group name. Table 5.5 provides an overview of each common group,
the account’s location, and its function.
Table 5.5 SMS Common Groups Overview
Group Location Function
SMS The site server Provides its members with access to the SMS Provider, through WMI.
Administrators and the server Access to the SMS Provider is required for viewing and modifying SMS
with the SMS security objects and data in the SMS Administrator console or using
Provider, if similar tools. By default, members of the SMS Administrators group on
different the local computer and members of the local Administrators group
have WMI access.
Internal Client Domain Created on domain controllers to contain the Client User Token
Group controllers that Account and the Client Services DC Account. Windows security
are SMS clients requires that domain accounts must be made members of a group.
The Internal Client Group enables the Client User Token Account and
the Client Services DC Account to run, but it does not grant to these
accounts, rights that they do not require.
Reporting Users Reporting point Controls access to the SMS Reports Web site.
Site System to Site server Provides its members with access to the site server resources that are
Site Server necessary for the operation of the site systems (such as CAPs,
Connection management points, and server locator points). Site system computer
accounts other than distribution point computer accounts should be
added to this group.
Site System to Database Management points, server locator points, and reporting points are
SQL Server servers given access to the computers running SQL Server using this group.
Connection The database accounts should be members of this group.
Site to Site Site servers Site to site communications are enabled using Site Address Accounts.
Connection Those accounts should be put in this group.

The SMS Administrators group is local to the SMS site database server and the site server for
each primary site. If these roles are on two servers, then there are two SMS Administrators
groups for the site and users must be added to both. If these roles are on the same server, or both
are on domain controllers, there is only one SMS Administrators group for the site.
SMS Accounts and Groups 153

SMS automatically adds the management point and server locator point database accounts to the
Site System to SQL Server Connection group when you enable the management point and server
locator point site systems at a site. Having the database accounts in the group simplifies
migrating to advanced security.

Important
It is recommended that the SMS Administrators group be used to grant
access to the SMS WMI namespaces rather than granting access to
individual accounts or other groups to reduce the number of entries for the
namespaces, and to grant the appropriate rights to all relevant namespaces.

SMS Database Accounts and Roles


SMS sites use SMS Database Accounts to connect to, send and receive data with, and manipulate
the databases. SMS Database Accounts are SQL Server accounts if you implement SQL Server
authentication, or they are Windows accounts if you implement Windows authentication. SMS
sites can use SMS Database Accounts to connect to the SMS site database, management point
database, or server locator point database.
If you implement Windows authentication, you do not have to specify a Site Database Account
for the SMS site’s access to the SMS site database — SMS uses the site server computer account
(advanced security) or the SMS Service Account (standard security). If the site uses advanced
security and SQL Server uses Windows authentication, you can set the server locator point or
management point to use their computer accounts as the SMS Database Account to access the
SMS site database by adding the SMS server computer account to the local Administrators group
on the SMS site database computer. This action gives the SMS server computer account all the
necessary access rights to the SMS site database because the Administrators local group is
mapped to the dbo user (the database owner) SQL account for the SMS site database.
If the SMS site database is on a server other than the SMS site server, and you modify or remove
the SMS site database access rights for the Administrators local group on the SMS site database
computer, then you need to map the SMS site server computer account to the dbo user SQL
account for the SMS site database. Follow these steps to do so:
Mapping the SMS site server computer account to the dbo user for the SMS site database
1. Start the SQL Query Analyzer with the SMS site database selected.
2. Run the following queries to add the login for the machine account:
exec sp_grantlogin '<machine account>'
exec sp_changedbowner '<machine account>'
exec sp_grantlogin 'NT AUTHORITY\SYSTEM'
exec sp_addrolemember 'db_owner', 'NT AUTHORITY\SYSTEM'
exec sp_droplogin 'BUILTIN\Administrators'
154 Chapter 5 Understanding SMS Security

Access Account Lists


Access account lists define the user accounts and group accounts that have access to specific
SMS objects. When you add or delete an entry from the list, you are not adding or deleting the
user account or group account itself. The entries correspond to accounts that already exist in the
domain, so by adding or deleting an entry, you are specifying whether an existing user account or
group account has access to SMS. Table 5.6 provides a brief description of the SMS access
account lists used by SMS. For more information about each account list, see the “SMS Feature
Security” section later in this chapter.
Table 5.6 SMS Common Access Account Overview
Are any user or user
SMS Access Account group accounts listed Are any accounts in
List name Description by default? the list required?
Package Access User accounts and group Yes: Administrators Yes: Administrators
Accounts accounts with access to and Users
package source files on
distribution points.
Remote Tools User accounts and group No No
Permitted Viewers accounts that can remotely
access clients (note that you
must also create a security
right to use Remote Tools on
specific collections and then
assign that right to a user
account or a group account).

Advanced Security Server Accounts and Groups


One of the advantages of advanced security is that it does not require user accounts other than the
local system and computer accounts. All SMS site server services and processes are run using the
local system account of the SMS site server. Advanced Security also uses the same server–level
groups that standard security uses to give the accounts access to the shares that they should be
able to access.
SMS servers must connect with resources (shares or WMI connections) on other computers in
order to transfer data within a site or between sites, or to manage clients. Figure 5.1 illustrates the
connections, and also includes the use of the service accounts. The numbers on the arrows and
services correspond to the numbers in the list of accounts.
SMS Accounts and Groups 155

Figure 5.1 SMS advanced security server connectivity


Another
SMS site

Site
server

An
SMS site

Site
server

Reporting
Point

Distribution
point

CAP Management
point
Server
Site database
locator
SQL Server
point

Accounts:
1 Site server computer account
2 Site system computer account
3 Site Address
4 Site Database

n = Optional accounts
156 Chapter 5 Understanding SMS Security

Standard Security Server Accounts and Groups


Table 5.7 provides an overview of each server-level account associated with standard security,
the account’s function, whether SMS creates the account automatically, and whether SMS
requires the account. For information about how to maximize security in your site, best practices
for managing accounts (including password changes), and procedures for creating and modifying
SMS accounts, see Chapter 12, “Planning Your SMS Security Strategy.”
Table 5.7 SMS Standard Security Accounts Overview
Account Created
Account type Function automatically? Required?
SMS Service Site server The site server services run Yes Yes
(SMSService) under this account.
The default account used
by site server services to
manage site systems
running Windows NT 4.0
(that is, create shares and
directories on the site
systems, set directory
permissions, copy files,
install services, and verify
that the services are
running).
SMS Server Server Provides SMS services Yes Yes
Connection connection running on remote site
(SMSServer_sitecode) systems (such as CAPs)
access to the site server.
Also used by the SMS
Provider to gain access to
SMS directories on the
site server, including the
PDF store.
Site System Site system Used by site server No No, but
Connection connection services for managing site recommended
systems. for greater
security.
If not specified,
the SMS
Service Account
is used.

(continued)
SMS Accounts and Groups 157

Table 5.7 SMS Standard Security Accounts Overview (continued)


Account Created
Account type Function automatically? Required?
SMS Remote Service Remote Used to run the SMS Yes, when you Yes, for CAPs
(SMSSvc_sitecode site system Executive service on CAPs assign the CAP not on the site
_xxxx) service other than the site server. role to a server or
Also used to run the SQL separate site instances of
Monitor when the SMS system or the SMS site
site database SQL Server SMS site database
is not on the site server. database SQL Server not
SQL Server to a on the site
computer other server.
than the site
server.

SMS Service Account


The SMS Service Account is used:
u To provide the security context the SMS Executive service runs in.
u To create operating system objects (such as directories, files, and services) on the site server
and the other servers it is used on.
u To access SQL Server, if SQL Server is accessed using Windows Authentication.
u To access domain controllers when enumerating users, groups, containers, or systems
(computer accounts) for the relevant discovery methods.
If you do not create optional accounts, the SMS site server uses the SMS Service Account as the
Site System Connection Account. In addition, you can use the SMS Service Account as your Site
Address Accounts. However, it is best to avoid using the SMS Service Account for these roles, in
order to minimize security risks and to ease administration, as described elsewhere in this
chapter.
The SMS Service Account must have the Log on as a service right on the SMS site server. This
right can be provided by a group policy of the organizational unit that the site server is in. If the
site server is moved to another organizational unit, a policy in that organizational unit must be set
to give the SMS Service Account the Log on as a service right. This can be accomplished by
running SMS site reset.
When the SMS Service Account is used to enumerate users, groups, containers, or systems in
domains other than the domain the site server is in, the SMS Service Account must have user
rights on those domains (the account must at least be a member of the Domain Users group for
the domains).
The local system account serves the SMS Service Account role on an advanced security site
server. When accessing network resources, the advanced security site server uses the computer
account for this role.
158 Chapter 5 Understanding SMS Security

Server Connection Account


SMS services running on remote SMS site systems (such as the Inbox Manager Assistant running
on a CAP) use the Server Connection Account to connect to the site server. The Server
Connection Account is a local account on the SMS site server.
The SMS site systems computer account serves this role in advanced security.
Site System Connection Account
Services that run on the SMS site server can use a Site System Connection Account to connect to
SMS site systems. This account is optional.
The SMS site server first uses the Site System Connection Account to connect to a site system if
one exists. If the Site System Connection Account is unable to connect to the SMS site system, or
does not exist, the SMS site server then tries the SMS Service Account.
The SMS site server computer account serves this role in advanced security.
Remote Service Account
SMS site system services (other than those running on the SMS site server) run under remote site
system service accounts. SMS creates this account automatically when you implement the site
system. The following SMS site systems use a remote site system service account:
u Client access point
u SQL Server if the SQL Monitor is running on it (with the SMS Provider)
The local system account on each computer serves this role in advanced security.
SMS servers must connect to resources (shares or WMI connections) on other computers in order
to transfer data within a site or between sites, or to manage clients. Figure 5.2 illustrates the
connections, and also includes the use of the service accounts. The numbers on the arrows and
services correspond to the numbers in the list of accounts.
SMS Accounts and Groups 159

Figure 5.2 SMS standard security server connectivity


Another
SMS site

Site
server

An
SMS site

Site
server

Reporting
Point

Distribution
point

CAP Management
point
Server Site database
locator SQL Server
point

Accounts:
1 SMS Service
2 Site Address
3 Site Database
4 Server Connection (SMSServer_sc)
5 Site System Connection
6 Logged on user

n = Optional accounts
Note: sc=site code
160 Chapter 5 Understanding SMS Security

SMS Client Accounts


SMS Client Accounts are accounts used to run services and processes on SMS clients. SMS
Client Accounts are used in both standard security and advanced security sites. However,
Advanced Clients and Legacy Clients use different client accounts. Table 5.8 provides an
overview of each client account, the account’s function, whether SMS creates the account
automatically, and whether SMS requires the account.
Table 5.8 Client Account Overview
Account Created
Account type Function automatically? Required?
CCM Boot Loader Client Provides SMS with access Yes Yes
(Non-DC) service to install CCM Boot Loader
(SMSCCMBootAcct&) on non-domain controllers.
CCM Boot Loader Client Provides SMS with access Yes Yes
(DC) service to install CCM Boot Loader
(SMS#_domain_ on domain controllers.
controller_name)
Logged on user User Might be used during client No Yes
installation and other
steps. Used for all
purposes on computers
using Windows 98.
Advanced Client Client Provides access to file No No
Network Access connections servers for Advanced
Clients on computers
running Windows NT 4.0,
Windows 2000, or
Windows Server 2003
family operating systems
Client Services (DC) Client Used to run the SMS Client Yes Yes
(SMS&_domain_ service Service on domain
controller_name) controllers.
Client Services Client Used to run the SMS Client Yes Yes
(Non-DC) service Service on non-domain
(SMSCliSvcAcct&) controllers.
Client User Token Client Used to create user tokens Yes Yes
(DC) service on client computers that
(SMSCliToknAcct&) are domain controllers.
Client User Token Client Used to create user tokens Yes Yes
(Non-DC) service on client computers that
(SMSCliToknLocalAcc are not domain controllers.
t&)

(continued)
SMS Accounts and Groups 161

Table 5.8 Client Account Overview (continued)


Account Created
Account type Function automatically? Required?
SMS Client Client Provides access to CAPs Yes Yes
Connection connection and distribution points for
(SMSClient_sitecode) Legacy Clients on
computers running
Windows NT 4.0,
Windows 2000, or
Windows Server 2003
family operating systems
Legacy Client Client Provides a security context No No, but
Software Installation connections for certain advertised recommended
and programs running on for greater
advertised computers running security.
program Windows NT, If this account
installation Windows 2000, or is not specified
Windows Server 2003 but a program
family operating systems. is told to run
This account is with it, the
recommended for use when program fails to
network resources that are run. The default
not on the distribution is to not to use
point must be accessed. this account, in
which case the
program runs
using either the
logged on user
account or the
Client User
Token Account.

CCM Boot Loader Accounts


There are two variations of the CCM Boot Loader Account:
u CCM Boot Loader (Non-DC) - used on computers that are not domain controllers
u CCM Boot Loader (DC) - used on computers that are domain controllers
SMS generates the CCM Boot Loader Account and password when client installation begins, and
deletes the account when the client is successfully set up.
Advanced Client Network Access Account
The Advanced Client Network Access Account is a domain-level account that you can create for
Advanced Clients. The Advanced Client uses this account when an advertised program needs to
access a share on a server other than the distribution point. Consequently, this account must have
the appropriate permissions on the share that the advertised program accesses.
162 Chapter 5 Understanding SMS Security

The Advanced Client Network Access Account must always include a domain name. Pass-
through security is not supported for this account. If the account must be used in multiple
domains because users might use resources from multiple domains, the domains should be set to
trust each other so that the account can be used on the resources on all the domains.
You can use the Advanced Client Network Access Account to access the Client.msi and related
files from the SMSClient share on the site server when you are installing the Advanced Client
software using Client Push Installation. If the Advanced Client Network Access Account is not
available, the computer account of the target computer is used instead.
Client Service Accounts
The SMS client service accounts run SMS client services on the SMS client. There are two
variations of the client service account:
u Client Service (Non-DC) — for SMS client computers that are not domain controllers
u Client Service (DC) — for SMS client computers that are domain controllers
SMS manages the client service accounts and passwords and creates them during client
installation. The accounts are local and unique to the client. The exception to this occurs when
the domain controllers are SMS clients. In this case the local security database is the domain
database, and the accounts include the server name in the account name to keep them unique.
Client User Token Account
The Client User Token Account password is reset every time the client restarts. The password
reset process changes the password to a new strong value and restores the default permissions
and rights for the Client User Token Account.
Client Connection Account
Legacy Clients use the Client Connection Account to connect to CAPs. SMS client connection
accounts do not have to have any access rights to the client computer and do not have to be
members of any groups on the client.
Standard security sites automatically create a Client Connection Account as a local account on
the CAP when a CAP is set up. You must create the Client Connection Account for advanced
security sites if you are supporting Legacy Clients in those sites.
You can create Client Connection Accounts as domain accounts and then share them among
many CAPs. This minimizes the number of Client Connection Accounts you must create and
maintain, but increases the security scope of each individual Client Connection Account. The
best practice is to use local accounts whenever possible.
SMS Accounts and Groups 163

Legacy Client Software Installation Account


The Legacy Client Software Installation Account is an optional domain-level account that you
create for Legacy Clients. The Legacy Client uses this account when an advertised program must
access a network share on a server other than the distribution point, and when the SMS
administrator identifies this account in the program properties of the advertised package. The
Legacy Client Software Installation Account requires the appropriate level of permissions to
access the network share.

Note
The Legacy Client Software Installation Account can be used only on SMS
clients that are not running Windows 98. Clients that are running
Windows 98 fail to run advertised programs if those programs are set to use
the Legacy Client Software Installation Account.

Legacy Client Connectivity


SMS Legacy Clients connect to SMS servers for various reasons and use accounts for different
functions. Legacy Client connections to servers are shown in more detail in Figure 5.3, which
indicates the specific client agents and components that use each account.
164 Chapter 5 Understanding SMS Security

Figure 5.3 SMS Legacy Client connectivity

SMS
Site server

CAP

Client

Distribution
point

SMS
Administrator
console

Accounts:
1 Logged on user
2 Client push installation account
3 SMS Client Connection account
4 Permitted viewers list

Advanced Client Connectivity


SMS Advanced Clients connect to SMS servers for various reasons and use accounts for
different functions. Advanced Client connections to servers are shown in more detail in
Figure 5.4, which indicates the specific client agents and components that use each account.
SMS Accounts and Groups 165

Figure 5.4 SMS Advanced Client connectivity

SMS
Site server

Management
Client Point

Distribution point
SMS Adminstrator and Non-SMS servers
console

Active Directory
domain controller

Accounts:
1 Logged on user
2 Computer account
3 Advanced client network Access account
4 Client push installation account
5 Anonymous htm connection
6 Permitted viewers list

n =Optional accounts

Avoiding Problems Due to Account Lockouts


Account lockouts occur when SMS uses passwords that are not valid to connect to network
resources and the domain account policy is set to lock out accounts that make such connections.
SMS retries almost all operations in an effort to overcome the initial problem. However, this
means that if SMS has an invalid password, it tries the invalid password multiple times,
triggering an account lockout.
In some cases, SMS uses a valid password but uses it in an inappropriate circumstance. For
example, it might use a valid password for a valid account but in the wrong domain.
Usually SMS uses the correct password in the correct circumstances, and account lockouts are
rare. However, if you do encounter a lockout problem with an SMS account, consider from
which computer SMS is trying to connect with an invalid password.
166 Chapter 5 Understanding SMS Security

For example, if multiple SMS sites share the same SMS Service Account and the SMS Service
Account becomes locked out, then any one of those site servers could have the wrong password
for the SMS Service Account. Or possibly an administrator for one of the sites might run a site
reset and change the value for the SMS Service Account password, without notifying the other
site administrators so that they can change the account password on their SMS sites if necessary.

Avoiding Orphaned Clients


Legacy Clients can become orphaned if they do not have a valid Client Connection Account. If a
Legacy Client has one Client Connection Account identified to connect to its CAP, and that
Client Connection Account password is changed at the SMS site, the Legacy Client might not
receive the new password before it tries to connect to the CAP. It connects using the old
password information, and potentially locks out the account in the domain. To avoid this
problem, create multiple Client Connection Accounts, that you maintain. Account information
for all these Client Connection Accounts are sent to each Legacy Client, ensuring that the clients
always have a valid Client Connection Account password to use.
Using Password Filters
If your organization uses password filters, passwords that SMS automatically generates might
fail to pass the password filter rules, causing the accounts creation to fail. SMS tries five times to
generate a password.
SMS generates strong passwords, using common password generation rules. However, if the
password filter rules are sufficiently restrictive, SMS might not be able to automatically create its
accounts. SMS generates a status message in this case. You can manually create most of the
accounts SMS needs.
Examples of password filter rules that SMS might not comply with are those in which a certain
type of character has to be used between the third and sixth character, or those that do not allow
punctuation.
Rules requiring a certain minimum length and more than one type of character work very well
with SMS. Rules can even require that at least one character of each of these four types is used in
the password: uppercase, lowercase, numeric, and punctuation.

Managing Accounts Through Site Setup and Site Reset


Site setup and site reset are two processes that you can use to manage certain SMS accounts. The
following sections describe how each running each process affects SMS accounts, and how you
can use each process effectively.
Site Setup
You might need to specify the details for SMS accounts during site setup, for an example, when
you are minimizing the number of accounts that SMS uses.
The following sections describe how to specify the details for the SMS accounts when you are
setting up a site.
SMS Accounts and Groups 167

If you have to reset a site, run the setup program with the same command line as the initial
installation, to manually specify the accounts. If you do not manually specify the accounts, the
default server connection and client connection accounts are created.
To change the password for the default server or Client Connection Account, change the
passwords for the accounts and then run the setup program with the same command line as the
initial installation, this time specifying the new passwords.

Important
The initialization file, or any batch file with the command-line options,
displays the passwords for these default server and Client Connection
Accounts in plain text. Therefore, it is important to restrict access to these
files. The Windows NT system directory has restricted access, but you must
take extra precautions if these files exist outside of that directory.

Setting Up SMS Sites in Active Directory Sites with Multiple Domain Controllers
SMS site setup in standard security creates a number of accounts. Some of the accounts are used
in the course of the setup, at which time they must be authenticated. However, in a
Windows 2000 or Windows Server 2003 Active Directory site with multiple domain controllers,
the domain controller used to authenticate the accounts might not be the domain controller used
to create the accounts. If the accounts have not replicated between the two domain controllers,
the authentication fails and the setup fails.
To avoid this problem, create the accounts before setting up the site, and allow time for the
accounts to replicate. Use the setup command-line options or setup initialization file options to
use the manually created accounts.
The SMS Service Account must be created prior to setup in this scenario.
Do not configure the site with site systems, site-to-site relationships, or Legacy Clients, until the
following accounts have had time to replicate if they are domain accounts:
u SMS Server Connection Account if the site server is on a domain controller
u Site System Connection Account
u Site Address Accounts
u SMS Client Connection Accounts
u Client Push Installation Account (if used)
168 Chapter 5 Understanding SMS Security

Secondary site setup from the SMS Administrator console retries a number of times, so it should
succeed even if the SMS Service Account is not replicated at the time the secondary site setup is
initiated. Site system set up, such as client access points, also retries and therefore should
succeed even if the site system is set up on a domain controller and the SMS Remote Service
Account takes some time to be replicated.

Important
SMS administrators must be familiar with the replication and timing values
set by the Knowledge Consistency Checker among multiple Active Directory
domains. It is possible in some Knowledge Consistency Checker scenarios,
especially when the Active Directory administrator customizes Knowledge
Consistency Checker settings, for SMS Setup to time out when creating
accounts if the replication interval is too long.

Setup Command-Line Options


SMS Setup has command-line options available for specifying the Client Connection and Server
Connection Accounts, and the Site System to Site Server, Site System to SQL Server, and Site to
Site Connection groups.
The accounts or groups must exist and have the proper rights. When you manually specify the
accounts or groups, the setup program does not create the default accounts or groups, and you
control the passwords that are given to the accounts.
The syntax of the setup command is as follows:
setup /ServerAccount <domain>\<account> /ServerPassword <password>
/ClientAccount <domain or computer>\<account> /ClientPassword <password>
/SiteSystemGroup <domain or computer>\<groupname> /AddressGroup <domain or
computer>\<groupname>

For example, when installing a site, you might want the setup program to use
MyDomain\SMSServerAcct (password Elvis1) as the Server Connection Account,
MyDomain\SMSClientAcct (password Elvis2) as the Client Connection account,
MyDomain\SiteSystems as the site system group, and MyDomain\Addresses as the address
group (Site to Site Connection group). You can invoke the setup program by using the following
syntax:
setup /ServerAccount MyDomain\SMSServerAcct /ServerPassword Elvis1
/ClientAccount MyDomain\SMSClientAcct /ClientPassword Elvis2 /SiteSystemGroup
MyDomain\SiteSystems /AddressGroup MyDomain\Addresses

However, to use the command-line arguments, you must be able to specify the setup command.
Therefore, you cannot specify a created server and Client Connection Account when running the
SMS Setup Wizard or the Create Secondary Site Wizard, which uses a setup command that you
cannot specify.
SMS Accounts and Groups 169

Setup Initialization File Options


You can also use an initialization file to specify the same accounts and groups as the setup
command-line options, and you can also specify the SQL Server access group.
To specify accounts or groups for a site setup by using an initialization file, create a file called
SMSAccountSetup.ini in the %Winnt%\System32 directory of the targeted site server. The file
lists the server and client account information in the following format:
[ServerAccount]
Name=domain\account
Password=password
[ClientAccount]
Name=domain\account
Password=password
[SiteSystemGroup]
Name=domain\groupname
[AddressGroup]
Name=domain\groupname
[SQLGroup]
Name=domain\MySqlServerGroup

The “SiteSystemGroup” is the Site System to Site Server Connection group. The
“AddressGroup” is the Site To Site Connection group. The “SQLGroup” is the Site System to
SQL Server Connection group.

Note
Instead of specifying domain accounts in the initialization file, you can
specify local accounts. Using local accounts minimizes your dependence on
domain accounts. If a domain is not specified, SMS tries to use the account
as a local account.

When the setup program is started, it reads the SMSAccountSetup.ini file from the
%WINNT%\system32 directory if the SMSAccountSetup.ini file exists. The user accounts
specified in the initialization file are treated the same as the /ServerAccount and the
/ClientAccount command-line arguments and the default accounts and groups are not created.

Important
On computers running Windows 2000 or operating systems in the
Windows Server 2003 family, non-administrative users can, by default, read
files in the System32 directory. By default, they cannot log on to servers, so
the SMSAccountSetup.ini file is secured in that way. However, if you let non-
administrative users log on to SMS servers, they could read this file. To
prevent this, remove the Users and Power Users permissions on this file.
170 Chapter 5 Understanding SMS Security

Site Reset
SMS site reset stops the core SMS site services, removes them, and then reinstalls them. This can
be done:
u To repair a damaged site server.
u To make account or password changes effective.
u To direct the site to use a different SQL Server database name or a server running
SQL Server, or a different SQL Server security mode.
If there has been a change to the accounts used by the SMS components, site reset ensures the
account details used by the SMS components are correct.
The exact effect of site reset depends on how the site reset is initiated and which options are
selected, which can include:
u Site reset from the SMS Administrator console.
u Site reset from setup.
u Site reset from Preinst.exe.
Site reset from the SMS Administrator console
Runs when you update the site accounts through the Accounts tab in the Site Properties dialog
box in the SMS Administrator console. This reset does not affect accounts other than the SMS
Service or SQL Server account information, if changed. Hierarchy Manager removes and
reinstalls the Site Component Manager, and passes an updated site control file to it. The Site
Component Manager then does the usual site reset removal and reinstall of the following local
services:
u SMS_Site_Component_Manager
u SMS_Executive (only on the site server itself)
u SMS_Site_Backup
u SMS_SQL_Monitor (only on the site server itself)
Site reset from setup
Runs when you select the setup option Modify or reset the current installation in the SMS
Setup Wizard. Site reset removes and reinstalls all SMS services that use the SMS Service
Account, including those on the site server, the site’s CAPs, and the server running SQL Server,
and affects the following services:
u SMS_Site_Component_Manager
u SMS_Executive (on the site server or component servers)
u SMS_Site_Backup
u SMS_SQL_Monitor (on the site server or component server)
SMS Accounts and Groups 171

If you specify changes through the SMS Setup Wizard, the site reset updates the SMS Service or
SQL Server account information stored in SMS. Also, site reset points the site to a new database
name or SQL Server, or it changes the SQL Server security mode if you specify such a change in
the SMS Setup Wizard.
During a site reset, passwords for the component server service accounts used by Inbox Assistant
and SMS SQL Monitor are automatically changed by Site Component Manager during the initial
site shutdown, while setup is still running. The sequence for each core component on a
component server is:
u SMS component shutdown is completed.
u SMS components are flagged for reinstallation.
u SMS Remote Service Account is recreated.
Setup shuts down the services, changes the SMS Server Connection Account password, installs
the Site Component Manager, and then creates an updated site control file. At this point in the
cycle, the SMS Setup Wizard displays a dialog box allowing you to skip changing the SMS
Server Connection Account password. You should skip this change if account lockout is enabled
in the domain, and you want to avoid the risk of locking out the SMS Server Connection
Account. You can then choose the best time to reset the SMS Server Connection Account,
independent of other reset requirements.
If site reset recreates the SMS Server Connection Account, the new account has a new security
identifier, and it does not have the same access to SMS resources as the old account. Giving full
permissions to the new account on the SMS directory tree allows the SMS servers to connect to
the SMS site server properly.
If the SMSAccountSetup.ini file specifies passwords for the SMS Server Connection Accounts,
the SMS Setup Wizard uses that information to reset the account. Otherwise, SMS Setup
generates a random strong password for the default SMS Server Connection Account
(SMSServer_sc). If you enable account lockout in the domain, then resetting the account could
result in its becoming locked out. This would happen if an SMS server attempts to connect to the
site server before the new password for the SMS Server Connection Account is propagated to all
SMS servers. Therefore, you might prefer to reset the account during a quiet period for the site
rather than doing it when the message appears during reset. You should also watch the SMS
Server Connection Account and unlock it if it becomes locked out.
172 Chapter 5 Understanding SMS Security

Site reset from Preinst.exe


Site reset runs when you run the command PREINST /STOPSITE. This reset is similar to the
reset initiated by SMS Setup. However, the password for the SMS Server Connection Account is
not modified because that functionality is part of setup itself, not part of Site Component
Manager. SMS Setup also changes the passwords for the accounts used by remote services on
CAPs and by the SMS_SQL_Monitor service.

Note
Site reset does not manage the default SMS Client Connection Account. The
original site setup creates the SMS Client Connection Account, but after that
it must be managed through the SMS Administrator console, and a site reset
is not required to implement any changes. Site reset also does not change
any of the other site or client accounts, or set a trigger for them to be
changed or updated. Most of the rest of the accounts are managed through
the SMS Administrator console.

SMS Object Security


SMS generally relies on other technologies to enforce security. For example, SMS sets security
on file shares and then relies on the operating system to authenticate accounts and allow only
correct accounts to access the shares. The only way that SMS itself enforces security is when you
access an SMS object through the SMS Provider. The SMS Provider compares the user who is
attempting to access the SMS object to the SMS security permissions on that SMS object, to
determine if the user has the right to access or change the objects. The SMS Provider enforces
SMS object security when you access SMS objects through the SMS Administrator console or
through a program that access SMS through WMI.
You can grant permissions on an SMS object to a single user or to user groups within a domain.
For example, you can specify that all members of the Domain Users group can edit packages.
You can specify that specific users can edit only the packages that they create. You can allow an
administrator to manage all collections or just one. For each security object or object type, you
can grant a number of different permissions. This granularity gives you great control over who
can access SMS object types and who can access specific information in the SMS site database.
You can set object security on the seven SMS object classes listed in Table 5.9.
Table 5.9 SMS Classes for Granting Security Rights
Object class Console item
SMS_Advertisement Advertisements
SMS_Collection Collections
SMS_Package Packages

(continued)
SMS Object Security 173

Table 5.9 SMS Classes for Granting Security Rights (continued)


Object class Console item
SMS_Query Queries
SMS_Report Reports
SMS_Site Sites
SMS_MeteredProductRule Software Metering Rules
SMS_StatusMessage Status Messages

You can configure security for SMS object types at either the class level or the instance level:
Class level
This level grants users permissions for all object types in a specific class — for example, all
packages or all collections.
Instance level
This level grants permissions for a specific instance of an object type, such as the “All
Windows 98 Systems” collection or a “New York City Site” collection. Because status messages
are very numerous, they do not have instance-level rights.
In both cases, you grant or deny permissions on a per-user or user group basis.
For example, the class-level Read right on collections allows you to see all the collections (and
the members of each collection). The instance-level Read right on one particular collection
allows you to see that collection (and its members). However, you can not see any resources in
any other collection.
SMS object permissions are cumulative. For example, if a user has the Read right on one
collection (for example, “All Systems”), and the Use Remote Tools right on another collection
(“Collection A”), then the user has the Read and Use Remote Tools rights on all systems that
are members of both collections. The user can view a resource in the “All Systems” collection
and use Remote Tools with that resource if that resource is also in the “Collection A” collection.
If the resource is not in the “Collection A” collection, then the user cannot use Remote Tools
with that resource. The fact that the user does not have the Remote Tools right in the “All
Systems” collection does not mean that they are denied use of Remote Tools to all computers in
the “All Systems” collection. The user is only denied use of Remote Tools to computers in the
“All Systems” collection that do not have the Use Remote Tools right in any other collection
that includes that computer.
174 Chapter 5 Understanding SMS Security

Because SMS rights are cumulative, if you grant a user class security rights to an SMS security
object and conflicting instance security rights to a specific SMS security object, SMS reconciles
the class and instance security rights to grant the highest level of permissions. The exception to
this rule is no permissions. For example, if you grant the user full permissions to all packages at
the class level and Read permission to a specific package at the instance level, the user’s
effective permissions are full permissions to all packages including that one specific package set
with read permission. If you grant the user full permissions to all packages at the class level and
no permissions to a specific package at the instance level, the user’s effective permissions are full
permissions to all packages except the one specific package set with no permissions. Similarly, if
you grant a user no permissions to all packages at the class level, and full permissions to a
specific package at the instance level, the user’s effective permissions are no permissions to any
packages except the one specific package set with full permissions.
By default, only two accounts are granted permissions to all objects in the SMS Administrator
console:
u The local system account (“NT Authority/System”).
u The user account that was logged on when SMS Setup was run to set up the primary site.
You must explicitly add other accounts and grant them permissions to SMS objects. Without
permissions, users who can launch the SMS Administrator console can only see the high-level
nodes in the SMS Administrator console, along with the Security Rights, Online Library, and
Tools. Users cannot see any data other than the Security Rights, and they cannot manipulate the
Security Rights.
When granting permissions to accounts, you can grant permissions to users, local groups, global
groups, universal groups, and nested global groups. However, all accounts that have SMS object
security rights must also have access to the SMS WMI namespaces. You can do this by putting
the accounts in the SMS Admins local group

The SMS Object Security Rights


For each class or instance, you specify rights such as Create, Administer, or Delete Resource
rights. Some rights are specific to an object type. For example, the Distribute right only applies
to package objects.
Table 5.10 describes each right and the security object types for which they are available.
SMS Object Security 175

Table 5.10 SMS Object Security Rights


Right Applies to Grants the ability to
Administer All secured object classes Assign or remove any user security rights for a class
of objects or for individual object types in that class
to yourself or to any other user.
You must explicitly grant other rights appropriate to
the object type. Granting the Administer right to a
user does not automatically give the user Create,
Modify, or Delete rights for that object type.
Advertise Collection object classes and Advertise to a collection. Subcollections to the
instances collection are also advertised to, even if the
administrator does not have the Advertise right on
the subcollections.
This right does not grant the ability to create
advertisements — that requires Create right on the
advertisement object type.
Create All secured object classes Create an instance of an object type.
Delegate All secured object classes Grant rights for any instances created by the user.
The only rights that can be granted are rights the user
has directly (not through group membership or at the
class level).
Delete All secured object classes Delete an instance of an object type.
and instances (except status
message instances)
Delete Resource Collection object class and Delete a resource from a collection.
instances
Distribute Package object class and Send packages to distribution points.
instances
Manage SQL Site object class and Create, modify, and delete site maintenance SQL
Commands instances commands.
Manage Status Site object class and Create, modify, and delete status filter rules.
Filters instances
Meter Site object class and Apply software metering rules to the site.
instances
Modify All secured object classes Modify an instance of an object type.
and instances (except status
message class and instances,
which cannot be modified)

(continued)
176 Chapter 5 Understanding SMS Security

Table 5.10 SMS Object Security Rights (continued)


Right Applies to Grants the ability to
Modify Resource Collection object class and Modify a resource in a collection.
instances
Read All secured object classes View an instance and its properties.
and instances (except status
message instances)
Read Resource Collection object class and Read a resource in a collection. Resource Explorer
instances. can be used on the resource to view hardware
inventory and software inventory data. If the
administrator does not have this right at the class
level, all the collections he creates must be
collection limited to collections he already has rights
to.
Use Remote Collection object class and Use Remote Tools on a resource.
Tools instances
View Collected Collection object class and View the files collected from a client. Resource
Files instances Explorer can be used on the resource to view
collected files.

For each object type, there must always be at least one account with the class-level Administer
right. This prevents administrators from being locked out of the SMS system. As a result, it is not
possible to delete the final user on an object type with the Administer right. Also, you cannot
delete your own Administer rights on an object.
Users who create an instance of an object are automatically assigned Read, Modify, and Delete
rights for that instance.
You can grant permissions to objects by granting rights to user groups in your organization to
address their specific needs. For example, if your help desk technicians have a user group, you
can grant that group Use Remote Tools rights for Collections. If users who are not SMS
administrators want to view and query inventory collected from clients, you can grant those users
Read rights to Collections and Queries, along with Read Resource rights to Collections.
When creating an object (such as a collection or advertisement), the user might want to allow
other users (or groups) to use or manage the object. This is possible if the user has the class-level
Administer right, but that also allows them to do anything they want to with any instance of that
object type. A better solution is to give the user the class-level Delegate right, which allows them
to grant rights to users and groups for objects they create. However, users can only grant rights
that they are explicitly granted at the instance level, and cannot grant rights that they are granted
through group membership or at the class level.
SMS Object Security 177

For example, a user might have the class-level Create and Delegate rights for Collections. The
user also has instance-level Read, Read Resource, and Advertise rights for the “All
Windows XP Systems” collection. The user can then create a new collection based on the
membership of the “All Windows XP Systems” collection. The user can then grant the Read and
Read Resource rights to the new collection — but not Create or Delegate rights — to another
group so that the members of that group can view members of the new collection.

Note
To maximize security, grant permissions to each administrator carefully at
the instance level, unless they require permissions at the class level. Create
a collection of the resources that each administrator manages and grant
permissions only to that collection. As a result, each administrator sees only
those security objects to which access is granted.
To improve security, do not give your SMS administrators the right to log on
to the site server. Have your administrators use the SMS Administrator
console remotely.
To minimize administrative overhead, give all administrators or some
administrators full control of all objects in the SMS site database. The
easiest way to do this is to create or use a group that has the correct
permissions. Then, as you add administrators to the site, you can easily add
them to the group.

Viewing resources in collections and queries


Often, the rights you set on collections affect your ability to perform tasks in other nodes in the
SMS Administrator console. For example, granting the Read SMS object security right on a
collection not only gives the user the right to see that collection, but also to see resources within
that collection. The user can view the properties of the resource and can invoke the Resource
Explorer, but they cannot see the values of the Resource Explorer groups. For that level of detail,
the user also requires the Read Resource right. To further manage computer resources, give the
user the Use Remote Tools or View Collected Files rights. To remove the resource from SMS
altogether (as opposed to just removing the collection rule that makes that resource a member of
the collection), the user must have the Delete Resource right.
You can manage resources through queries, but the Read right on queries only gives you the
privilege to see and run the queries. The right to view resources in a query result window and to
manage those resources is granted by the rights set for collections that those resources are in.
Site maintenance
To manage the SMS site database, site maintenance SQL Server commands can be created in the
SMS Administrator console, under the Site Settings node for each site. These commands have
complete privileges in the SMS site database and can manipulate the data and database in any
way. To prevent malicious use of this powerful facility, you should limit the Manage SQL
Commands SMS object security right to only those senior SMS administrators that require this
right.
178 Chapter 5 Understanding SMS Security

Software metering security


One of the primary software metering tasks is to create software metering rules. Software
metering rules can apply not only to the site they are created for, but also to the child sites of that
site. To manage software metering rules, the SMS administrator must have appropriate software
metering rule SMS object security rights. For those rules to apply to a site, the administrator must
also have the site’s Meter instance right, or the class-level site Meter right, in which case the
rules apply to all sites the rule is distributed to. The Meter rights that are relevant are the rights at
the site the rule originates at, not the rights at the sites the rule is distributed to.

Changing SMS Object Rights


You have several options available to change SMS object rights:
u Change the class and instance rights directly
u Use the SMS User Wizard
u Use the Clone SMS User dialog box
u Use scripts (see Appendix C, “Scripting SMS Operations” in the Microsoft Systems
Management Server 2003 Operations Guide.)

Note
Copying the rights from one user to another can be very time consuming.
The SMS Administrator console can be unusable during that time. To avoid
this problem, do not copy instances rights from the other user if the class
rights are sufficient.

Important
In some cases you can remove the SMS rights for the local system account -
NT Authority\SYSTEM. You should not remove those rights. This version of
SMS does not use those rights, but future versions or tools might require
those rights.

Changing class and instance rights directly


You can directly change class and instance rights for SMS objects in the SMS Administrator
console in two ways:
u Right-click an object (such as a collection), select Properties, and then click the Security
tab. Change the rights as necessary.
SMS Object Security 179

u Right-click Security Rights, select New, and then click Class Security Right or Instance
Security Right. Or select Security Rights, right-click the appropriate right, and click
Properties. Change the rights as necessary.

Note
When granting rights by using the Delegate right, you can only grant rights
that you have. In the SMS Administrator console, rights that you cannot
grant are indicated with a lock icon.

Security Rights can have many entries, especially in an SMS site that has been in production for
some time. To filter the entries displayed, right-click Security Rights, and then click Properties.
Clear any entry you do not want to see.

Important
The permissions filter continues to be effective until you change it. This
could cause confusion at a later date when you return to the Security Rights
node and do not see all the permission entries. To avoid that problem,
include all the permissions on the filter when you are done working with
permissions.

Using the SMS User Wizard


To facilitate the addition of SMS object security rights to users or groups, you can use the SMS
User Wizard. To use the SMS User Wizard, navigate to the Security Rights node in the SMS
Administrator console.
Systems Management Server
X Site Database (site code - site name)
X Security Rights
Right-click the Security Rights node, click All Tasks, and then select Manage SMS Users.
The SMS User Wizard allows you to modify an existing user, add a new user, or remove an
existing user. When adding a new user or modifying a current user, you can modify rights
individually or copy them from another user. Repeat these steps as needed.
180 Chapter 5 Understanding SMS Security

The SMS User Wizard automatically adds new SMS administrators to the SMS Admins group.

Important
When adding a new user, SMS might display the following message: “SMS is
unable to verify that the name you entered is an existing Windows user or
user group account.” This might occur because of a typing error, an
underlying problem that prevents the wizard from verifying the account, or
because the account is a local user group. All accounts granted SMS object
security permissions must have access to the SMS WMI namespace. You
can give accounts access to the SMS WMI namespace by putting the
accounts in the SMS Admins local group. Local groups cannot be added to
local groups. Therefore you must manually provide the WMI rights to a local
group so that it can access the SMS WMI namespace.

Cloning SMS Users


If you want to add a user with the same rights as a current user, you can clone SMS the current
user’s permissions. To clone an SMS user, navigate to the Security Rights node in the SMS
Administrator console.
Systems Management Server
X Site Database (site code - site name)
X Security Rights
Then right-click the current user, click All Tasks, and select Clone SMS User. However, the
Close SMS User Wizard does not put the new account into the SMS Admins group. You must do
that manually.

SMS Feature Security


The Microsoft Systems Management Server 2003 Operations Guide describes using SMS
features. In addition, SMS Help contains detailed instructions on how to work with SMS feature-
level security. This section describes additional security details for the following SMS features:
u SMS Query and Report Security
u SMS Remote Tools Security
u Software Distribution Security
u Inventory Collection Security

SMS Query and Report Security


When you run queries in the SMS Administrator console, you must have SMS object security
rights on the objects included in the query. In addition, when you create a query, Values on the
Criteria tab of the Query Statement Properties dialog box returns no data if you do not have
Read and Read Resource rights to the Collections class.
SMS Feature Security 181

Queries in the SMS Administrator console access the SMS data through the Configuration
Database WMI Provider and are subject to SMS Object security. They can also be collection
limited, so that users can only query data for resources in collections they are authorized to use.
Even when the user does not specify collection limiting when creating a query, SMS applies
collection limiting if the user is not authorized to view all resources.
Administering SMS Reports is controlled from the SMS Administrator console by WMI security,
SMS object security for the reports, and IIS security. Viewing SMS Reports does not use SMS
object security unless the administrator is viewing the report from the SMS Administrator
console. For example, a user who has the right to run a report of collections can list all
collections even if they do not have any collection rights, or if they are only authorized to use
certain collections. You can limit this exposure by ensuring that the SQL statement used by the
report limits the results to data that the user should be able to see. However, administrators that
have the rights to create reports but not to view all collections in the SMS Administrator console
can create a report that lists all collections.
In addition to having SMS object security rights for reports, report administrators must have the
right to connect to the SMS site namespace in WMI. Normally SMS administrators have this
right by being members of the SMS Admins local group. You can also grant them access to the
namespace individually or using a group that they are members of.
The users of SMS Reports must also have access to the SMS reporting Web site. By default, all
members of the Administrators and SMS Reporting Users groups have access to the Web site.
The SMS Reporting Users group does not have any members by default.
To give a non-administrator the ability to run SMS Reports
1. Add the user, or a group the user is a member of, to the SMS Reporting Users group on the
reporting point.
2. If the user must access reports on multiple reporting points, repeat step 1 for each of those
reporting points.
Dashboards are not secured at the SMS object security level. However, the reports that are
components of dashboards are subject to SMS object security.
SMS Reporting accesses the SMS SQL Server views using a SQL Server application role named
“webreport_approle.” This role is secured with a random password automatically generated and
securely stored by SMS.

Security for Querying and Reporting Methods Other Than SMS Reports
Products such as Microsoft Access or third-party report tools access the SMS site database
through WMI by using the WBEM ODBC driver. Scripts, Web pages, and similar tools use the
WMI scripting model to query SMS. All of these reporting options require access to WMI and
the SMS Provider, and you control access using WMI security and SMS object security.
182 Chapter 5 Understanding SMS Security

Reports that use SMS data that is accessed through SQL Server views are done by products such
as Microsoft Access or third-party report tools that access SMS data through SQL Server views
use the SQL Server ODBC driver or any other scripting model that accesses SQL Server data
directly. Add users who connect to the SMS site database using Windows Authentication to view
reports to the SMS Reporting Users group. Add users who connect to the SMS site database
using SQL Server Authentication to view reports to the smsschm_users SQL Server role. The
smsschm_users SQL Server role has the “SELECT” right to all SMS SQL Server views.
Alternatively, you can grant individual users or role permissions to specific views if you want to
limit access to the SMS data.

SMS Remote Tools Security


Remote Tools has three levels of security — collection security, the Permitted Viewers list, and
asking the user’s permission. Collection-level class and instance security facilitates the flexible
enforcement of remote tools security so that you can tailor Remote Tools usage to your
organization’s needs. The Permitted Viewers list provides an authorization step at the client
before a user can start a remote session. Asking the user’s permission ensures that no one can
remotely control the computer without permission from the user.
SMS 2003 includes the option to use Terminal Services, Remote Desktop Connection, and
Remote Assistance in addition to Remote Tools if the console and client operating systems
support those options. For more information about their security and auditing, see the
documentation for those operating system features.
Bypassing collection security for Remote Tools is easy for knowledgeable or determined people.
They could set up an SMS site that is not part of your SMS hierarchy and create resource records
for clients they want to control. They could give themselves any rights they want on those
resources. Or they could use the Remote.exe /SMS:nosql switch, as described in the
“Remote.exe” section later in this chapter. You should think of collection security for Remote
Tools as an organizational convenience and effective for staff that follow your policies and
procedures.

Note
Collection security is an effective form of security for other SMS features
where the clients must report to authorized sites or the feature is entirely
dependent on the site server. But with Remote Tools the clients are
controlled directly from consoles, regardless of which site the client is
assigned to or the console is using.
SMS Feature Security 183

Security Provided by the Permitted Viewers List


The Permitted Viewers list defines the users and user groups that have permission to remotely
access clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003
family operating systems. In the Remote Tools Client Agent Properties dialog box, the
Security tab contains the Permitted Viewers list. You can use the Permitted Viewers list to add
and delete permitted viewers. By default, if the user account you are using to connect to a client
is not a member of the Permitted Viewers list, SMS prompts you for an appropriate user name
and password.
How the Permitted Viewers list works
Local administrator rights are not required for a user to be able to use Remote Tools. If the
collection and Permitted Viewers list security is met, the Remote Tools user can use Remote
Tools on the client.
When initiating a remote control session, if the client cannot authenticate the account that is
attempting the remote control, either as an account or as a valid entry in the Permitted Viewers
list, then the connection is rejected. For example, a client might not be able to authenticate the
account when the remote control user is from a nontrusted domain. However, a dialog box is
displayed, allowing the administrator to enter credentials, user name, password, domain, or the
local computer name. If those credentials can be resolved as valid, then the administrator is
allowed to remotely control the client.
The permitted viewers are resolved to security identifiers when the Remote Control Agent is
started on the client. The names are resolved to local accounts, if appropriate, then domain
accounts for the domain on which the client computer is installed, and finally for trusted domains
of the client’s domain. Groups are considered to be accounts, for this purpose, so they are
resolved in the same way as user accounts. Members of global groups that are members of local
groups listed in the Permitted Viewers list are not enumerated, and thus members of global
groups are not permitted viewers unless they are otherwise permitted viewers. As an example, if
a user is a member of the Domain Administrator’s group, and the Domain Administrator’s group
is included in the local Administrator’s group, the user cannot control the client unless the user’s
account or group is specifically included in the permitted user list. For this reason, if you want all
domain administrators to have remote control of clients, be sure you specifically include the
Domain Administrators group in the Permitted Viewers list, rather than rely on its inclusion in
the local Administrator’s group.
There is a two-minute time-out during which administrators who are attempting to use Remote
Tools do not require permission from the end-user to perform additional Remote Tools tasks. If
one administrator ends the sessions with the client, another administrator could start a session
within this time-out and would not require permission from the user, even if the policy is set to
ask permission from the user. However, the administrator must still pass the collection-level
security and Permitted Viewer list security on the client computer.
184 Chapter 5 Understanding SMS Security

Local and global groups in the Permitted Viewers list


For clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003
family operating systems, SMS Remote Tools relies on the operating system’s security to
validate users and groups against security objects. When you include a local group in the
Permitted Viewers list, remember that the group is local to the domain in which it was created,
regardless of trust relationships. Therefore, if a client is in a different domain that does not also
include the same local group, the client is unable to authenticate users from this local group.
When you attempt to establish a Remote Tools connection, if the client cannot authenticate your
user account as a valid member in the Permitted Viewers list, then the connection is rejected. For
example, a client might not be able to authenticate the user account when the Remote Tools user
is from a nontrusted domain. In this case, the Credentials Required dialog box appears and
prompts the administrator to enter username, domain (or local computer name), and password. If
those credentials are accepted, the administrator can connect to the client.
When a global group is included in a local group that is listed in the Permitted Viewers list,
members of that global group are not implicitly included as permitted users and are not resolved
when attempting to establish a Remote Tools connection. Members of such global groups are not
resolved as permitted viewers unless the global group is explicitly listed in the Permitted Viewers
list. For example, if a user is a member the Domain Administrators global group, and the Domain
Administrators global group is included in the local Administrators group, the user is unable to
connect to the client unless the user’s account or the Domain Administrators global group is
explicitly listed in the Permitted Viewers list.
Using accounts in trusted domains environment
In a complex domain environment, your SMS site server might be in one domain, and the clients
are in other domains, with trust relationships between the domains or another master domain. In
this situation, the user accounts or user groups included in the Permitted Users list must be fully
qualified, by using the following syntax:
domain\user account
The client domains also must have a trust relationship with the domain that contains the user
account or user group, so that the client can authenticate the account.
Permitted Viewers list in a nondomain environment
For clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003
family operating systems, which are not authenticated through a domain or Active Directory, you
must create a local user account on the client before you can establish a Remote Tools connection
to the client.
SMS Feature Security 185

Security Provided by Asking for User Permission


When you enable the Display a message to ask for permission option as a site-wide setting, the
user logged on to the client must grant permission for you to perform any Remote Tools function.
However, if you perform a Remote Tools function (for example, Remote Control) on a client and
then discontinue performing that function, you can perform the same Remote Tools operation to
the same client for a period of up to 10 seconds without regaining the user’s permission. If you
attempt to perform a different Remote Tools function, even within 10 seconds, the user must
grant permission. After 10 seconds, an attempt to perform any Remote Tool function on the same
client requires user permission.
Clients that are running Windows 98 can rely only on the security provided by asking for user
permission for Remote Tools security. Clients that are running Windows 98 do not have
Permitted Viewers lists, and collection security can be bypassed. If you do not want to have the
possibility of unauthorized people remotely controlling your computers that are running
Windows 98, you must enable the option to ask user’s permission on at least one site that the
clients running Windows 98 are assigned to. You can set this option so that user’s permission is
only required on computers running Windows 98, so that permission is not required on other
clients.
Remote Tools Security Considerations
There are various security considerations you should take into account when using Remote
Tools:
u Remote tools sessions
u Remote tools client agent security settings
u Membership in the Permitted Viewers list
u Remote.exe
u Client programs that run with administrative privileges
Remote Tools sessions
To establish a Remote Tools connection to any client, you must have Use Remote Tools and
Read rights for a collection that contains the client, and for clients running Windows NT 4.0,
Windows 2000, Windows XP, or Windows Server 2003, you also must be included in the
Permitted Viewers list, which is on the Security tab of the Remote Tools Client Agent
Properties dialog box. If you set remote tools to require the user’s permission, the user must
permit you to establish a remote tools session.
Entries are written to the operating system event log on the client computer when a Remote
Tools session is started and completed. Also, SMS status messages are written every time a
Remote Tools session is initiated, unless the Remote.exe /sms:nosql command-line option is
used. Predefined queries are available in the SMS Administrator console to display the remote
tool status messages.
You can configure SMS to display an icon on the user desktop to indicate use of Remote Tools
on the computer. There are several levels of prominence that can be given to this icon.
186 Chapter 5 Understanding SMS Security

Remote Tools client agent security settings


You can control Remote Tool security settings on computers running Windows NT 4.0,
Windows 2000, Windows XP, or Windows Server 2003 family operating systems by
manipulating appropriate registry entries and stopping and restarting the SMS Remote Control
Agent. For complete control of Remote Tools security, it is important to ensure that remote
registry editing and remote service control are properly secured. Refer to operating system
documentation for details on registry and services security.
Membership in the Permitted Viewers list
The Permitted Viewers list is intentionally ambiguous because a user is authenticated against the
list at the client, and the SMS site server might not have access to the same domains as the client.
Consequently, you can enter an account name in the Permitted Viewers list without specifying a
domain for the account. However, the list must be clear at the client. Therefore, it is
recommended that you enter an account name in the Permitted Viewers list by using the format
domain\account to remove any ambiguity that might occur at the client.

Note
The localized versions of the “Administrator” user name that appear by
default in the Permitted Viewers list could give Remote Tools access to
unintended users. If you do not use the localized versions of the
“Administrator” user name in your organization, remove them from the
permitted viewers list. Removing unnecessary accounts from the Permitted
Viewers list also reduces the amount of time and the amount of network
authentication traffic needed for the client to authenticate the user and
establish the remote session.

Remote.exe
Remote Tools can be run from the command line, or another program, by using Remote.exe. For
more information about Remote.exe, see Chapter 9, “Remote Tools,” in the Microsoft Systems
Management Server 2003 Operations Guide. Remote.exe enforces security in the same way that
running Remote Tools from the SMS Administrator console does. However, Remote.exe
includes a /SMS:nosql switch that does not enforce collection security. The /SMS:nosql switch
allows you to use SMS Remote Tools even when the SMS site is unavailable.
When you use the command-line interface to run Remote Control, the computer you specify is
always resolved to a resource ID in the SMS_R_System class. SMS object security is then
scanned to determine if the administrator has the right to remotely control this resource. Any
differences in the ability to remotely control a computer by using Remote.exe with different
parameters depends on the ability of SMS to resolve the computer address that is supplied, rather
than on differences in the application of security controls.
Client programs that run with administrative privileges
When you run programs on client computers using SMS Remote Tools, the programs run in the
security context of the administrator remotely initiating the programs and not in the context of
the user who is logged on at the time. The user can use that program with administrative
privileges.
SMS Feature Security 187

Users of the Remote Execute function should be careful not to run programs that the end user
could use to perform functions that they should not be able to do. This is especially true for
programs that do not terminate when the intended task is completed. For example, the Remote
Tools user should not start a command prompt window on the client computer.
When in a remote control session on a client computer, the remote control user should avoid
entering passwords for privileged accounts. The password is secure to the client computer, but
the password is entered through the virtual keyboard. Software that observes keyboard input
could capture the password. Or if the program being run on the client computer is the not the
program that the remote control user assumes, the program might be capturing the password.
When accounts and passwords are required, the end user should enter them.
Using Remote Control Securely
When you use remote control to fix a problem or make changes on a remote computer running
Windows NT 4.0, Windows 2000, or Windows Server 2003 family operating systems, it is
possible that a user is not logged on at the remote computer. This can be the case when you are
working on remote servers. However, during the session it is possible that the network link can
become congested or other problems might cause the session to fail. Often you can resume the
session by reconnecting. If the session fails before you log out of the remote computer, the
remote console remains logged on with your credentials, and potentially without any supervision.
Consequently, anyone who can get physical access to that server has your security rights and
permissions. This can represent a significant security risk.
There are several methods to make the remote computer secure again:
u Restart the computer using a remote restart tool, such as Shutdown.exe or Shutgui.exe, from
the Windows 2000 Resource Kit. If programs were open, it might be necessary to use the
option to restart even if data from open programs will be lost. Also, be sure to specify that
the computer restarts, instead of just shutting down. You can determine the success of this
method by pinging the remote computer. The computer will go offline for several minutes
and then come back online. You can use Srvinfo.exe (also from the Windows 2000 Resource
Kit) to ensure that the computer has been booted only for a minute after it is back online, and
that it did restart. You might have to use this method because a network reliability issue
could cause the session failure, and it might not be clear whether an unsuccessful restart is
the cause of the ping failures. When the computer restarts, it waits at the logon prompt, and
thus no one without privileges can work on the server. Use this technique if the computer
can be restarted at that time, and no other solution is available, or if the risk of someone
using your session is sufficiently great.
u Configure a secured screen saver to run when activity is idle for the user accounts that access
the server remotely. Then only users with administrative privileges on the computer can
unlock the screen saver after it runs. However, this allows the risk of someone using your
session until the screen saver starts.
u If any trusted staff are available at the remote location, you can ask them to log you off the
computer.
188 Chapter 5 Understanding SMS Security

Software Distribution Security


Clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003
family operating systems can run programs in two security contexts on the client: a logged on
user context or a service context. By default, SMS tries to install all software in the context of the
logged-on user. If the user is not expected to have sufficient rights to successfully run the
program, the SMS administrator can designate that the program requires administrative rights.
For Legacy Clients, you can specify that the Legacy Client Software Installation Account to use
to install the software. For both the Legacy Client and the Advanced Client running Windows
Installer packages requiring administrative rights, SMS uses Windows Installer elevated rights in
either the user or the system context, even if the user does not have administrative rights.
To access distribution points, Legacy Clients first look for an existing connection to the
package’s share on a distribution point. If they find that connection, they use it regardless of what
credentials were provided. If SMS clients do not find an existing connection to the server and
share, they attempt to connect using the current security context. In this case, the operating
system uses the context of any other connection made to the server. After the SMS client has
tried all options for connecting to the distribution point, the client attempts to connect using all
SMS Client Connection Accounts available for the site for Legacy Clients, or the Advanced
Client Network Access Account for Advanced Clients.

Important
An advertisement to a collection with subcollections is sent to all members
of the collection and subcollections, even if the administrator only has the
Advertise right to the collection (not the subcollections). Any administrator
who can link a collection to another collection can cause their collection to
receive the advertisements targeted to the other collection, even if they do
not have Advertise rights on any collection. For this reason you should watch
for the addition of subcollections to collections with advertisements, and be
cautious of who you give the rights to read collections that are advertised to.
Users with administrative rights on their Advanced Clients can set the client
to join any site, even if the computer is not within the boundaries of the site.
When the clients have joined the site, they can receive any software
distributions that are available at that site and where the computer or user
meets the qualifications of the relevant collections. For this reason, software
that should be limited to specific users should be secured at the package
access level to those users, rather than being limited by site availability or
collection criteria.
SMS Feature Security 189

Package Security
To distribute packages to distribution points, the administrator must have package Read and
Distribute SMS object security rights. They do not need the package Modify right. Although
distribution points are assigned to packages, the assignment is only relevant to the distribution
process. Therefore administrators who distribute packages to distribution points do not
necessarily have to be able to modify packages. The ability to modify packages can be restricted
to administrators who create packages.
By default, the package files on distribution points are fully accessible by administrators and
readable by users. When you are creating packages, you should consider using specific package
access accounts to allow only the appropriate users to access the packages when they are made
available.

Note
Changes to the access accounts on the package files (as opposed to the
distribution point shares) become effective only when you refresh the
package. Therefore, you should set the package access rights carefully when
you first create the package, especially if the package is large, if you are
distributing the package to many distribution points, or if your network
capacity for package distributions is limited. To quickly initiate the refresh of
all distribution points, you can use the Update Distribution Points task for
the package.

If you disable the Everyone group or have users in multiple domains, then the default package
access accounts might not be sufficient for your users to access the packages on the distribution
points. If these conditions are true in your organization, you must make it a standard part of your
package definition process to adjust the package access accounts.
When creating packages, many packages have sources files available from either a directory or
share. SMS uses those source files to update the packages. However, because the source files are
not necessarily in SMS directories, they are not be secured by SMS. If the files have been
tampered with, SMS clients could be compromised. Therefore, you must ensure that the source
files are secured.
You can set the access accounts for the package through the package properties in the SMS
Administrator console. The permissions you set through the SMS Administrator console affect
the folder shares on all the distribution points in your SMS site. For this reason the SMS rights
for creating and editing packages should be reserved for trusted senior SMS administrators.
To ensure the integrity of packages downloaded to Advanced Clients, hash values are calculated
for packages when they are sent from the originating site to distribution points and child sites.
The hash values are automatically included in advertisements of those packages. The clients
verify that the hash value of the package matches the hash value of the advertised program before
running the advertised program.
190 Chapter 5 Understanding SMS Security

Software Distribution Security on Clients


When packages are downloaded to Advanced Clients, the packages can be run by anyone on the
computer as long as the package is in the download cache. Or a user could copy the files to a
directory or share that can be accessed by other people. If unauthorized people must not be able
to access the files, the download option should not be used for those packages.

Software Distribution Use of Accounts


Advertisements that are intended to run in the context of the logged-on user have only the
privileges of the user, and they connect to the distribution point using the user’s credentials.
Advertisements that require administrator privileges run in a service-like security context with
the Client User Token Account on Legacy Clients, if the user does not have administrative
privileges. The Client User Token Account is dynamically added to the local Administrators
group as necessary (and then removed when the task is completed) and has the Act as part of the
operating system right.
The Legacy Client Software Installation Account allows a program to run on client in the
appropriate security context and to have access to specific non-SMS network resources. When
defining the advertised program properties, the administrator must designate that the Legacy
Client Software Installation Account be used for installing the package. Administrators must
specify a Legacy Client Software Installation Account that:
u Has access to the necessary non-SMS network resources.
u Has access to the SMS distribution point share and directories for the package.
u Is in a domain trusted by the client computer.
To maximize security, the Legacy Client Software Installation Account must not be granted any
rights on client computers, either directly or through group membership. The SMS client
components grant certain user rights and membership in the local Administrators group to the
Legacy Client Software Installation Account when a client runs a program that is designated as
requiring administrative rights. This membership and the user rights are removed when the
program finishes running.
Clients access packages on software distribution points by using the:
u User account in user context.
u Network Installation Account otherwise on the Advanced Client.
u Legacy Client Software Installation Account otherwise on the Legacy Client.
Running Software Distribution Wizards
You cannot run the Create Package from Definition Wizard if you do not have Modify rights for
the Sites class.
The Software Distribution Wizard does not work with restricted security. Advertise rights for the
Collections object is required.
SMS Feature Security 191

Inventory Collection Security


The IDMIF and NOIDMIF collection can be used to extend SMS hardware inventory collection.
When necessary, SMS creates new tables or modifies existing tables in the SMS site database to
accommodate the properties in IDMIF and NOIDMIF files.
However, IDMIF and NOIDMIF files are not validated, so they could be used to alter tables that
you do not want altered. Valid data could be overwritten by invalid data. Large amounts of data
could be loaded, causing delays in all SMS functions.
To help avoid these problems, you can disable the IDMIF and NOIDMIF collection, as described
in Chapter 2, “Collecting Hardware and Software Inventory,” of the Microsoft Systems
Management Server 2003 Operations Guide.
Extending hardware inventory collection by using SMS_def.mof extensions does not have the
same issues. All SMS_def.mof extensions must be made on the server side, which requires
administrative privileges.
The Advanced Client inventory collection is done using all the rights of the local system account.
This includes the ability to collect copies of critical system files such as the registry or security
account database. When these files are available at the SMS site server, someone with the
necessary privileges could analyze their contents and possibly discern important details about the
client in order to be able to compromise its security. Therefore you should carefully control who
has the rights to enable the SMS file collection and to read collected files.
C H A P T E R 6

Understanding
Interoperability with
SMS 2.0
This chapter describes issues that are related to administering a mixed-version Microsoft®
Systems Management Server (SMS) hierarchy A mixed-version hierarchy contains both
SMS 2003 sites and SMS 2.0 sites with Service Pack 4 (SP4) or later. To continue supporting
client platforms that are not supported by SMS 2003, you can choose to upgrade only part of the
SMS 2.0 hierarchy to SMS 2003. This mixed-version hierarchy contains sites of both versions.
SMS 2003 supports interoperability with SMS 2.0 SP4 or later sites. Both versions can coexist
within a single hierarchy, but an SMS 2003 site cannot be a child to an SMS 2.0 site. SMS 1.2
sites are not supported in hierarchies that contain SMS 2003 sites.
For information about upgrade, see Chapter 11, “Planning an Upgrade,” and Chapter 14,
“Upgrading to SMS 2003.”

In This Chapter
u Administering a Mixed-Version Hierarchy
194 Chapter 6 Understanding Interoperability with SMS 2.0

Administering a Mixed-Version
Hierarchy
In a single-version hierarchy, you can centrally manage the entire hierarchy. However, with the
changes introduced in SMS 2003, some incompatibilities between the versions are unavoidable.
In a mixed-version hierarchy, you can continue to centrally manage the entire hierarchy, but
some issues exist.
In general, data flows across SMS versions and you can use an SMS 2003 Administrator console
to manage SMS 2.0 sites. However, some issues and limitations exist.

Note
You cannot use the SMS Administrator console from a specific SMS version
to administer a later version of SMS.

Data Flow
Data propagates between SMS 2.0 sites and SMS 2003 sites. You can use many SMS features
across versions, depending on how much the feature has changed in SMS 2003.
Data that propagates down from site to site in a single-version hierarchy will propagate across
versions. For example, packages and advertisements that propagate from a parent SMS 2003 site
to a child SMS 2003 site also propagates to a child SMS 2.0 site.
Data that propagates up from site to site in a single-version hierarchy also propagates across
versions, except for software metering data and inventory MIF files from 16-bit clients. MIF files
that are collected from SMS 2.0 16-bit clients are usually discarded when they reach an
SMS 2003 site in the hierarchy.

Note
Discarding MIF files from 16-bit clients usually depends on whether those
clients were assigned to the SMS 2.0 site before or after the SMS 2.0 site
became a child site to an SMS 2003 site. Also, if an SMS 2.0 site containing
SMS 1.2 client discovery or inventory data attaches to an SMS 2003 site,
those SMS 1.2 clients appear in the SMS 2003 site database. However,
advertisements from the SMS 2003 site to those SMS 1.2 clients are
ignored because SMS 2003 does not support interoperability between
SMS 2003 and SMS 1.2.
Administering a Mixed-Version Hierarchy 195

Sites running SMS 2.0 SP4 and earlier do not have the capability of signing data. Because of its
unsecured nature, you might want to prevent that data from propagating to SMS 2003 sites. You
can do that as follows:
To allow or to prevent unsigned data flow from sites running SMS 2.0 SP4 to SMS 2003 sites
1. In an SMS 2003 site, navigate to the <site> item in the SMS Administrator console.
Systems Management Server
Site Database
Site Hierarchy
<site code>-<site name>
2. Right-click the <site code>–<site name> item, and then select Properties.
3. In the <site code>–<site name> Properties dialog box, click the Advanced tab.
4. Select or clear the Do not accept unsigned data from sites running SMS 2.0 SP4 and
earlier check box to allow or to prevent unsigned data flow from SMS 2.0 SP4 and earlier
sites.
For more information about using this option, see Chapter 5, “Understanding SMS Security.”
Using the SMS 2003 Administrator Console in a Mixed-Version Hierarchy
When both SMS 2.0 sites and SMS 2003 sites exist in the same hierarchy, it is recommended that
you use the SMS 2003 Administrator console to administer both site types. When you select a
site in the SMS 2003 Administrator console, SMS performs version checking to identify which
features and properties to display, based on the version of the selected site. You can manage an
entire mixed-version hierarchy branch, or the entire hierarchy, from a single SMS Administrator
console.
The rest of this section describes issues related to using an SMS 2003 Administrator console to
administer an SMS 2.0 site.
Connecting to an SMS 2.0 site from an SMS 2003 Administrator console
You can use an SMS 2003 Administrator console to administer an SMS 2.0 site. The SMS 2003
Administrator console can be remote, or it can be running on a local SMS 2003 site server. By
using either a remote or a local SMS 2003 Administrator console, you can access an SMS 2.0 site
in either of the following two ways:
u Connecting to a parent SMS 2003 site, expand the Site Hierarchy item in the left pane, and
then selecting a child SMS 2.0 site
u Connecting directly to the SMS 2.0 site
To connect directly to an SMS 2.0 site by using an SMS 2003 Administrator console
1. Start the SMS 2003 Administrator console.
2. Right-click Systems Management Server in the left pane.
3. Select All Tasks, and then select Connect to Site Database.
Enter the information in the Database Connection Wizard for the SMS 2.0 site database.
196 Chapter 6 Understanding Interoperability with SMS 2.0

For information about supported platforms for a remote SMS Administrator console, see the
“Getting Started” chapter. For information about setting up a remote SMS Administrator console,
see the SMS Help.
Using an SMS 2003 Administrator console to administer an SMS 2.0 site
You can administer an SMS 2.0 site from an SMS 2003 Administrator console. By using this
configuration you can perform most of the operations that are possible when you use an SMS 2.0
Administrator console. The SMS 2003 Administrator console is different, as follows:
u The Software Metering Server site system role is not available.
u The following maintenance tasks are not available:
u Export Site Database
u Export Site Transaction Logs
u Export Software Metering Database
u Export Software Metering Transaction Log
u The software metering tool is not available.
u When you right-click an SMS 2.0 client in a collection, the Start Event to Trap Translator
option is not available.
u Hardware inventory data for 16-bit clients that are assigned to an SMS 2.0 site might not be
available.
u You cannot run the Repair Wizard by right-clicking <site code–site name> of an SMS 2.0
site, and then choosing All Tasks.
u You can use an SMS 2003 Administrator console to attach an SMS 2.0 site to a parent only
if you connect directly to the SMS 2.0 site.
u You can use an SMS 2003 Administrator console to uninstall an SMS 2.0 secondary site
only if you connect directly to the parent of that secondary site and if the secondary site
server is running a supported operating system from the Microsoft Windows® 2000 family
or later. If the secondary site server is running an earlier version of the operating system,
then you can uninstall the SMS 2.0 secondary site by running the Hierarchy Maintenance
Utility (PreInst.exe) with the /deinstall switch at the SMS 2003 site. For more information
about the Hierarchy Maintenance Utility, see Chapter 15, “Backup and Recovery,” in the
Microsoft Systems Management Server 2003 Operations Guide.
u You cannot use the SMS 2003 version of the Distribute Software Updates Wizard to manage
SMS 2.0 software update packages created by SMS Software Update Services Feature Pack
tools for SMS 2.0. For information about working around this, see the “Software Update
Management” section later in this chapter.
u You cannot access Help topics for unavailable items in the SMS Administrator console.
Interoperability of the SMS 2003 Administrator console with SMS 2.0 sites
The SMS 2003 Administrator console supports functionality that is new and changed since
SMS 2.0. Although they are not used in SMS 2003, some SMS 2.0 items remain to allow an
administrator to use an SMS 2003 Administrator console to manage an SMS 2.0 site.
Administering a Mixed-Version Hierarchy 197

The following items are in the SMS 2003 Administrator console only to support interoperability
with SMS 2.0:
u The Update database statistics option
This option is enabled only when you use an SMS 2003 Administrator console to connect to
an SMS 2.0 site.
To access the Update database statistics option
1. Navigate to Component Configuration in the SMS Administrator console.
Systems Management Server
Site Database
Site Hierarchy
<site code>-<site name>
Site Settings
Component Configuration
2. In the right pane, right-click Data Processing and Storage, and then select Properties.
The Data Processing and Storage Properties dialog box appears, which contains the
Update database statistics option.
u Platforms in the Supported Platforms list for software distribution that are not supported in
SMS 2003
You can advertise programs to SMS 2.0 clients that are running platforms which are no
longer supported in SMS 2003.
u Components in the Thresholds list that are not in SMS 2003
These components remain to support interoperability with SMS 2.0.
To access the status summarization thresholds list
1. Navigate to Status Summarizer in the SMS Administrator console:
Systems Management Server
Site Database
Site Hierarchy
<site code>-<site name>
Site Settings
Status Summarizer
2. In the right pane, right-click Component Status Summarizer.
3. Select Properties.
4. In the Component Status Summarizer Properties dialog box, click the Thresholds
tab.
u NetBIOS in the Default remote access protocol list
You see this list on the Advanced tab when you are configuring the Remote Tools Client
Agent. This item is available in the SMS 2003 Administrator console only when an SMS 2.0
site is being administered.
198 Chapter 6 Understanding Interoperability with SMS 2.0

Interoperability of SMS 2.0 Features with


SMS 2003 Features
In a mixed-version SMS hierarchy, SMS 2003 features interoperate with the corresponding
SMS 2.0 features. However, because most features have changed in SMS 2003, some
interoperability issues exist. The rest of this topic describes the interoperability issues of each
SMS feature, in a mixed-version hierarchy.
For more information about specific features, see the respective feature chapter in the Microsoft
Systems Management Server 2003 Operations Guide.

Client Discovery and Installation


u SMS 2003 sites cannot use SMS 2.0 logon points.
u Server locator points are not supported in SMS 2.0 sites. In a mixed-version hierarchy,
where SMS 2.0 and SMS 2003 sites both reside in the same domain, SMS 2.0 sites can
continue to use their logon points. However, instead, they can use server locator points set
up in SMS 2003 sites to eliminate the need for logon points in the SMS 2.0 sites.
You can configure the SMS 2003 site to use the Logon Script-initiated Client Installation
method, and configure the SMS 2.0 site to run Capinst.exe from the SMS 2003 site. The
logon scripts for the domain can contain a Capinst.exe command to install a Legacy Client
or an Advanced Client. The logon script can also contain the /AutoDetect switch with a
batch file or script that always returns 1, to install a client depending on which platform the
computer is running.
u CAPINST /SLP=Servername -to install a Legacy Client
u CAPINST /ADVCLI /SLP=Servername -to install an Advanced Client
u CAPINST /autodetect=<batch file or script> /SLP=Servername - platform dependent
client installation. <batch file or script> - a batch file or a script which always returns 1,
for example, Wscript.Quit(1).
In this environment, SMS determines which client type to install as follows:
u For the computers that reside exclusively in an SMS 2003 site boundaries, SMS installs
the same client type as it would in an SMS 2003 environment that does not contain
mixed versions of SMS.
Table 6.1 Determining Client Type to Install Within SMS 2003 Site Boundaries
Windows NT 4.0
Logon script Service Pack 6 Windows 2000
command Windows 95 Windows 98 or later and later
Legacy Clients None SMS 2003 SMS 2003 SMS 2003
Legacy Client Legacy Client Legacy Client

(continued)
Administering a Mixed-Version Hierarchy 199

Table 6.1 Determining Client Type to Install Within SMS 2003 Site Boundaries
(continued)
Windows NT 4.0
Logon script Service Pack 6 Windows 2000
command Windows 95 Windows 98 or later and later
Advanced None None None SMS 2003
Clients Advanced Client
Platform None SMS 2003 SMS 2003 SMS 2003
Dependent Legacy Client Legacy Client Advanced Client

SMS does not install any client on computers running Microsoft Windows NT® 4.0 SP5 or
earlier, which reside exclusively within SMS 2003 site boundaries because they are not
supported by SMS 2003.
u For the computers that reside exclusively in an SMS 2.0 site boundaries. SMS installs
the SMS 2.0 client.
u For the computers that reside in the overlapping boundaries of SMS 2.0 and SMS 2003,
SMS determines which client type to install according to the logon script client
installation command and the computer’s operating system.
Table 6.2 Determining Client Type to Install Within Overlapping Site Boundaries
Windows NT Windows NT
4.0 Service 4.0 Service
Logon script Pack 6 and Pack 5 and Windows 2000
command Windows 95 Windows 98 later earlier and later
Legacy SMS 2.0 SMS 2003 SMS 2003 SMS 2.0 SMS 2003
Clients client Legacy Client Legacy Client Client Legacy Client
Advanced SMS 2.0 SMS 2.0 SMS 2.0 None SMS 2003
Clients client Client Client Advanced Client
Platform SMS 2.0 SMS 2003 SMS 2003 SMS 2.0 SMS 2003
Dependent client Legacy Client Legacy Client Client Advanced Client

Note
If lower level SMS 2.0 sites are configured by using IPX boundaries, you
cannot use SMS 2003 logon installation to install clients in those sites. You
must continue to use SMS 2.0 client installation methods.

u You can copy Capinst.exe from an SMS 2003 site to an SMS 2.0 site. SMS 2.0 clients then
run the SMS 2003 Capinst.exe, which eliminates the need for logon points in the SMS 2.0
site.
200 Chapter 6 Understanding Interoperability with SMS 2.0

u SMS 2.0 clients upgrade to SMS 2003, and they are assigned to the current site if, when you
use the Client Push Installation Wizard, you do the following:
u In an SMS Administrator console in an SMS 2003 site, you select a collection, which
contains SMS 2.0 clients that are assigned to child sites, and then you start the Client
Push Installation Wizard for that collection.
u On the Installation options page, you select Advanced Client or Legacy Client, as
appropriate.
u On the Client Installation Options page, when installing Advanced Clients, you do not
select the Include only clients assigned to this site option or the Always install
(repair or upgrade existing client) option.
u On the Client Installation Options page, when installing Legacy Clients, you select the
Always install (repair or upgrade existing client) option.
Collections and Queries
Collections that are defined in SMS 2003 sites propagate down to SMS 2.0 sites in the same
manner that they propagate down to lower level SMS 2003 sites. However, the following
interoperability issues exist with collections and queries in a mixed-version hierarchy:
u Queries that run against SMS 2.0 classes that do not exist in SMS 2003 return only the
classes that exist in SMS 2003.
u Collections or queries cannot be imported from sites running one version of SMS and then
be imported into sites running another version of SMS.
u An SMS 2003 collection that contains a carriage return in its comment might be incorrectly
replicated to SMS 2.0 sites. When you are viewing this collection in an SMS 2.0 site, a
“##SMSCD##” string might be displayed instead of a carriage return.
u An SMS 2003 collection containing a rule with any clause that does not apply in SMS 2.0 is
successfully replicated to the SMS 2.0 sites. However, that entire rule is not included in the
replicated collection. For example, rules containing any of the following clauses, are entirely
removed:
u A clause that references a property that does not exist in SMS 2.0, such as
SystemResource - ClientType.
u A clause that references Active Directory® organizational units or any other Active
Directory objects.
u When you use a remote SMS 2003 Administrator console to connect directly to an SMS 2.0
site database, membership rules are not retained when you import a collection. After running
the Import Object Wizard to import a collection, you must manually add any membership
rules that are part of that collection.
Administering a Mixed-Version Hierarchy 201

Hardware Inventory
Hardware inventory data that is collected from clients running SMS 2.0 is propagated up to
SMS 2003 upper level sites in the same manner that it is propagated to SMS 2.0 upper level sites.
You can use the SMS 2003 Administrator console to perform operations that require hardware
inventory data on SMS 2.0 clients.
In a mixed-version hierarchy, it is recommended that all sites use a standardized SMS_def.mof
file. Differences between the SMS_def.mof files at different sites in the hierarchy can result in
having conflicting hardware inventory data. This is especially true in a mixed-version hierarchy
because different versions of WMI (the Microsoft implementation of Web-based Enterprise
Management) are used in SMS 2.0 and in SMS 2003. Having conflicting hardware inventory
data in the SMS site database results in having multiple tables for the same class. Because reports
retrieve data for a class from only one class, this can result in reports displaying incorrect
information. You can prevent those conflicts, by ensuring that all sites in the hierarchy, including
SMS 2.0 and SMS 2003 sites, use the same hardware inventory definitions.
To standardize the SMS_def.mof files in your hierarchy
1. Compare the SMS_def.mof file that SMS 2003 sites are using with the SMS_def.mof files
that SMS 2.0 sites are using.
2. Determine whether there are hardware inventory extensions that you want to use and which
do not already exist in the SMS 2003 SMS_def.mof. Update the SMS 2003 SMS_def.mof as
follows:
u If you have extended the SMS 2.0 SMS_def.mof file with extensions that are in the
SMS 2003 SMS_def.mof file, use the extensions from the SMS 2003 site instead of the
extensions from the SMS 2.0 site.
u If you have hardware inventory extensions in the SMS 2.0 SMS_def.mof file that you
want to use, and those extensions are not in the SMS 2003 SMS_def.mof file, then add
those extensions to the SMS 2003 SMS_def.mof file.
3. Use the extended SMS 2003 SMS_def.mof file throughout your mixed-version hierarchy.

Note
Before turning off collection of hardware inventory classes or properties in
the SMS_def.mof file, ensure that those classes or properties are not used
by any queries or reports that you plan to use.
202 Chapter 6 Understanding Interoperability with SMS 2.0

Whether the SMS_def.mof is standard throughout the hierarchy, the following interoperability
issues exist with hardware inventory in a mixed-version hierarchy:
u Hardware inventory data for 16-bit clients assigned to an SMS 2.0 site might not be
available.
u The changes to SMS_def.mof file in SMS 2003, and in the various SMS 2.0 service packs,
might not be compatible with each other. You cannot copy a modified SMS_def.mof file to
an SMS site running an SMS version or service pack that differs from the original site’s
version or service pack. To use a modified SMS_def.mof file in another site, you must
manually modify the SMS_def.mof file.
For example, WMI View Provider classes, that in SMS 2.0 were registered in the WMI
CIMv2\SMS namespace, are registered in the WMI CIMv2 namespace in SMS 2003.
u In a mixed-version hierarchy, in which SMS 2.0 and SMS 2003 sites use a standardized
SMS_def.mof file, you should not enable a property in the SMS_def.mof file with the
DecimalString qualifier. This can cause a decimal overflow error and cause the inventory
from the SMS 2.0 clients to be discarded.
Software Inventory
Software inventory data collected from clients that are running SMS 2.0 is propagated to
SMS 2003 upper level sites in the same manner that it is propagated to SMS 2.0 upper level sites.
You can use the SMS 2003 Administrator console to perform operations that require software
inventory data on SMS 2.0 clients.
The following interoperability issues exist with software inventory in a mixed-version hierarchy:
u Software inventory data for 16-bit clients assigned to an SMS 2.0 site might not be available.
u Software inventory data from SMS 2.0 clients includes details about file creation dates. This
information is discarded when it arrives at SMS 2003 sites, and therefore is not displayed in
SMS 2003 sites.
u Software inventory data from SMS 2.0 clients does not contain full paths. Therefore, when
you are browsing software inventory data in an SMS 2003 Administrator console, full paths
are displayed only for SMS 2003 clients.
Software Distribution
By using an SMS 2003 Administrator console, you can create and advertise programs to SMS 2.0
sites in the same manner that you do for SMS 2003 sites. Software distribution status messages,
that SMS 2.0 clients generate, propagate up to SMS 2003 upper level sites in the same manner
that they propagate to SMS 2.0 upper level sites. However, the following interoperability issues
exist with software distribution in a mixed-version hierarchy:
u SMS 2.0 16-bit clients, that are identified by user accounts or user groups in collections, do
not receive programs sent to them by using the software distribution feature from SMS 2003
sites. Only 32-bit clients can receive software distribution programs that are based on user
accounts or user groups.
u Settings on the Advanced Client tab and the Suppress program notifications check box
are ignored when the program reaches SMS 2.0 sites.
Administering a Mixed-Version Hierarchy 203

u In SMS 2003 sites, the Supported Platforms list includes platforms that are not supported
in SMS 2003. They are included to support advertising to SMS 2.0 sites.
u Advanced Clients can download package source files from SMS 2.0 distribution points. This
is supported only for Advanced Clients that roam to the site’s immediate SMS 2.0 child
secondary site.
u When you configure a package with the Courier Sender as the preferred sender in an
SMS 2003 site, SMS 2.0 sites cannot receive this package unless they run the SMS 2003
Courier Sender Manager.
To run the SMS 2003 Courier Sender Manager in an SMS 2.0 site
1. Copy the SMS/bin/i386/coursend.exe file from an SMS 2003 site to the SMS/bin/i386/
folder in the SMS 2.0 site.

Caution
Rename the file so that it does not overwrite the Coursend.exe file in the
SMS 2.0 site.

2. Run the executable file.


3. Configure the Courier Sender in the same manner as you would configure it by using an
SMS 2.0 Courier Sender Manager.
Software Update Management
You can use the SMS 2003 software update management feature to manage software updates in
SMS 2.0 sites in the same manner that you manage updates in SMS 2003 sites. However, you
might encounter several issues when you are using the software update management feature in a
mixed-version hierarchy.
In a mixed-version hierarchy, the SMS Software Update Services Feature Pack tools for SMS 2.0
might or might not have been installed in SMS 2.0 sites. Whether the feature pack is installed in
the SMS 2.0 sites or not, it is recommended that you always use the SMS 2003 software update
management feature to manage software updates for both the SMS 2003 and the SMS 2.0 sites.
The following interoperability issues exist with software update management in a mixed-version
hierarchy:
u The SMS 2003 Distribute Software Update Wizard does not operate correctly in SMS 2.0
sites. This is because SMS 2.0 site servers are missing specific folders and files that the
wizard requires to create packages. This issue applies to SMS 2.0 sites regardless of the
Software Update Services Feature Pack being installed or not.
You can resolve this issue by performing the following steps.
To allow the SMS 2003 Distribute Software Update Wizard to operate correctly in SMS 2.0
sites
1. Create a new shared folder on the SMS 2.0 site server named SMS_SUIAgent.
2. Grant Read, Read and execute, and List folder contents file rights on the shared
folders to the SMS Admins security group.
204 Chapter 6 Understanding Interoperability with SMS 2.0

3. Copy all files and folders from the SMS 2003 site server SMS_SUIAgent folder to the
newly created folder on the SMS 2.0 site server.

Note
Whenever you apply upgrades to the SMS 2003 site, such as a new
International Client Pack (ICP) or a Service Pack, you must repeat the above
copy procedure.

The following issues apply in a mixed-version hierarchy where the SMS 2.0 SUS Feature Pack
tools are installed:
u In an SMS 2.0 site, packages created with the SMS 2.0 version of the Feature Pack tools
might not behave correctly after an SMS 2003 site starts to distribute software update
packages to the SMS 2.0 site. To resolve this issue, you must do one of the following:
u In the SMS 2.0 site, remove all software update packages that were created by the
Distribute Software Updates Wizard in the SMS 2.0 site.
u Upgrade the SMS 2.0 site to SMS 2003.
u Upgrade the SMS 2.0 software update packages to SMS 2003 software update packages
(see next procedure.)
u You can upgrade SMS 2.0 software update packages to SMS 2003 software update packages
by opening and then saving those packages in the SMS 2003 Distribute Software Updates
Wizard. Use the following procedure for each package that you want to upgrade.
To upgrade an SMS 2.0 software update package to SMS 2003
1. Use the SMS 2003 SMS Administrator console to connect to the SMS 2.0 site. Right-
click Collections or Packages, select All Tasks, and then select Distribute Software
Updates.
2. On the Specify a Software Update Type page, select the type of software update for
the package you are upgrading.
3. On the Create an Update Package page, select the name of the package you are
upgrading, and then click Next.
4. If you are making no other changes to the package, go through the rest of the wizard by
clicking Next, and then Finish.
The wizard copies SMS 2003 Software Update Management client component files to the
SMS 2.0 package source folder and updates distribution points accordingly.
Although the SMS 2003 version of the Distribute Software Updates Wizard has features that
do not exist in the SMS 2.0 version of the wizard, the upgraded package is configured with
the existing SMS 2.0 Feature Pack settings until you modify them.
u Software update related status messages have changed slightly between SMS 2.0 and
SMS 2003. Review any custom queries or collections to ensure that they reference the
correct status message text of SMS 2003.
Administering a Mixed-Version Hierarchy 205

u Some new SMS 2003 Software Update Management settings, such as persistent notification
icons, and the scheduled installation option are ignored when programs are advertised to
SMS 2.0 clients.
u If an SMS 2.0 site is using the Software Update Services Feature Pack tools for SMS 2.0,
then ensure that advertisements for software updates from the SMS 2.0 site, and from an
upper level SMS 2003 site do not overlap. Ensure that the SMS 2.0 site and the SMS 2003
site do not advertise duplicate software updates or duplicate inventory tool updates to clients.
Remote Tools
Discovery data from SMS 2.0 clients propagates to SMS 2003 sites. You can use Remote Tools
on an SMS 2003 Administrator console to access SMS 2.0 clients. However, the following
interoperability issues exist with remote tools in a mixed-version hierarchy:
u You might not be able to run Remote Tools for 16-bit clients because discovery data for
those clients might not exist in the SMS 2003 database.
u Although SMS 2003 clients no longer support IPX and NetBIOS Remote Control
communication, the SMS 2003 Remote Tools console still makes requests by using these
protocols. You can use an SMS 2003 Administrator console to control SMS 2.0 clients,
which are configured to listen for Remote Tools requests on IPX or NetBIOS addresses.
u Some of the Remote Tools settings on an SMS 2.0 client might not be compatible with the
Remote Tools settings of the client’s site. This can happen in the next interoperability
scenario:
u An SMS 2.0 client is assigned to multiple SMS 2.0 sites.
u One or more of the sites that the client is assigned to are upgraded to SMS 2003, but
SMS 2003 does not support the client’s platform, and therefore the client remains
assigned to the SMS 2.0 sites that were not upgraded to SMS 2003.
Remote Tools on this client might have settings from the sites that were upgraded, even
though the client is not assigned to those sites.

Reporting
Because client data from SMS 2.0 sites propagates to SMS 2003 sites, reports that you run in
SMS 2003 sites include data from SMS 2.0 sites that was propagated to the SMS 2003 site
database.
You can continue to use a stand-alone version of SMS 2.0 Crystal Reports to view SMS 2.0
reports. However, the following interoperability issues exist with Reporting in a mixed-version
hierarchy:
u You cannot use SMS 2003 Report Viewer to view reports that are created by Crystal Reports
in SMS 2.0 sites.
u You cannot export reports from sites running one version of SMS and then import them into
sites that are running a different version of SMS.
206 Chapter 6 Understanding Interoperability with SMS 2.0

u You cannot use the SMS 2003 Report Viewer to access an SMS 2.0 site database.
u In SMS 2003, discovery methods report the client’s types — Advanced Client or Legacy
Client. SMS 2.0 discovery methods do not report the client’s types. Therefore, when an
SMS 2003 Web report is displayed that includes a Client Type column, this column is left
blank for SMS 2.0 clients.
Software Metering
SMS 2003 software metering does not interoperate with SMS 2.0 software metering. Software
metering rules from SMS 2003 sites do not propagate to SMS 2.0 sites, and software metering
data from SMS 2.0 sites does not propagate to SMS 2003 sites. For more information about
software metering in a mixed-version hierarchy, see Chapter 8, “Software Metering,” in the
Microsoft Systems Management Server 2003 Operations Guide.

Product Compliance
Product compliance functionality has not changed in SMS 2003. You can export product
compliance data from an SMS 2.0 site to a product compliance data file. You can then import
that file, or any other valid product compliance data file, into an SMS 2003 site. If you had any
queries that ran against product compliance data, you must recreate those queries in SMS 2003.
Backup and Recovery
The backup operation is isolated to single sites, and therefore there are no interoperability issues.
The backup task in SMS 2003 sites works differently than it does in SMS 2.0 sites. You cannot
use the default backup control file, SMSbkup.ctl, from one SMS version to back up an SMS site
of a different version. You cannot recover an SMS 2.0 site to an SMS 2003 site.
The recovery operation is also isolated to single sites. But in a mixed-version hierarchy, you can
use some of the recovery tools that are integrated into SMS 2003 to recover SMS 2.0 sites. When
you recover sites in a mixed-version hierarchy, you can use recovery tools as follows:
u You can use the SMS 2003 Recovery Expert to recover either an SMS 2.0 site or an
SMS 2003 site. The Recovery Expert asks about the SMS version and generates the recovery
task list according to your answer.
u You can use the SMS 2003 Site Repair Wizard to repair either an SMS 2.0 site or an
SMS 2003 site. However, to repair an SMS 2.0 site, you must run the wizard in the SMS 2.0
site that you are repairing. If you run the wizard remotely, the wizard uses files from the
local server and attempts to run them on the recovering server which is running SMS 2.0.
u When you recover an SMS 2.0 site, you must download the recovery command-line tools
from the SMS Maintenance and Recovery Web site at
http://www.microsoft.com/smserver/techinfo/administration/20/recovery. Preinst.exe is also
available on the SMS 2.0 SP5 CD, under the \SMSSETUP\BIN\I386 and the
\SMSSETUP\BIN\ALPHA folders.
Administering a Mixed-Version Hierarchy 207

u When you use the Repair Wizard to recover an SMS 2003 site, you can designate SMS 2.0
sites as reference sites.
However, in such a recovery scenario, the wizard does not correctly recover a collection if
all of the following apply:
u The collection contains a rule in which Limit to collection is set.
u The collection is not included in the site backup snapshot that is used to recover the site,
and the wizard recovers the collection from an SMS 2.0 reference site.
The recovered collection will contain the respective rule, but the Limit to collection will not
be set. You can correct this by modifying the rule, and selecting Limit to collection. If you
do not correct the collection definition, it might contain additional members that the original
collection did not contain. Software distribution programs advertised to that collection will
then reach those additional members.
P A R T 3

Planning

This part of the Microsoft® Systems Management Server 2003 Concepts, Planning, and
Deployment Guide provides information that helps you determine your general and specific
project objectives, document your current computing environment, and implement project
management techniques that you can use during your Systems Management Server 2003
implementation.
C H A P T E R 7

The Pre-Planning Phase

The first six chapters of this book describe the concepts and functionality of Microsoft® Systems
Management Server (SMS) 2003. This chapter describes a methodology you can use to plan and
deploy SMS 2003. It also outlines the steps to perform before embarking on the planning
process, which is described throughout the “Planning” part of this book.
In an SMS deployment, most of your time is spent planning the implementation, instead of
installing the SMS software product. SMS is an enterprise application. For a successful SMS
deployment, you must gather a significant amount of data to drive your early planning decisions.
This chapter helps you understand the planning process, and begin that process by gathering
necessary data. Chapters 8–13 guide you in planning your SMS design and your deployment and
configuration. Strategies for later implementing your design and deployment plans are described
in Chapters 14–17.
In This Chapter
u Step 1 Understand the Methodology and the Risks
u Step 2 Analyze Your Environment
u Step 3 Analyze Your Needs
u Step 4 Assemble the Team
u Step 5 Begin Assembling the Project Plan
u Step 6 Learn SMS
u Step 7 Establish Test Lab Environment
212 Chapter 7 The Pre-Planning Phase

Who Should Read This Chapter


By now you have already assigned the roles of SMS project sponsor and project manager for
your SMS 2003 implementation project. This chapter is designed to provide the project sponsor
the means to identify the project objectives, and to provide the project manager with the
necessary guidelines to conduct the planning process.
It is the project sponsor’s role to prioritize feature identification, develop the organization’s
requirements case, promote the shared product vision, and manage both customer expectations
and the customer interaction process.
The project manager has many roles. Depending on the size of your organization, you might
assign more than one project manager to your SMS project. The roles of the project manager
include defining the goals and scope of the project, assembling the team, managing the project
and maintaining communications. The project manager is also responsible for developing the
budget and procuring the equipment.
For more information about SMS team member roles, see the SMS occupation taxonomy in
Table 7.10.
Step 1 Understand the Methodology and the Risks 213

Step 1 Understand the Methodology


and the Risks
Successful implementation of SMS requires detailed planning. It is important that you understand
the planning process. A planning methodology is described in this chapter and is used throughout
this book. With a properly prepared project plan, your SMS deployment can be as simple as
carrying out your plan. For this reason, appropriate resources must be allocated to the planning
phase. You must thoroughly research, document, and test your project plan before deploying
SMS.
Proper planning can help ensure the greatest return on your investment. Implementation of
management solutions, such as SMS 2003, must not be rushed. The pressure to deliver quick
results can make the temptation to run Setup.exe irresistible. This approach might be acceptable
in a limited number of organizations, such as small, single-site environments with few users and
a need only to report inventory. However, as your systems population grows larger, the quick
deployment is risky and becomes difficult to manage. Administrators are then forced to patch
their management solutions, and possibly spend large amounts of time re-engineering.
Implementation without planning can cause inherent design problems, which can lead to costly
downtime and user perception issues regarding the reliability of the system. Also, without proper
planning, the inventory results that your organization uses for budgetary and financial decisions
might not be valid. See the “Risk Management” section later in this chapter for a list of avoidable
risks such as this one.

The Methodology
The planning and deployment process consists of three phases:
Pre-planning This phase involves examining and documenting your current computing
environment, determining your business and technical objectives, understanding risk, assembling
project plan documentation, learning SMS, and building your test lab in preparation for the pilot
project.
Planning In this phase, you fill in your project plan documents with details for your SMS
hierarchy design, pilot project, SMS deployment, how you will use SMS features, and planning
security and recovery. As you perform these steps, test configuration variations and deployment
scenarios in your lab environment.
Deployment In this phase, you continue lab testing, perform a pilot deployment, validate the
design, deploy your SMS sites, configure security and site settings for SMS, build your SMS
hierarchy, and deploy the SMS client software in phases.
214 Chapter 7 The Pre-Planning Phase

Table 7.1 illustrates this methodology. See Chapter 11, “Planning an Upgrade,” if you are
upgrading to SMS 2003.

Note
The post-deployment maintenance and operations phase is detailed in the
Microsoft Systems Management Server 2003 Operations Guide.

Table 7.1 Planning and Deployment Methodology for a New SMS 2003 Implementation
Chapter of Microsoft Systems
Management Server 2003
Concepts, Planning, and
Phase Steps Deployment Guide
Pre-planning 1. Understand the methodology and the Chapter 7, “The Pre-Planning
risks. Phase”
2. Analyze and document current
computing environment.
3. Analyze your organization’s needs and
identify objectives.
4. Assemble the team.
5. Begin assembling the project plan.
6. Learn SMS.
7. Establish test lab environment.
Planning 8. Complete the project plan, performing Chapter 8, “Designing Your SMS
lab testing as you proceed with each Sites and Hierarchy”
step:
u Design the SMS hierarchy.
Chapter 9, “Capacity Planning for
u Plan the deployment and site SMS Component Servers”
configuration and conduct a pilot
project. Chapter 10, “Planning Your SMS
Deployment and Configuration”
Chapter 12, “Planning Your SMS
u Plan your security strategy.
Security Strategy”
Chapter 13, “Planning for Backup
u Plan for SMS site recovery.
and Recovery”
Deployment Chapter 15, “Deploying and
9. Deploy the SMS hierarchy. Configuring SMS Sites”
10. Deploy SMS clients. Chapter 17, “Discovering
Resources and Deploying Clients”
Step 1 Understand the Methodology and the Risks 215

The pre-planning, planning, and deployment phases are iterative processes. For example, you
might complete a pre-planning step, such as building your test lab, and later revisit that step to
revise your lab hierarchy when your planning work reveals that a hierarchy adjustment is
required.
As you progress through the planning phase, you continue to perform risk assessments, evaluate
staffing allocations, monitor your timeline, budget and expenditures, perform various tests in
your lab environment, and make modifications to the plan that you are designing. Continue to do
these same assessments, evaluations, and tests in the lab while performing a phased deployment
of SMS in your production environment.
There are two frameworks that can provide you with additional information:
u Microsoft Operations Framework
u Microsoft Solutions Framework
Microsoft Operations Framework
Microsoft Operations Framework can provide you with additional information about successful
planning and delivery of enterprise solutions. Microsoft Operations Framework provides a
collection of best practices, principles, and models in delivering enterprise solutions such as
SMS. It provides comprehensive technical guidance for achieving mission-critical production
system reliability, availability, supportability, and manageability of solutions. Microsoft
Operations Framework provides an in-depth supplement to the guidelines presented in this book.
For more information about the Microsoft Operations Framework process, teams, and risk
models, see the Microsoft Operations Framework Web site at
http://www.microsoft.com/business/services/mcsmof.asp.
Microsoft Solutions Framework and SMS
The cycle of planning, testing, deploying, and maintaining SMS is the same as for any major
infrastructure product. It should follow an established and tested framework, such as Microsoft
Solutions Framework, which is the basis of the planning and installation methodology used in
this book.
Microsoft Solutions Framework describes in detail all the steps in the process of planning and
building an enterprise solution. It also describes individual roles and responsibilities at each
phase of implementation.
Microsoft Solutions Framework provides specific guidance for successful application and
infrastructure projects. In addition to the technology choices, Microsoft Solutions Framework
emphasizes the people and process elements of the project. The framework includes principles,
models, and best practices that help project teams address the most common causes of project
failure.
To learn more about Microsoft Solutions Framework, see the Microsoft Solutions Framework
Web site at
http://www.microsoft.com/business/services/mcsmsf.asp.
216 Chapter 7 The Pre-Planning Phase

Risk Management
In rushing to take advantage of SMS features, organizations might overlook the risks involved in
running a technically complex implementation project that touches nearly every component of
your infrastructure.
You must actively manage any risk. To manage risks effectively, identify the risks, and then
design contingency plans for dealing with those risks.
Also, it is important to perform a risk assessment and to re-evaluate your risk management plan
after you complete each phase of the project.
Risk Analysis
To conduct a comprehensive risk analysis, use a system such as Microsoft Readiness Framework,
available through Microsoft Consulting Services.
Microsoft Readiness Framework is a guide created and used by Microsoft partners to provide an
approach for organizations in preparing their people and processes for technology adoption. The
Microsoft Readiness Framework risk model helps you manage risks that are specific to
technology readiness efforts and projects that prepare an organization to fully adopt new
technology, and to realize the business benefits driven by this change.
For more information, see the Microsoft Risk Management Model technical paper at
http://www.microsoft.com/trainingandservices/default.asp.

Avoiding Risks
The best way to avoid risks is to plan your SMS implementation carefully. For example, using
the default settings provided by Express Setup to install SMS presents considerable risks to your
computing environment. The default settings cannot guarantee a successful deployment for every
organization. Properly planning configuration settings before deploying SMS in your production
environment is the preferred method of performing an SMS installation.
Table 7.2 outlines some potential risks that you should be aware of before completing your
project plan.
Table 7.2 Risk Avoidance and Best Practices
Action Risk Best practice
Deploying SMS without planning Hindered network infrastructure Create a project plan and follow
stability, reduction in available the planning and installation
bandwidth, reduced performance guidelines in this book or in the
due to improper server sizing, Microsoft Solutions Framework
and the potential for SMS to documentation.
collect data that is not valid

(continued)
Step 1 Understand the Methodology and the Risks 217

Table 7.2 Risk Avoidance and Best Practices (continued)


Action Risk Best practice
For large- and medium-sized Network infrastructure instability, Use Custom Setup unless you are
organizations, using the Express performance issues, and evaluating SMS within a lab
Setup feature to install an SMS productivity interruptions due to environment that is physically
site server without planning or a reduction in available network isolated from your production
considering the customizable bandwidth environment.
SMS and Microsoft SQL Server™
settings
Not testing in a lab environment Interoperability problems and Thoroughly test your SMS
before deployment reduced ability to: deployment, run a pilot project,
Provide support staff with and document your results
needed skills and before deploying any SMS
experience component on your production
network.
Eliminate the costs
associated with incorrect
design, which could lead to
a costly redeployment
No use of change control or Inability to troubleshoot system Develop a formal change
change management failure if changes to system are management process and
not tracked tracking system to ensure that
changes are made only where
necessary to fulfill objectives,
and that all implications and
risks are understood in advance.
Not planning for recovery SMS data loss and complex Plan for recovery as you plan your
recovery process deployment, not after you have
already deployed SMS.
Not understanding and planning Security breaches — Plan for security early, so that
for SMS security policies unauthorized access of client you can ensure the security of
computers or malicious your computing environment.
destruction of client computers
Not planning for training and Improper installation and use of As you assign roles to your SMS
education SMS, failure to meet project staff and trainers, ensure
requirements, and poor support that these individuals are trained
for end users, all of which can in the areas of expertise needed
result in forming a negative for planning, installing,
reputation for SMS in the supporting, and maintaining
organization SMS.
Not planning and carrying out a Insufficient support from Plan a schedule for informing the
good communications strategy management, colleagues, end SMS team and all other groups
users, or other groups in the of planning and deployment
organization progress.
218 Chapter 7 The Pre-Planning Phase

Change Control and Change Management


Most of your significant project design changes are likely to occur as the result of testing. In the
pre-planning phase, begin thinking about how you want to control and manage change
throughout the planning and deployment phases of the project.
Change control requires tracking and reviewing changes to your implementation plan made
during testing cycles and after deployment. Change management requires testing potential
system changes in a lab environment before implementing them in your production environment.
By identifying all affected systems and processes before a change is implemented, you can
mitigate or eliminate potential adverse effects.
The Microsoft Operations Framework provides best practices in change, configuration, and
problem management. This information is available at:
http://www.microsoft.com/business/services/practiceservice.asp.

Note
You can further reduce the potential for unfavorable implementation results
by carefully planning for backup and recovery, and testing your plan for
backup and recovery. For more information, see Chapter 13, “Planning for
Backup and Recovery.”

Step 2 Analyze Your Environment


A thorough understanding of your computing environment helps you determine the scope of your
SMS implementation project. Having accurate information about your physical network
infrastructure and the issues that influence your network operations is critical to many of the
decisions you make as you plan your SMS deployment.
For example, the locations, types, and number of SMS site servers deployed are greatly
influenced by network topology.
Detailed documentation of your computing environment is essential to an optimal SMS design.
Diagrams are a useful way to deal with complex concepts, such as network topology. Where
appropriate, create these diagrams and include them in
If You Do Not Have This Data your project plan documentation.
If this is your first implementation of
SMS, and some of this environment
Start by collecting and collating the data described in
data is information that you plan to this section. See Table 7.3 for an overview of the type
collect using the discovery and of data you can collect. As you examine your
inventory features of SMS 2003, environment, review how SMS integrates into existing
then collect as much data about operational processes and the effect it will have on
your environment as you can existing operational roles and responsibilities. Also, be
during the pre-planning phase. This sure to anticipate and track proposed infrastructure
helps you to determine your
objectives when you proceed to the
changes.
“Analyze Your Needs” section later
in this chapter.
Step 2 Analyze Your Environment 219

Table 7.3 Collecting Computing Environment Data


Environment Data needed
Previous installations The history of your organization’s systems
management solutions
Geographic profile Diagram of the geographic locations of your
organization’s sites, including information about
international operating system languages and time
zones
Organizational structure Diagram of the divisions or departments within
your organization and their associated managing
and reporting structures
Network topology Diagram of your network infrastructure, including
LAN and WAN architecture, physical topology,
network size, bandwidth, usage, traffic patterns,
network protocols, and subnets
Client environment The number of clients at each location, software
applications and operating systems in use
(including logon scripts, if applicable), client
mobility and type of network connectivity (dial-up,
wireless, LAN-connected)
Active Directory® site structure Diagram of the forest, domains, and
Active Directory sites in your Active Directory site
structure, if applicable, and organizational unit
information for later use in SMS operations
Domain models Diagram of your organization’s Microsoft
Windows NT® and Windows® 2000 domain
models and trust relationships
Server environment Diagram of the locations of the core servers on your
network, indicating their primary functionality and
operating system version level (domain controllers,
servers running Terminal Services, file servers, Web
servers, DHCP, WINS, and DNS servers)
Security Documentation containing your security settings,
including Windows security groups, Administrator
and Domain Administrator accounts, client
lockdown levels, shared folder access restriction
policy, account policies, account control needs,
and sensitivity to security risks
Information Technology (IT) organization Knowledge of your IT organization, the support
areas defined for IT staff members, what the
management control policies are and any policies
that play a part in the success of the organization’s
infrastructure projects
220 Chapter 7 The Pre-Planning Phase

As you collect this information, document it in diagrams, charts, and tables that can later be
inserted into the project plan. If possible, create your network and organization diagrams using an
overlay fashion. For example, create a domain model diagram using clear media, such as
transparency paper, that can overlay a printed diagram of your network topology.

Note
Because your SMS site structure can be based on both IP subnets and
Active Directory sites, pay particular attention to the location and clustering
of IP subnets and Active Directory sites.

Previous Installations
It is useful to investigate your organization’s history of systems management solutions and
determine if any method was used in the past or is currently in use. Evaluate the success or
failure of past projects, making note of any mistakes made and ways of avoiding the same
mistakes in the future. Determine if there are previous successful project plans to assist you in
planning your SMS 2003 implementation.
Also, document how you logically view and manage your current computing environment. For
example:
u Do you manage inventory centrally or locally? Do you manage it by organization or by
physical location? You must know this information to design your SMS hierarchy. This is a
good time to evaluate your organization’s current systems management guidelines and make
decisions about changing appropriate aspects of it with your SMS implementation.
u How do you decide what software can be used, when it can be used, how it is distributed to
end users, and how often? Knowing how your organization distributes and monitors software
usage helps you in configuring these features in SMS later.
u How do you support users when they have computer problems? What remote control tool
does your IT department use, if any? It is important to know if you have a remote control
solution in place already because you must determine whether it is compatible with the SMS
remote control agent or not. If not, you must remove the incompatible remote tool before
enabling SMS Remote Tools on your SMS clients.
It is important to check for previous installations of SMS 1.2 or SMS 2.0 so that you can plan for
interoperability issues and upgrade procedures. If you find that a previous version of SMS was
installed and later removed, consider removing all SMS components from client computers and
servers before installing SMS 2003. If you are planning a phased deployment of SMS 2003 that
coexists with another management solution, check both the vendor’s support documentation and
the Microsoft Knowledgebase for any known interoperability issues.
If you are currently using SMS, and you plan to upgrade to SMS 2003, see Chapter 11, “Planning
an Upgrade.”
Step 2 Analyze Your Environment 221

Geographic Profile
It is important to know the geographic profile of your organization because it affects your SMS
hierarchy design. A lot of organizations have a central location (headquarters) with branch
offices located in other regions (remote sites). Organizations that have locations in different cities
will probably have one or more SMS sites in each of those cities. Also, date and time zone
differences can affect how software is distributed to different locations. Create geographical
diagrams of your organization, and include the information listed in Table 7.4.
Table 7.4 Gathering Geographic Profile Data
Geographic information Data needed
Date and time zone information List the time zone for each location and any date
and time difference between the remote site and
headquarters.
Operating systems and international operating List the operating systems in use and locations that
system versions use language versions that are different from those
of your platform operating systems.

Organizational Structure
It is important that you know the structure of your organization, because it can influence how you
deploy, use, and support SMS. It is also useful to know your organization’s long-term plans.
Changes such as mergers and acquisitions can have a significant impact on IT infrastructure.
Both external pressure for change and internal projects (either planned or in progress) can affect
your SMS deployment.
Where applicable, obtain the data described in Table 7.5.
Table 7.5 Gathering Organization Data
Organizational structure Data needed
Departmental organization High-level organization charts to help determine
the divisional structure of your organization, the
design of your SMS hierarchy, and your method of
communicating SMS implementation updates to
departments
End users, clients, and software applications Number of client computers that are at each
location, which divisions they belong to, and
whether they are using unique software
applications or operating systems (see Table 7.7
for specific information)

(continued)
222 Chapter 7 The Pre-Planning Phase

Table 7.5 Gathering Organization Data (continued)


Organizational structure Data needed
Mobile clients A list of laptops that travel from one location to
another
IT organization and administrative policies The structure and technical level of local and
remote IT divisions, their reporting hierarchies, and
local and global IT administrative policies
Long-term business direction Any major business changes planned for the future,
such as mergers, acquisitions, major physical
moves, or network migrations

Network Topology
Create high-level diagrams of your network topology that include any available information
listed in Table 7.6. The larger or more complicated your network topology, the more diagrams
you need.
Table 7.6 Gathering Data on Network Topology
Network topology Data needed
High-level WAN/LAN architecture Links, gateways, geographic locations, firewalls,
and extranets or virtual private networks, where
applicable
Network size Number of servers and clients at each location
Network bandwidth Link speeds and available bandwidth, including
any known bandwidth issues
Network usage and traffic patterns Light, moderate, heavy — times of day when
network usage is heaviest (peak times) and
scheduled times for backup and maintenance
(non-peak times)
Network types Windows NT, Windows 2000, or Novell NetWare
and other third-party network operating systems
Network protocols TCP/IP, NetBEUI, IPX/SPX, AppleTalk, DLC,
DecNet, Banyan VINES, etc., and name resolution
methods such as DNS and WINS
IP subnet structure The IP subnets on your network by subnet ID
Active Directory site structure Active Directory organizational units, site names,
trees, and forest
Step 2 Analyze Your Environment 223

Later, after you make decisions about your SMS site structure and site system hardware
requirements, you can determine whether any equipment upgrades or additions are necessary
before your SMS deployment.
Network diagrams are also helpful when you create a representative test environment for your
test lab and pilot project. Ensure that your network diagram is detailed and specific. If your
network is large or complex, consider creating a similar but separate diagram for your domain
structure and server topology.

Client Environment
Where applicable, include client information in your network diagram. This type of information
can help you determine whether your client operating systems must be upgraded before
deploying SMS 2003, the scope of your SMS client deployment, which type of SMS client to
deploy, and which discovery and SMS client installation methods you will employ.
See Table 7.7 for a list of the types of client data you can collect.
Table 7.7 Collecting Client Data
Clients Data needed
Number of clients Total number of client computers in use on your
network, and the physical and logical groupings of
clients
IP subnet size Number and types of client computers on each IP
subnet, including projected number of clients in
the upcoming year
Logon scripts Whether or not users use logon scripts, and if those
scripts are customized
Security rights Desktop security rights granted to end users
Operating systems Platform operating systems (including language
version) in use on each IP subnet (Windows 98 and
later can become SMS 2003 clients), and the
locations of Macintosh and UNIX computers
(unsupported as SMS clients)
Client stability/mobility Computers that are shared by multiple users, those
that travel from one location to another, all home-
based client computers having remote access to
the network, and any other client computer
environments
Software A database or spreadsheet of all major
applications in use in the enterprise, categorized
by organizational division or by IP subnet

(continued)
224 Chapter 7 The Pre-Planning Phase

Table 7.7 Collecting Client Data (continued)


Clients Data needed
Special applications Divisions or departments that use Windows
Terminal Services to run applications, or use other
special applications, such as internally
manufactured or obsolete applications
Connectivity Types of connectivity different organizational
groups are using, including remote client
connection speeds (dependent on the remote
access method in use, such as ADSL, wireless,
dial-up, ISDN, or other)

It is important to gather client information so that you are prepared for interoperability and
connectivity issues that might prevent proper SMS client software installation. For example, all
the members of the Contoso Pharmaceuticals sales group use laptops. Some run Windows 95
(which is not supported as a SMS 2003 client), and others run Windows 98. Sales members
travel frequently from one location to another and use a special remote access application to
access the sales database located at headquarters.
The Contoso Pharmaceuticals marketing group, however, uses desktop computers running
Windows 2000 Professional. Although they do not travel, the marketing members have home
computers that they use to remotely connect to the corporate network over a virtual private
network (VPN). The marketing group uses Microsoft Access 2000 to access the sales database
located at headquarters.
Having this information can help you avoid potential interoperability conflicts with remote tools.
It gives you a chance to plan an upgrade of the clients running Windows 95 to an operating
system supported by SMS 2003. Also, it allows you to plan for remote SMS client installation
scenarios, in addition to testing SMS client connections over the VPN.

Domain Models
Create diagrams that show your domain models, using one-way or two-arrows to indicate the
trust relationships in your model. SMS 2003 supports the following domain models:
u Windows NT domains
u Windows 2000 Active Directory native mode domains
u Windows 2000 Active Directory mixed mode domains
u All Windows Server™ 2003 Domain functional levels
Step 2 Analyze Your Environment 225

Windows NT Domain Model


The following are types of Windows NT domain models. See Figure 7.1 for a basic diagram of a
Windows NT master domain model:
u Single domain
u Single master
u Multiple master
u Complete trust
u Mixed mode (see the “Active Directory Structure” section later in this chapter)
Figure 7.1 Sample master domain model diagram
Los Angeles domain

Advertising

Sales2

Master
Development domain

Manufacturing

PDC

Sales1

Seattle domain

Advertising

San Francisco domain

Windows 2000 Active Directory Domain Model


The Windows 2000 domain model uses Active Directory domains and trusts. You should know
how your Active Directory site structure is laid out in relation to your domain model. This is
important if you are using mixed mode domains. Active Directory service is compatible with
Windows NT 4.0 and supports a mixed mode of operation using both Windows 2000 Server
domain controllers and Windows NT Server 4.0 domain controllers.
226 Chapter 7 The Pre-Planning Phase

It is recommended that you be aware of the status of your Active Directory migration. Which of
your domains are in mixed mode? Typically, after all of your Windows NT domain controllers
are upgraded to Windows 2000, native mode is enabled on the domain. Figure 7.2 illustrates the
different mode types.
Figure 7.2 Types of domain modes available on a Windows 2000 network
PDC not PDC upgraded PDC and all PDC and all
upgraded but not all BDCs upgraded - BDCs upgraded -
BDCs upgraded native mode native mode
switch not yet switch has been
set set

Windows NT Mixed Mode Mixed Mode Native Mode


Domain Domain Domain Domain

Windows Server 2003 Active Directory Domain Model


Windows Server 2003 introduces a way to enable domain-wide Active Directory features in your
network environment. This is called domain functionality, and is expressed in four different
levels, as seen in Table 7.8.
Be aware of the status of your Active Directory migration. SMS 2003 supports all four domain
functional levels.
Table 7.8 Windows Server 2003 Domain Functional Levels
Domain functional level Domain controllers supported
Windows 2000 mixed (default) Windows NT 4.0
Windows 2000 Server family
Windows Server 2003 family
Windows 2000 native Windows 2000 Server family
Windows Server 2003 family
Windows Server 2003 interim Windows NT 4.0
Windows Server 2003 family
Windows Server 2003 Windows Server 2003 family
Step 2 Analyze Your Environment 227

Active Directory Structure


Document your Active Directory site names and locations. Active Directory is the directory
service for Windows 2000 and Windows Server 2003 family of products. It stores information
about objects on the network. An Active Directory site is defined as one or more well-connected
TCP/IP subnets. A well-connected TCP/IP subnet has a fast, reliable network connection.
The logical structure of your organization is represented by the following Active Directory
components:
u Organizational units
u Domains
u Trees
u Forests
The physical structure of your organization is represented by the following Active Directory
components:
u Active Directory sites (physical subnets)
u Domain controllers
When planning your SMS hierarchy design, consider your Active Directory logical layout
(hierarchical forest arrangement and domain structure), and its physical structure
(Active Directory site topology). Later, when planning your SMS deployment and configuration,
become familiar with the more granular details of the logical structure, such as organizational
units, because these can help determine how you organize collections, distribute software, and
perform queries in SMS.
Document your physical Active Directory structure and domain structure before you begin the
planning phase. You might also include a diagram similar to that in Figure 7.3 if your
environment includes mixed-mode domains.
228 Chapter 7 The Pre-Planning Phase

Figure 7.3 Sample Active Directory structure depicting domain modes and operating
systems

Contoso.com

Contoso-acct Contoso-
corp

Windows 2000 Windows NT Windows 2000 Windows 2000


Professional 4.0 Workstation Server Server

Contoso-
sales
Key

Windows 2000 Windows NT


Server 4.0 Server
Mixed-Mode Native-Mode
Domain Domain

Server Environment
Document the location and function of the computers that run the core services of your network,
such as domain controllers, DNS and WINS servers, Internet Information Services servers,
computers running SQL Server or Terminal Services, Exchange servers, print servers, and file
servers.
Document current naming conventions for products you use with SMS, such as Windows 2000
and SQL Server. This helps you establish and document naming conventions for SMS elements
in your project plan. These elements include sites, site codes, servers, and the objects that are
used by or created in the SMS Administrator console. Because the SMS site code is used to
uniquely identify each SMS site, it is especially important that these codes are assigned and
tracked by the SMS central site administrators.
Step 2 Analyze Your Environment 229

It is recommended that you document the following hardware, software, and network information
for each domain controller and file server in your network, because some of these servers might
also function as SMS component servers:
u Type and speed of the microprocessor and amount of RAM installed
u Disk and array controller characteristics and configuration, including whether Windows
Cluster Service or Windows Network Load Balancing Service is enabled
u Naming conventions
u Devices and their characteristics, including size, MB of cache, and the drive models and
types (for example, ultra-wide SCSI, 18 GB, 7200 RPM)
u Primary domain controllers and backup domain controllers
u Servers running Terminal Services
u Platform operating system, version, and language
u DHCP servers and IP address scopes
u WINS servers
u DNS servers
u Relevant software applications located on servers, including anti-virus software
u Novell NetWare and other third-party network servers

Note
Novell NetWare servers are not supported as SMS servers in SMS 2003.

See Figure 7.4 for a sample network diagram showing a basic server environment. Use a
database or spreadsheet to store specific information about each server.
230 Chapter 7 The Pre-Planning Phase

Figure 7.4 Sample server environment diagram


Windows 2000 Domain Controller
DNS/WINS Server
172.16.4.11/22
Sv3.Corp.Com
Windows 2000
Terminal Server
Sv6.Corp.Com
172.16.4.10/22 Windows 2000
Exchange Server
Sv2.Corp.Com
172.16.4.9/22
Windows 2000
DHCP Server
Sv44.Corp.Com
172.16.4.1/22 172.16.16.0/22

172.17.4.1/22
172.16.16.1/22
172.17.4.2/22
172.16.8.10/22 UNIX Server
Solaris 2.6
172.16.8.1/22 172.16.16.5
Cabling:
100BASE-T
Category 5 UTP
Ethernet

Windows NT 4.0
DHCP Server
172.16.8.46/22 Windows NT 4.0 Server
Sv21.Corp.Com DHCP Assigned
Sv23.Corp.Com
Windows NT 4.0 PDC
172.16.8.22
Sv10.Corp.Com

172.16.8.60/22
172.17.8.1/22
Public IP Proxy Server
Address Range Sv33.Corp.Com
172.17.8.2/22
DS3
Internet
Step 2 Analyze Your Environment 231

Security
Chapter 5, “Understanding SMS Security,” introduces important concepts underlying SMS
security. Familiarize yourself with these concepts and examine your current security procedures
before planning your SMS security strategy.
Collect information about your organization’s security policies, such as:
u Account password policies (age, length).
u Account cycling policies (account expiration).
u Account rights policies.
u Client and server lockdown policies (restrictions on disks and registry, services that are
stopped, whether services use Domain Administrator accounts, hidden shared folders that are
removed).
u Auditing policies (activities being audited, if any).
u Separation of duties between IT divisions within the enterprise (be aware of any overlap).
u The degree to which users must retain control of clients, and any exceptions to such policies
(for example, servers or computers used by programmers).
u Sensitivity to security risks.
u Importance of ease of administration.
u Special needs you have for secure data access and transmission.
If you document your security policies, you will be prepared to plan your SMS security strategy
during the planning phase.

IT Organization
It is important to determine your personnel resource needs and to assign project roles when
planning your SMS configuration and deployment. To do this, you first must have an
understanding of your current IT organization. You need this information during your SMS pre-
planning, planning, and deployment phases, and also for post-deployment operational tasks.
Understand the breakdown of IT staff in your organization. For example, you might have one
centralized IT unit whose members are in close communication. Or, you might have many
decentralized units where communication is not optimal. Is there a central headquarters with IT
responsibility, or many separate organizational units with widely varying goals and philosophies?
232 Chapter 7 The Pre-Planning Phase

Create an organization chart that maps your IT organization to your geographic profile. Include
the following in your organization chart:
u IT reporting hierarchy
u IT departmental divisions that produce an overlap in SMS tasks (for example, a department
separate from the SMS team manages all database servers, including computers running
SQL Server)
u Points where management control issues or policy issues exist
u Level of technical sophistication and security clearance of IT staff members who will be
working with SMS before, during, or after SMS deployment
u Service level agreements for departments, end users, and IT groups
u Operating systems used to support the network and end users
u Change control policy
Management control issues might not seem important, but consider this: SMS security controls
access by resource type. IT policy issues might exist regarding who controls which clients in
which regions. In the planning phase you must address these issues. It is important to familiarize
yourself with the IT structure, administrative policies, and any existing service level agreements
early on in the process.

Step 3 Analyze Your Needs


A clear understanding of how you want to install and modify SMS to suit your business and
technical needs is an integral part of the pre-planning process.
This knowledge allows you to define the business and technical objectives to include in your
project plan. For example, reducing the cost of software upgrades and simplifying hardware asset
tracking are common objectives. A technical objective might be migrating from a
Windows NT domain structure to a Windows 2000 domain structure, or implementing
Active Directory in your network environment.
It is important to understand what you need, want, and expect from SMS. A core requirement
often stated is to distribute software, but what exactly does this mean? What software, how often
is it to be distributed, and to how many users? What size are the application files, where are the
destination computers located, and are there any language-related issues? Will software package
installations be optional, mandatory, or a combination of both?
The answers to these questions can have a significant impact on your design.

Identify Requirements
To establish business objectives, you must first gather specific information about your
organization, as outlined in the “Organizational Structure” section earlier in this chapter. This
helps you determine which SMS features you want to use.
Step 3 Analyze Your Needs 233

Use your organizational charts and the sample chart in Table 7.9 to create a list of requirements.
It is important to make these requirements measurable because your requirements are part of the
project’s deliverables and milestones. Map each requirement to the SMS feature that you will use
to meet that need.
Table 7.9 Example of Mapping SMS Features to Business Needs
Business needs SMS 2003 features
Configuration management
Track hardware and software assets and collect files from client Hardware and software inventory
computers.
Produce and share reports on computer assets and application Reporting
monitoring from any Web-based computer.
Centrally administer client reporting across products that can Active Directory discovery
use Active Directory.
Manage site boundaries by Active Directory site names instead Active Directory site boundaries
of (or in addition to) IP subnets.
Release management and license compliance
Deliver software to clients for automatic or user-assisted Software distribution
installation.
Create preconfigured self-extracting software packages and SMS Installer
perform unattended software installations on clients.

Convert SMS Installer packages to Windows Installer format SMS Installer


(.msi).
Increase efficiency of site-to-site software package replication Delta replication
(conserve bandwidth in updating software packages on
distribution points).
Manage laptops over slow network links and reduce the cost of Advanced Client
remote client operation over expensive WAN links.
Monitor usage of software programs. Software metering
Incident management
Perform remote troubleshooting. Remote Tools

It is recommended that you list your requirements in order of priority. In situations where time is
limited, the design effort must first focus on the essential requirements to ensure that key
functionality is delivered. On time-limited projects, it is still important to be aware of lower
priority issues, because a design that is based on only the essential requirements might prevent
the implementation of other deliverables.
234 Chapter 7 The Pre-Planning Phase

In accordance with Microsoft Solution Framework best practice, requirements must be:
u Specific.
u Measurable.
u Achievable.
u Results-oriented.
u Time-specific.
The metrics to measure success must be known and achievable within the allowed time, budget,
and other constraints. Following these guideline assists you in establishing and tracking project
milestones.

Assessing Time and Budget Allotments


When determining your requirements, assess the amount of money and time that can be allocated
for the project.
Expenses for the project can potentially include software licensing, IT staff salaries, training
costs, and hardware procurement or upgrades. Identify how much money you can afford to spend
on the project before finalizing your SMS hierarchy design or hiring additional staff.
Knowing when you and your team must complete the project is relevant to how much work can
be accomplished. It is recommend that you not move forward with planning your SMS
configuration and deployment until you establish the amount of time that can be dedicated to the
project.
After each phase of the project, it is a good idea to review any changes in budget and time
allotments, and whether these allotments are appropriate for the expected scope of the project.

Step 4 Assemble the Team


One of the tasks of the project manager is to assemble a team of IT specialists to fulfill the roles
in the planning and deployment processes. Typically, during the same time period, roles are
assigned to IT staff members who will manage, maintain, and operate SMS.
Before moving forward with the planning phase, it is recommended that you begin assembling
your team. Some of the SMS team members need to participate in the planning phase. Begin
assigning roles based on the work functions described in Table 7.9, and review your team
structure as you complete each step in the planning and deployment phases, because some of the
roles might be assigned later on in the project.
Step 4 Assemble the Team 235

Occupation Taxonomy
The number of IT staff members needed to successfully plan, deploy, and administer SMS
depends upon many factors. SMS activities fall into several categories. In small implementation
projects, one person might fill several roles. In large implementation projects, several people
might be assigned to each role. The size and complexity of your organization’s SMS hierarchy
will further define the workforce requirements.
Some SMS roles require a good understanding of the Windows operating system,
Windows security, and SQL Server. Some of your SMS team members should be familiar with
your organization’s network infrastructure and security policies. The occupation taxonomy in
Table 7.10 is based on the Microsoft Readiness Framework and describes the SMS roles and
responsibilities to consider when you determine your personnel needs.
Table 7.10 SMS Occupation Taxonomy
Role Critical work functions
Project sponsor Manage customer expectations and customer interaction processes
(the customers are your SMS users and other members of your
organization who benefit from SMS functionality).
Oversee feature identification and prioritization.
Promote a shared product vision.
Develop, maintain, and manage the business case.
Project manager Define and manage project scope.
Assemble the planning and deployment team.
Define and manage project plan and timeline.
Manage project integration.
Develop and manage project budget.
Manage project quality process.
Manage project human resources.
Manage project communication processes.
Assess and manage risks.
Perform change control and change management.
Manage project procurement processes.

(continued)
236 Chapter 7 The Pre-Planning Phase

Table 7.10 SMS Occupation Taxonomy (continued)


Role Critical work functions
Administrator These tasks are typically divided among multiple administrators with
varying degrees of expertise:
Run test lab and pilot project.
Design SMS sites and hierarchy.
Install and configure SMS sites and component servers.
Set up security within SMS.
Create customized Microsoft Management Console (MMC) consoles
and distribute them to SMS administrators and help desk
specialists as needed.
Troubleshoot SMS site problems.
Create reports.
Perform SMS task administration.
Create software distribution packages and advertisements.
Manage collections.
Create and manage queries.
Monitor SMS processes and report status.
Programmer Create scripts for use in SMS.
Customize tools.
Design and develop SMS applications.
Test and validate programs.
Release and implement solutions.
Manage development environment.
Database administrator Perform SQL Server administration and maintenance for SMS site
database.
Troubleshoot database problems.
Help desk specialist Troubleshoot SMS client problems.
Use SMS Remote Tools in workstation support and troubleshooting.
Provide customer service to end users.
Perform system operations, monitoring, and maintenance.
Trainer Analyze training needs through skills assessment.
Develop training solutions.
Deliver training to administrators, help desk specialists, and others
as needed.
Assess training effectiveness.
Develop user documentation.
Step 4 Assemble the Team 237

SMS team: One possible scenario in a large


organization
In this scenario, Contoso Pharmaceuticals is a large international
organization with 55,000 clients and 1,200 Windows 2000 servers.
Contoso is running SMS 2.0 with plans to upgrade to SMS 2003.
The company has one central SMS site, 50 primary sites, and
45 secondary sites, and uses SMS software distribution to deploy over a
million software package distributions per year.
Contoso’s IT organization consists of seven dedicated SMS
administrators who are responsible for creating packages, and
troubleshooting and maintaining SMS sites. In addition, there are
50 non-dedicated (part-time) site-based administrators worldwide
assisting the dedicated administrators by providing hands-on support
for processes that require physical access to SMS servers at their
locations. Two or three trainers provide SMS training and internal
training documentation as needed.
In addition, Contoso has 20 staff members who are dedicated to writing
and testing the installation scripts and executable files that are
delivered by the SMS software distribution process. Each Contoso
location has an onsite database administrator who assists with
SQL Server troubleshooting and optimization on the local site server.
Contoso’s help desk staff has 300 people using SMS Remote Tools in
customized SMS Administrator consoles for remotely supporting end
user computers.

Assigning Roles
The roles of project sponsor and project manager are the first roles assigned in the project. The
project sponsor determines the business needs, maps them to SMS features, and prioritizes them.
The project manager defines the project scope and assembles the team.
The project manager puts together a team consisting of SMS administrators with varying roles.
For example, one SMS administrator might be in charge of building the test lab and conducting
the pilot deployment. Another SMS administrator might be in charge of planning the SMS
hierarchy and monitoring network bandwidth availability during the pilot project. Other
administrators might be assigned other tasks as described in Table 7.9.
The project manager should locate a trainer who can educate the staff members on several levels
of SMS functionality. For example, train your help desk specialists in troubleshooting the SMS
client and using Remote Tools. The SQL Server database administrator needs advanced training
in performance tuning of the SMS site database. The SMS administrators, however, might
require formal training ahead of time in the more technical aspects of SMS and SMS
administration.
238 Chapter 7 The Pre-Planning Phase

Typically, your help desk is already staffed and their roles are assigned, so you might not need to
assign new roles unless you want to assign an SMS leader for that group. Or, for a smaller
organization, you might need to assign some of the help desk personnel various administrative
tasks in SMS.
Assign the responsibilities for database administration to a SQL Server database administrator.
Also, it is helpful to have a programmer or someone knowledgeable about scripting perform a
role in SMS operations.

Support Plan
After SMS is installed in your production environment, it must be supported. It is a good idea to
develop your support plan before conducting your SMS deployment so that it is in place when
needed. Note that for larger organizations you might develop two support plans, one for before
and during employment, and another for after deployment.
When developing a support plan, balance the administrative requirements of supporting your
SMS hierarchy with your budget and staffing resources. Keep in mind that effective support
helps set a positive tone your SMS implementation. Do not underestimate your support
requirements.
The support plan addresses the expectations of both the end users and the IT staff. End users
expect timely responses to problem reports. If software distribution is implemented, end users
also expect timely distribution of requested software packages. Administrators expect proper
tools for client management. Help desk specialists might need the ability to remotely
troubleshoot individual client computers.
Some variables to include in your plan are:
u The amount of staffing resources you can devote to testing SMS and running the pilot
project.
u The amount of long-term staffing resources you have during and after deployment.
u A support matrix showing who provides support for which group of users (end users,
administrators, help desk specialists, and any other SMS users in your organization).
u A path for escalating problems to higher-level support tiers.
u The hours that support will be available to users.
u Methodology for reporting, tracking, prioritizing, and resolving problems.
u Service level agreements required for various groups in your organization.
Communication Strategy
It is important that you communicate your plans to other groups in your organization because
SMS affects other groups more directly than most other products do. Communication to the
management team and all project sponsors is essential.
Step 4 Assemble the Team 239

You can also start building support and acceptance early in the project by having other managers
and key personnel review your plans before you begin the deployment phase of the project.
Continue to keep these people informed as you make changes that could impact network access
and performance.
By defining effective communication channels and methods, you help ensure that:
u All participants are regularly informed about the progress of the project.
u All participants are aware of their roles and responsibilities.
u The project team is aware of problems as they occur.
Your communication strategy should address the needs of the following groups.
IT professionals and SMS users
This group includes administrators, programmers, help desk specialists, database administrators,
IT managers, and trainers. Communication with IT professionals and SMS users includes regular
risk assessment and updates on progress. Encourage individuals to bring problems to the
attention of other IT team members. Meet on a regular basis and maintain a formal record of
issues and decisions.
Effective communication among the IT staff ensures that problems and risks are managed
efficiently. It also increases project visibility, facilitates support of SMS in your organization,
and contributes to the overall success of the project.
Communication with trainers should emphasize SMS concepts and procedures that require
further documentation and clarification. On a regular basis, send summaries of problems reported
by end users to your trainers so that the more common issues can be communicated during
training sessions.
SMS users are people who might not be involved in the SMS project but benefit from it. This can
include systems analysts, managers, and other professionals who use SMS features, such as
software distribution, reporting, and remote help desk support. Early communication ensures that
the deployed system adequately serves their needs.
End users and managers
An SMS user is anyone in your organization who uses or is responsible for a computer that has
the SMS client installed on it. An end user is anyone who is somehow affected by the SMS client
deployment.
Communicate with end users and their managers to prepare them for the SMS deployment and
introduce them to the features of SMS. For those end users involved in your pilot project, proper
communication prepares them for their role in the pilot project and encourages them to become
active participants.
Methods of Communication
Consider implementing the following communication methods:
u Progress updates sent to specific e-mail distribution lists
u A Web site for quick access to frequently asked questions, procedures, and status reports
240 Chapter 7 The Pre-Planning Phase

u Articles in your organization’s newsletter


u A newsletter, flyer, or memo devoted to the pilot project
u Online or printed customer satisfaction surveys
If your communication strategy requires that you create a Web site or e-mail distribution lists,
create these mechanisms well in advance of the pilot project so that you are prepared to
communicate with all pilot participants from the start.

Step 5 Begin Assembling the Project


Plan
After you have documented your environment, assembled your SMS team, and identified your
objectives, begin creating the project plan to use in designing, deploying, and configuring SMS.
Your designs and plans can change as you proceed through planning, testing, and deploying
SMS. Your project plan documentation should be in modular form, so that you can add and
remove documents as needed, and it should contain a master schedule.
The plan might be contained in something as simple as a three-ring binder or series of binders.
Or, you might choose to use a document management system such as Microsoft SharePoint™
Portal Server 2001. For more information about document management, see the SharePoint
Portal Server Web site at
http://www.microsoft.com/sharepoint/default.asp.
Consider posting this information for access by your IT staff members and project sponsors.
Project Plan Document
You are now ready to define and document a project plan for your SMS implementation. It is
recommended that your project plan document include the following information:
Scope and schedule Define the scope of the project by creating a master schedule indicating
personnel and time requirements. The amount of time required to plan an SMS implementation is
dependent on a number of factors, including the size and complexity of your organization and
infrastructure. Allocate plenty of work hours in the pre-planning and planning phases. Do not
forget to schedule lab testing and a pilot project before the SMS deployment.
Business requirements and technical objectives Ensure that your plan clearly states your
objectives, and how SMS fulfills these objectives. Ensure that your plan provides methods that
measure progress and success.
Risk analysis strategy Develop a plan for performing a risk analysis at the end of each major step
or phase, and add reminders in your schedule to perform this task.
Time and budget reviews Keep track of your time and budget reviews that are conducted at the
end of each phase and throughout the project as needed. Add reminders to the schedule to review
any newly introduced budgetary or time constraints, because adjustments to these resources
might be required before proceeding to the next phase.
Step 5 Begin Assembling the Project Plan 241

Communication strategy Assign communication tasks to team members to keep the appropriate
people in your organization informed at each phase of the project.
Assumptions Clarify the tasks that SMS project team members will and will not do.
Overview of the current networking environment Include the information you collected in step 2,
“Analyze Your Environment.” Add a high-level description of what in the existing environment
needs to change and how these changes would satisfy project goals and objectives.
Test lab plan Include a plan that describes your test lab configuration. For more information, see
step 7, “Establish Test Lab Environment.”
Test plan and pilot project plan Include a pre-implementation testing plan, and add testing to your
master schedule. This involves tasks such as testing SMS hierarchy design, client discovery and
installation methods, and operational scenarios like software distribution. Also, include a plan for
your pilot project, where you distribute the SMS client to a limited number of computers in your
production environment. For more information about creating these plans, see Chapter 10,
“Planning Your SMS Deployment and Configuration.”
Naming conventions Document your SMS site codes, server names, and other SMS elements in
your project plan. Consider standardizing the names and locations of all your documentation
relating to the project.
Site and hierarchy design Include your SMS site and SMS hierarchy design, which documents
the full SMS hierarchy structure, site boundaries, site systems, site connection methods, etc. For
more information, see Chapter 8, “Designing Your SMS Sites and Hierarchy.”
Deployment strategy Include your deployment plans. For guidelines, see Chapter 10, “Planning
Your SMS Deployment and Configuration.”
Security strategy Include a well-documented plan for your security strategy. For more
information, see Chapter 12, “Planning Your SMS Security Strategy.”
Recovery plan Create a plan describing your recovery strategy. For more information, see
Chapter 13, “Planning for Backup and Recovery.”
Upgrading to SMS 2003 (if applicable) Include your plan for upgrading to SMS 2003, if this
project is not a new installation of SMS 2003. For more information, see Chapter 14, “Upgrading
to SMS 2003.”
Staffing and support plan Document the assigned roles that you define when you assemble the
team. Create a support plan that defines support roles on your team. The support plan also
outlines the escalation path and criteria, and defines service level agreements for the various
groups in your organization. Create a template for a standard service level agreement and include
it in your project plan documentation.
Training strategy Create a plan to train the appropriate staff in installing, using, and supporting
SMS. This includes a current skills assessment for each team member, the level of training
needed, and the source of that training. For more information, see step 6, “Learn SMS” later in
this chapter.
242 Chapter 7 The Pre-Planning Phase

Operations Plan how to operate, manage and maintain your SMS sites after deployment. For
more information, see Part 2 of the Microsoft Systems Management Server 2003 Operations
Guide, “Maintaining SMS in Your Organization.”

Step 6 Learn SMS


This section describes developing a training and education plan for learning SMS. Your test lab
and pilot project can provide valuable hands-on training for many people involved in the project.

Groups to Train
It is recommended that your training plan address the needs of the following groups:
u IT professionals
u SMS users
u End users
IT professionals
This group includes administrators, database administrators, trainers, and any other IT
professional or staff member who administers SMS or educates others in SMS.
Training for your IT professionals should address setting up and supporting the SMS hierarchy in
a production environment. Site creation, site communication, site system setup, client
installation, and troubleshooting procedures are tested in the lab, and are further explored during
the pilot project.
Your in-house training staff might also need additional training to expand their SMS knowledge
and skills. The higher the skill level, the better equipped your trainers are to develop high-quality
training programs that address the needs of user groups throughout the organization.
SMS users
This group includes programmers, help desk specialists, and any other users who take advantage
of the features of SMS. Provide the help desk staff members with materials and training that
familiarize them with the SMS Administrator console. This includes understanding the SMS
hierarchy, navigating MMC, using Remote Tools, generating reports, running queries, using the
resource explorer, and tracking software distributions.
Help desk specialists and programmers do not have to be SQL Server experts, but it is beneficial
if they are familiar with Windows, SMS, and the corporate network environment. Programmers
require training in designing and developing SMS applications, creating scripts, and testing
programs.
Provide documented procedures to your SMS users for escalating SMS issues to the central SMS
team.
Step 6 Learn SMS 243

End users
End users must understand how SMS affects them, what its benefits are, and what to do if they
encounter problems. Effectively educating your users can help set positive expectations of SMS
in your user community, in addition to enabling end users to become active pilot participants.
Carefully plan and implement your promotion of SMS features to your organization. Likewise, it
is important that you inform your end users of what SMS will not do, such as monitor all
computing activities of each user. Consider holding special sessions on this topic for all affected
personnel in the organization. This can be beneficial both during and after your SMS
deployment.

Training Methods
Training methods can include:
u Self-paced computer-based training courses.
u Instructor-led classroom sessions.
u Webcasts offered online at http://www.microsoft.com/smsmgmt/default.asp.
u Printed and electronic product documentation provided by Microsoft and third-party
resources.
u Internally created printed documentation that is specific to your organization.
Another good way to obtain information about SMS is to monitor user groups and mailing lists
that focus on SMS issues.
Training can be conducted in any of the following locations:
u On site
u Authorized Microsoft training centers, such at the Microsoft Authorized Academic Training
Program and the Microsoft Certified Technical Education Center
u Third-party training facilities

More Information
The following Web sites provide additional information about SMS and other training options
offered through Microsoft:
u SMS training Web site: http://www.microsoft.com/smsmgmt/training/default.asp
u Microsoft Training and Certification:
http://www.microsoft.com/trainingandservices/redirect/mcp.htm
u Microsoft Training for the Enterprise (Microsoft Solutions Framework and Microsoft
Operations Framework training): http://www.microsoft.com/trainingandservices/default.asp
For more information about training resources, news groups, and mailing lists, see the SMS
Resource Roadmap, available for download at http://www.microsoft.com/smsmgmt/default.asp.
244 Chapter 7 The Pre-Planning Phase

Step 7 Establish Test Lab


Environment
Set up a test lab on an isolated network in your organization. Do not set up your test lab in your
production environment, and do not install SMS on any of your production servers before
installing it and working with it in your test lab. Installing SMS in a production environment
without first testing it on an isolated network can cause undesirable and potentially damaging
results. Later, during the deployment planning stage, you will design a pilot project for further
testing. The pilot project is described in Chapter 10, “Planning Your SMS Deployment and
Configuration.”
Use the test lab to perform tests throughout the steps of the planning phase:
u Designing the SMS hierarchy
u Planning the deployment and site configuration
u Planning your security strategy
u Planning for backup and recovery
Also, use the lab to perform tests throughout the steps of the deployment phase:
u Deploying the hierarchy
u Deploying SMS clients
Maintain your lab for post-deployment testing.
Developing the Test Lab
Your test lab computers must use at least the minimum recommended configuration required for
their SMS roles. The computers must contain configurations that are representative of those in
your organization.
Minimum recommended configuration Lab computers must meet the minimum recommended
configuration for the roles they perform in SMS. For example, ensure that your SMS site servers
and site systems have the minimum system requirements specified in the “Getting Started”
chapter of this book.
Standard configurations If your organization has standard client and server configurations, use
those configurations in the lab. To the extent that it is possible, use the same hardware, software,
network connectivity, and logon scripts that are used in your production environment. For
example, if your production environment includes computers with nearly full disks, obsolete and
possibly unused software, and an assortment of network adapter cards, ensure that your lab
computers have the same characteristics.
Duplicating network conditions If production networks are connected by routers or slow links, be
sure to duplicate those conditions in the lab. This approach ensures that design concerns can be
identified and resolved in the lab rather than during deployment.
Step 7 Establish Test Lab Environment 245

Creating a Representative Test Environment


For the test results to be useful, ensure that the lab environment reflects your production
environment as closely as possible. Use the network diagram you create at the beginning of the
pre-planning phase to help you create a representative test environment. Add at least one client
for each client platform that you plan to support.
Include a representative of each type of site system role, server, and client that will exist in your
full SMS hierarchy. Also, the network link connecting these objects should mirror the network
speed and availability in production.
Your hierarchy should contain a central site and a representative number of child primary sites
and secondary sites. Include desktop and mobile clients (laptops) that are based on the standard
configurations of your organization. Your test data might be distorted if you create a test
environment that contains computers that have only fast processors and a lot of memory, instead
of less powerful, smaller computers in the hierarchy. You can gain valuable information by
analyzing how your planned SMS hierarchy functions in your network as it exists today,
including outdated computers and obsolete applications.
The closer your test installation resembles your actual network design and hardware, the more
valuable your results are as you plan the deployment of SMS throughout your organization. In
your test lab, install all applications in use in the production environment so that they are
available for application compatibility testing.
During testing and the pilot project, test and refine your project plan documentation regarding
support and deployment. As you plan your SMS hierarchy design, you might need to add more
servers or clients to your test environment, depending on your needs as the planning progresses.
Maintaining the Test Lab
After deploying SMS 2003, keep your test lab intact. Use it for future testing of SMS service
pack and feature pack installations, proposed site changes, software distribution scenarios, and
other SMS activities. For example, it is important that you test each software package in your test
lab before distributing it in your production environment. Continually update your test lab
environment as your production environment changes. By maintaining this test lab throughout
the life of SMS, you will always have an isolated SMS hierarchy for testing purposes.
Because the test lab represents your production environment, it is ideal for performing periodic
recovery tests. This helps you identify shortcomings in your backup and recovery plan. For more
information about preparing your test lab for recovery tests, see Chapter 13, “Planning for
Backup and Recovery.”
C H A P T E R 8

Designing Your SMS Sites


and Hierarchy

The task of designing your SMS sites and hierarchy is done during the planning phase, before
implementing Microsoft® Systems Management Server (SMS) 2003 in your production
environment. This chapter includes an overview of SMS hierarchy design and guidelines for
designing your SMS sites and arranging them in a hierarchy.
To benefit most from this chapter, you should be familiar with the following chapters in this
book:
u Chapter 2, “Understanding SMS Sites”
u Chapter 3, “Understanding SMS Features”
u Chapter 7, “The Pre-Planning Phase”
While designing your SMS sites and hierarchy, see Chapter 9, “Capacity Planning for SMS
Component Servers,” to determine how many site servers and site systems you need.

In This Chapter
u Overview
u Designing SMS Sites and the SMS Hierarchy
u Advanced Design Issues
u Reviewing and Testing the Design in the Lab
248 Chapter 8 Designing Your SMS Sites and Hierarchy

Overview
When planning your SMS sites, start by examining your organization’s infrastructure. To
successfully design your sites and hierarchy, perform the pre-planning steps identified in
Chapter 7, “The Pre-Planning Phase.” This includes gathering and analyzing data about your
organization and its environment. After you analyze this data, examine the technical and business
considerations that affect SMS site and hierarchy design. Then you can create an appropriate
design. The design should provide the ability for server hardware to scale up as your organization
grows.
It is critical that you test your hierarchy design before deploying SMS in your production
environment. To do this, create a representative test hierarchy in a test environment that is
isolated from your production network. The test hierarchy is a smaller scale version of your SMS
hierarchy. You can use the data that you gather, and the experience that you gain in your test lab
and during your pilot project, to refine your final hierarchy design and implementation.
Chapter 10, “Planning Your SMS Deployment and Configuration,” guides you through the
process of creating a pilot project to troubleshoot and refine your design while planning your
server and client deployment for SMS 2003.
Designing an SMS site involves defining site boundaries and roaming boundaries, establishing
the SMS site systems to be deployed within the site and their physical locations, and determining
recommended hardware specifications.
Designing the SMS hierarchy involves establishing the logical relationships between distinct
SMS sites and determining where information is reported. In designing the SMS hierarchy, you
choose a primary site to serve as the central site. The central site is the parent to other sites. The
first primary site you install is a stand-alone site. It has neither parent sites nor child sites. The
site can remain a stand-alone site, or you can attach it to other sites to build a hierarchy.
Determining the type of site to deploy in each location is a critical step in the hierarchy design
planning process. After you define the sites, you can build your hierarchy.

Note
Implementing a single SMS site to manage all network resources is usually
not practical for large organizations or for any organization with multiple
locations communicating over wide area network (WAN) links. These
organizations usually require multiple SMS sites arranged in hierarchies.

Figure 8.1 shows a sample hierarchy design based on geographic location for an international
company that has its headquarters in Chicago.
Overview 249

Figure 8.1 A three-tier SMS hierarchy based on geographic location


Primary site
Chicago
(parent site)

Central site server


SMS site database
(SQL Server)

Primary site Primary site


NYC London
(child site) (parent site and child site)

Site server Site server


SMS site database SMS site database
(SQL Server) (SQL Server)

Secondary site
Milan
(child site)

Site server
250 Chapter 8 Designing Your SMS Sites and Hierarchy

Figure 8.2 shows a sample hierarchy based on the residential and commercial organizational
divisions for a company with a single location in Seattle.
Figure 8.2 A two-tier SMS hierarchy based on organizational division
Central site
Seattle
SEA

Reporting Central site server


point SMS site database
(SQL Server)

Server locator
point

Parent

Primary site Primary site


Seattle Seattle
COM RES
Site server Site server
Distribution Distribution
SMS site database SMS site database
point point
(SQL Server) (SQL Server)
CAP CAP
Management Management
point Distribution point Distribution
point point
CAP CAP

Distribution CAP Distribution CAP


point point

Child Child

Designing SMS Sites and the SMS


Hierarchy
Understanding the benefits and required resources that are associated with each SMS feature, and
the effects of those features on your SMS hierarchy, can be complex. The design process requires
reviewing the technical and business considerations that can affect the design. Many of these
considerations are listed in this chapter, although you might include additional considerations that
apply to your organization in particular. Plan how to address these considerations using design
specifics, and prioritize the considerations as you examine them.
Using this information, determine the locations of your SMS sites. If you have more than one site
in your SMS hierarchy, determine which sites use similar designs and which ones require
different designs.
Designing SMS Sites and the SMS Hierarchy 251

Determine where these site types will be located in relation to one another, and map out your
hierarchy. When designing your hierarchy, review and test it in the test lab. Making
modifications to your hierarchy design during this phase is easier and entails less risk than if you
make changes after deployment.
When designing the SMS hierarchy, consider the physical layout of your network and the
administrative requirements of your organization. The SMS hierarchy you design should reflect
both the layout of your network and the administrative requirements of your organization.

Business and Technical Considerations


At this stage of the planning process, ensure that you have completed the following tasks and
have included this information in your project plan documentation:
u Collected the computing environment data listed in Table 7.3
u Determined your objectives
u Developed a clear understanding of the SMS 2003 features to implement
u Identified the numbers and types of resources located throughout your organization
With this information, you can address the business and technical considerations that affect your
hierarchy design. When designing your hierarchy, examine these considerations, determine
whether they are applicable to your environment, and prioritize their relevance.

Business Considerations
Major business considerations that can affect your hierarchy design are listed in this section. As
you examine these considerations, determine their applicability and their relative priority in your
design.

Geographic Profile
Be aware of multiple languages and time zones that exist across your enterprise. These can affect
the placement of your site servers and the language version of the software you deploy. If your
organization has locations in more than one country or region, then your SMS hierarchy will
probably span those geographic areas. For more information, see the “Multilanguage Site
Hierarchies” section later in this chapter.
Operations scheduled at night in one SMS site might conflict with operations of a child or parent
site in another time zone. By coordinating SMS scheduled activities among time zones, you can
reduce the possibility of scheduling conflicts. Be aware of international policies and procedures
that affect your hierarchy design.

Organizational Structure
Your organizational structure can affect hierarchy design. You might have reason to define site
boundaries based on organizational division. For example, you might logically group resources
based on organizational units, billing departments, or scope of control.
252 Chapter 8 Designing Your SMS Sites and Hierarchy

Also, consider who will access the data that SMS generates and which SMS sites should display
discovery and inventory data. Because this data flows up the hierarchy, consider business needs
for data being gathered at particular levels or sites in the hierarchy.

Note
Some SMS data flows down the SMS hierarchy and some flows up. For more
information, see Chapter 2, “Understanding SMS Sites.”

Information Technology Organization and Organizational Policy


Whether computer management in your organization is centralized or decentralized helps you
determine how many secondary sites and tiers to include in your SMS hierarchy. Depending on
the scope of control, each IT management location is likely to require a primary site. Locations
that do not have local IT administration are good candidates for hosting secondary sites.
Consider the help desk model of your organization. If you use a central help desk for your entire
organization, and you want your help desk personnel to use the central site server to access
resource information for the entire organization, you might design a deep hierarchy. Or, if you
have multiple help desks, each of which is responsible for different departments within your
organization, you might distribute the workload for help desk personnel across multiple primary
sites in a flat hierarchy. This design gives you more sites that can perform help desk operations.
SMS clients report to sites that service their particular department, provided that the departments
do not span slow or unreliable network links.
Other IT policies can also affect site design. For example, consider what your expected system
response times are, as specified in service level agreements in your organization. Every tier in the
hierarchy increases the time it takes for configuration changes to be sent up and down the
hierarchy. For example, the greater the depth of your hierarchy, the longer it takes for status to
flow up and for advertisements to flow down. Remember this when you analyze bandwidth
capacity and expected response times.
Consider who will control the SMS deployment. Hierarchy design and deployment must be
carefully controlled because rogue SMS sites and hierarchies can seriously disrupt operations of
your production SMS deployment. If organizations do not allow servers to be installed in
locations that do not have an onsite administrator, then you cannot install SMS sites at these
locations.
Data Flow
Your hierarchy design directly affects how SMS data flows, such as how sites report data to one
another. Most data flow can be controlled between sites but not within sites. This affects how you
design the parent-child relationships in your hierarchy. The type of site servers deployed in an
SMS site depend on network topology and remote management needs. Large numbers of
advertised programs, or frequent hardware and software inventory intervals, can increase the
network traffic between the sites in your hierarchy. This traffic affects the network links that
connect the sites in your hierarchy. If you carefully schedule SMS activities and spread the load
by implementing multiple sites, you might be able to distribute the load more evenly on your
network.
Designing SMS Sites and the SMS Hierarchy 253

Resources Available for Implementing SMS


Personnel and budget limitations can affect your SMS hierarchy design. Your organization must
have the workforce resources necessary in the appropriate locations to deploy, support, and
maintain the SMS hierarchy that you design. For example, secondary sites are appropriate in
locations that lack IT resources. Budget constraints can impose limits on your hierarchy and site
design. Determine how many new servers you can afford, which existing servers can support or
be upgraded to support SMS services, and whether to combine site system roles on servers that
have more processing power.
Consider your hardware budget. Each tier in a hierarchy processes all the objects of the sites
below it. As you continue to add clients at lower tiers in the hierarchy, each set of site servers
requires progressively more processing power than those in the tier below it.

Note
To manage the level of processing power needed at each tier of the
hierarchy, you can control which data is propagated to higher tiers. Part of
hierarchy design is determining which data to propagate to the central site
and which data to filter out.

Legal Policies
Legal relationships among the suborganizations that the hierarchy spans can affect hierarchy
design. For example, you might be required to create isolated SMS sites for your organization’s
finance department or for a partially owned subsidiary. Your organization’s policy might
mandate that its information be contained in separate databases. It is difficult to completely
isolate suborganizations within a single hierarchy. To ensure legal compliance, plan your security
requirements simultaneously while designing your SMS hierarchy. For more information, see
Chapter 12, “Planning Your SMS Security Strategy.”

Technical Considerations
Technical considerations have an extensive effect on your hierarchy design. The most important
considerations are listed here. As you examine the considerations, determine their where they are
relevant to your situation and, if so, their relative priority in your design planning.
Previous Installations and Interoperability
Your organization’s history of systems management can affect how you design your SMS
hierarchy today. You might already have computers grouped into sites that you choose to use as
SMS 2003 sites. Also, if you are running any platforms that are not supported by SMS 2003,
such as Novell NetWare, Microsoft Windows® 95, Windows Millennium Edition, or the Alpha
processor, consider whether to upgrade these platforms now or to exclude them from your
SMS 2003 deployment.
254 Chapter 8 Designing Your SMS Sites and Hierarchy

If you have an existing SMS 2.0 infrastructure in place, it affects your hierarchy design. If, for
interoperability reasons, you must maintain an SMS 2.0 site in your SMS 2003 hierarchy
indefinitely, then design a hierarchy that accommodates that site. For more information about
interoperability issues, see Chapter 6, “Understanding Interoperability with SMS 2.0.”
Capacity and Performance
The SMS sites and hierarchy you design need to be able to scale up as your organization grows.
For example, if your organization plans to add more remote offices to its infrastructure, you
might need to deploy more SMS sites later. Or, your organization might anticipate adding more
clients to already existing SMS sites. This knowledge encourages you to consider future capacity
needs when planning for server capacity and performance. Growth expectations affect how deep
or flat your planned hierarchy is and how many sites you implement in your SMS hierarchy. For
more information about capacity planning, see Chapter 9, “Capacity Planning for SMS
Component Servers.”
Network Topology
Your network infrastructure, and its associated constraints, influence hierarchy design. The SMS
site boundaries you define, and which clients are included in each site, are affected by all of the
following:
u Connection speed and reliability
u Available bandwidth
u Line quality
u Latency
u Peak usage patterns
SMS requires a fast, reliable network link for all processes that interact between SMS site
systems, the SMS site database server, and SMS site servers. The recommended design is to have
an SMS site at the end of a WAN link that contains clients you want to manage. This can be a
secondary site, which requires fewer resources than a primary site and can be remotely
administered. It is better to have a secondary site server share the workload with an existing
server than to have site systems connect over slow network links.

Client Environment
Consider the number of computer resources that must be discovered and supported as SMS
clients, both now and as your organization grows. In general, the site’s performance is better if it
has fewer resources to manage. Also, managing laptops with SMS affects the placement of
management points and how to define roaming boundaries.
Designing SMS Sites and the SMS Hierarchy 255

Active Directory Site Structure


Active Directory® implementation directly affects how you define SMS site boundaries, because
you can use Active Directory site names as SMS site boundaries. SMS collections that are used
to distribute software and perform other SMS functions can be categorized by Active Directory
group, container, or organizational unit. Also, SMS has limitations across Active Directory
forests. Be aware of these considerations as you design your SMS sites and hierarchy. For more
information, see the “Active Directory Considerations” section later in this chapter.
Server Environment
You might choose to assign SMS site system roles to existing servers in your infrastructure.
Backup and recovery strategies for production servers might also affect server locations and the
number of servers. For more information about your server needs in a recovery scenario, see
Chapter 13, “Planning for Backup and Recovery.”

Important
If you have any existing servers running the Windows Cluster Service, be
sure to investigate SMS 2003 interoperability with Windows Clustering in the
downloadable white paper at http://www.microsoft.com/smserver.

Remote Access Servers


SMS 2003 includes support for client computers connected to slow and unreliable links, such as a
dial-up connection to a remote access server. It is recommended that you assign these clients to
an SMS site that is well-connected to the remote access server serving the client connections.
Domain Models and Security
Security policies, including Windows security, folder structure, and account policies, can affect
site design. It is critical that you address these security issues when designing your sites and
planning your SMS deployment. For more information, see Chapter 12, “Planning Your SMS
Security Strategy.”
After carefully reviewing all business and technical considerations that affect your SMS
implementation, rank them in order of priority. When making design decisions, these prioritized
considerations help you meet the requirements you identified in the pre-planning phase.
256 Chapter 8 Designing Your SMS Sites and Hierarchy

SMS Site and Hierarchy Design


Determine what types of SMS sites fulfill your needs at each location in your enterprise. Begin
by planning your SMS site boundaries.

Important
Now is the time to begin managing risks. When you proceed with your
design, make a list of potential risks to test and review in your test lab. It is
equally important to think through the implications of your choices when
making design decisions. If you are not sure of potential design implications,
put those on your list too. You can address these issues when you review
your design. For more information about risk management, see Chapter 7,
“The Pre-Planning Phase.”

When developing your SMS site design, depending on your WAN configuration, you will
probably notice that you have many similar sites. For example, you might have:
u Several primary sites that have approximately 10 child sites.
u Several secondary sites that have approximately 25 clients.
u Several sites that have a large number of help desk personnel for support.
Look for similarities like these and determine a standard configuration for each type of site you
plan to deploy.

Planning Site Boundaries and Roaming Boundaries


Because the boundaries of an SMS site are defined by IP subnet or Active Directory site name,
most SMS sites are mapped to your physical network topology.
Planning site boundaries involves deciding which resources and subnets to include in each site.
Each SMS client is assigned to a single SMS site. Legacy Clients must exist within the site
boundaries as defined. If this condition is not met, the Legacy Client software might be removed
from client computers. Advanced Clients, however, are explicitly assigned to a site according to
the site code. This assignment is independent of site boundaries. Multisite client assignments are
not supported in SMS 2003.
One method of gathering information about resources in your organization is to initiate discovery
in SMS without initiating client installation. For more information, see the “Initiating Discovery
Without Initiating Client Installation” section in Chapter 10, “Planning Your SMS Deployment
and Configuration.”
Designing SMS Sites and the SMS Hierarchy 257

The subnets included in your site boundaries should be connected with reliable links so that all
resources in the site have a fast connection to all other site resources. As a rule, if two subnets are
separated by a slow link, do not include them both in
Supernetting the same site. Instead, create a separate SMS site at each
Classless interdomain routing (CIDR) physical location. If the physical location contains many
uses a single IP address to designate users, contains users with very different needs, or has
many unique IP addresses. CIDR is more than one group manages the computers, you might
also called supernetting.
split a single physical location into more than one SMS
Supernetted IP subnets are not
supported as SMS 2003 site site.
boundaries. To take advantage of Computers must be members of a domain to be included
any subnet grouping technologies in in SMS site boundaries. Workgroup computers are not
SMS, such as supernetting, you must
use Active Directory site names for
supported in SMS.
your site boundaries instead of IP Because site boundaries generally reflect the layout of
subnets. For information about your enterprise, use the network diagram you created in
supernetting, see the Windows 2000
the pre-planning phase when considering where to set
Resource Kit.
your site boundaries. Your diagram identifies the
number and types of users on each local area network (LAN) and WAN. Evaluate how to build
the existing subnets into the separate sites based on link speed. Also, consider the location of the
domains in your site, because you can enable resource discovery by domain, which is a reliable
way to find all computers while using little overhead.
If a client is located within the site boundaries or roaming boundaries of its assigned site, it
accesses available software package files locally. Otherwise, the client accesses the content as if
it were remotely connected (that is, using the download and run method of software installation
instead of run from network method). For more information, see the “Roaming Boundaries for
Advanced Clients” section later in this chapter.
Site-wide Settings
When you plan your site boundaries, consider the fact that the site settings you configure for
client agents, components, discovery methods, installation methods, and other features apply to
all of the clients you assign to that site.

Note
In some cases, you might want some clients within a site to have
configurations that are different from other clients in the site. For example,
you might want the Remote Tools Agent to require user permission on
desktop computers only and not on your servers. With an Active Directory
Group Policy or registry modification, the user permission setting can be
overridden for the servers in your site. For more information, see the “Clients
with Special Configurations” section in Chapter 4, “Understanding SMS
Clients.”

Roaming Boundaries for Advanced Clients


Roaming boundary planning is an important component of site design because the roaming
boundaries you specify designate how software is distributed to Advanced Clients.
258 Chapter 8 Designing Your SMS Sites and Hierarchy

SMS site boundaries determine which resources the SMS site manages. Roaming boundaries
enable SMS software distribution to Advanced Clients. For this reason, plan to define roaming
boundaries in SMS sites where Advanced Clients need to access advertised programs. Roaming
boundaries are also used in the site assignment of Advanced Clients and to configure protected
distribution points.
If a client roams to a location that has no roaming boundaries defined, that client reverts to its
assigned site’s management point and distribution point. In this scenario, the client treats the
distribution point as a remote distribution point.
Avoid creating overlapping roaming boundaries. If an Advanced Client is within the roaming
boundaries of more than one site, the client might not communicate with the correct site.

Important
In an Active Directory environment, each SMS site server publishes its list of
roaming boundaries in Active Directory. To obtain the full benefits of
Advanced Client roaming, you must have Active Directory deployed — and
the Active Directory schema extended for SMS — in your site. This allows
your Advanced Clients to perform global roaming. In the absence of
Active Directory, your SMS clients are limited to regional roaming. For more
information about roaming, see Chapter 2, “Understanding SMS Sites,” and
Chapter 4, “Understanding SMS Clients.”

When you plan your site and hierarchy design, it is important to understand how roaming
boundaries differ from site boundaries:
u Site boundaries are composed of IP subnets and/or Active Directory site names and define
which resources the site manages.
u Roaming boundaries are used by Advanced Clients to access distribution points that can
provide them with advertised software packages.
u Roaming boundaries are similar to SMS site boundaries because they can be defined by IP
subnets and Active Directory sites. However, you can also use IP address ranges to define
roaming boundaries. This is beneficial to SMS clients that connect to the network by way of
remote access or a virtual private network.
u By default, site boundaries are included in the site’s roaming boundaries.
For more information about site boundaries and roaming boundaries, see Chapter 2,
“Understanding SMS Sites.”

Note
When determining your site boundaries, consider the location of your client
access points (CAPs), distribution points, management points, and server
locator point relative to the clients that will use them. Be sure that stationary
clients can access these site systems using fast, reliable links. For
information about creating CAPs, distribution points, management points,
and server locator points as site systems, see the “Assigning Site System
Roles” section later in this chapter.
Designing SMS Sites and the SMS Hierarchy 259

Client Management Needs


When designing your SMS hierarchy, remember client management needs, because you will use
SMS to service and manage client computers. SMS clients interact with the following SMS
servers:
u Client access points
u Management points
u Distribution points
u Server locator points
You must establish management points for site communications with Advanced Clients and
CAPs for site communications with Legacy Clients. You can also include a server locator point
in your hierarchy design to help clients find CAPs. Consider using a server locator point for
determining assigned site codes for Advanced Clients if Active Directory is not enabled. Install
the server locator point only in a primary site. Plan to make distribution points available to your
sites for storing software packages to be distributed to clients.
It is recommended that you do not deploy clients to locations that do not have locally available
site servers, CAPs (for Legacy Clients only), and distribution points. SMS requires a fast, reliable
link for all processes that interact between CAPs, distribution points, and site servers. Customers
who must deploy a small number of SMS clients in a site without a local site server must
understand the performance risks involved.
Number of clients assigned to an SMS site
There are several different factors that affect the maximum number of clients that can be
managed by a site. These include SMS site server hardware specifications, site server load
signatures, and the number and types of SMS features enabled. Scheduled intervals for SMS
tasks to be performed on clients (such as inventory and software distribution and the amount of
inventory that you configure SMS to collect) are also factors.
For information about determining the number of clients you can assign to one SMS site, see
Chapter 9, “Capacity Planning for SMS Component Servers.”
Client types
The type of client you install in each site affects the location of your CAPs and management
points.
Advanced Client The Advanced Client is the preferred SMS 2003 client. It is designed for
computers running Windows 2000 and later. Deploy the Advanced Client where possible. Some
considerations for the Advanced Client when designing your sites are as follows:
u If you have Advanced Clients reporting to a site, you must make a management point
available to those clients.
u Advanced Clients are assigned to primary sites, not to secondary sites.
u An Advanced Client is assigned to only one site.
260 Chapter 8 Designing Your SMS Sites and Hierarchy

u For regional roaming, the Advanced Client benefits from the use of local distribution points,
even if the client is not assigned to the local site. However, in the case of global roaming, the
client can use only local distribution points, which requires Active Directory. Be aware of
limitations across forests and other considerations, which are described later in this chapter.
u In particular, the Background Intelligent Transfer Service (BITS)-enabled transfer of
packages, transfer of inventory, and updates of clients mean that software distribution and
client upgrades do not have an adverse effect on the clients at remote locations.
u With BITS enabled, the Advanced Client is able to send and receive files in any situation in
which an HTTP link can be established. This includes using a virtual private network. Also,
BITS can handle priority requests. For example, if BITS has started transferring a large
Microsoft Office XP package, but SMS generates a delta inventory, the inventory
momentarily interrupts the package download so that it can be uploaded.
u The use of the Advanced Client through a proxy server that performs network address
translation is not supported.
u If Active Directory is not available, or if you do not plan to extend the Active Directory
schema for SMS, establish a server locator point at a primary site in your hierarchy. This
enables your Advanced Clients to use automatic site assignment.
Designing SMS Sites and the SMS Hierarchy 261

Figure 8.3 shows two Advanced Client laptops traveling away from their assigned site servers in
Chicago and New York to Milan. Note that these laptops still communicate with the management
points at their assigned sites, but they receive software distributions from the local SMS site.
Figure 8.3 Legacy Client and Advanced Client management with management
points and client access points

Legacy Client The Legacy Client is designed for computers that are required to run Microsoft
Windows NT® 4.0 or Microsoft Windows 98. Some site design considerations are as follows:
u Because Legacy Clients are managed by CAPs, you must plan to install a CAP in each site
that has Legacy Clients.
u You can install a server locator point at a primary site in the hierarchy to help your Legacy
Clients locate CAPs.
262 Chapter 8 Designing Your SMS Sites and Hierarchy

Common client activity cycles


Most client activity depends on the SMS components you enable and the intervals of time you set
for running those components. As a result, the impact of client activity generated by SMS can
vary greatly.
When designing your sites, take into consideration the following feature-related client activity
cycles:
u Heartbeat Discovery
u Hardware and software inventory
u Polling for new advertisements (software distribution)
u Running an advertisement (software distribution)
u Status reporting, configuration verification, and client software updating
For an overview of SMS client activity cycles and how your clients are affected by the values
you set, see Chapter 4, “Understanding SMS Clients.”

Active Directory Considerations


Because Active Directory sites are based on physical network segments, the recommended
method of defining your SMS site boundaries is to base them on your Active Directory sites. This
allows SMS administrators to split or combine IP boundaries based on logical, not physical,
criteria. One advantage to using Active Directory sites as SMS sites is that subnet changes or
additions made within an Active Directory site do not require additional configuration in
SMS 2003. Subnet changes are automatically reflected within your Active Directory site
boundaries for SMS. Remember that Active Directory discovery methods can only be used to
discover clients whose site boundaries are defined by Active Directory site names.
Be aware that a single SMS site cannot span multiple Active Directory forests, although it can
span multiple domains within a single forest. All SMS site systems must be in the same
Active Directory forest as the SMS site server. For general information about multiple forest
considerations, download the white paper at http://www.microsoft.com/downloads. Be aware of
limitations across forests and considerations in the following areas when you design your SMS
hierarchy:
u Communications within an SMS site
u Site-to-site communications
u Client communications
u Secure key exchange
Communications within an SMS site
Communication between an SMS site server and its site systems is not supported across forests.
This includes communications between the SMS site server to the SMS site database server. Plan
your hierarchy design so that all SMS site servers, including the SMS site database server, and all
site systems and SMS clients are within the same forest.
Designing SMS Sites and the SMS Hierarchy 263

Site-to-site communications
Site-to-site communications have limitations across forests. A child primary site in one forest can
attach to a parent in a different forest. A child secondary site cannot attach to a parent in a
different forest. Data is sent up the hierarchy from a child primary site to its parent site. For site-
to-site communications to work, the SMS addresses at the sending site must have access to the
receiving site and vice-versa. If one or more of the forests is running in Windows 2000
Active Directory mixed mode or if Windows Server 2003 Active Directory is using the interim
domain functional level, you must specify user accounts as addresses for site-to-site
communications to work.
Windows Server 2003 and site communications
Communications across forests work in SMS if the following conditions are met:
u You are using the Microsoft Windows Server™ 2003 family
u The forest functional level is set to Windows Server 2003
u SMS is running in advanced security mode
u The forests are configured with a transitive trust
The forest functional level can be set to Windows Server 2003 only if all of your domain
controllers are running an operating system in the Windows Server 2003 family. If the forest
functional level is set to Windows Server 2003, then creating additional accounts is not required
for SMS site-to-site communications to work. For more information about forest functional
levels, see the Windows Server 2003 family documentation.
Client roaming across Active Directory forests
Without Active Directory, client roaming is limited to regional roaming (roaming to lower level
sites in the SMS hierarchy). With Active Directory, Advanced Clients can perform global
roaming within the forest of their assigned site (roaming to higher level sites or sibling sites
across the hierarchy).
If the SMS hierarchy is distributed among multiple Active Directory forests, the Advanced Client
cannot roam outside the forest that contains the client’s assigned site unless WINS is enabled. In
this scenario, WINS is required for the client to locate the resident management point. If WINS is
enabled, roaming Advanced Clients are able to communicate with resident management points to
receive distribution point location information. For information about roaming, see Chapter 2,
“Understanding SMS Sites.”
Secure key exchange
Another limitation across forests is that there is no secure key exchange by way of
Active Directory across forests. For more information about domain trusts, forest trusts, and key
exchange, see Chapter 5, “Understanding SMS Security.”
264 Chapter 8 Designing Your SMS Sites and Hierarchy

Windows NT Domain Requirements


If you plan to have SMS 2003 sites in Windows NT 4.0 domains in your environment, be sure
that all of the SMS components are contained within a Windows NT domain and WINS is
enabled for the domain. Although an SMS site cannot be distributed among multiple
Windows NT domains, the SMS hierarchy can. The support for SMS in Windows NT domains is
similar to that of Active Directory forests. Global roaming, however, is not supported across
Windows NT domains. Regional roaming requires WINS.
Naming SMS Sites
It is a good practice to develop a logical site code and naming convention strategy. With
consistent naming conventions, administrators can use the site codes to locate the parent-child
relationships within the hierarchy. This is also useful for support and recovery issues. Do not use
the same SMS site code in more than one location in your enterprise.

Important
SMS site codes cannot be changed after they are created. Be sure to
carefully plan your site codes and site names before deploying the SMS
hierarchy. It is important to follow your organization’s naming convention
policy when designing your SMS hierarchy. You should avoid using extended
characters in site code names.

If you are using Active Directory, your Active Directory site names must use only valid
characters. The Active Directory naming convention requires that Active Directory site names
are legal Domain Name System (DNS) names. Otherwise, SMS will not recognize those
Active Directory sites. Only use the standard characters A–Z, a–z, 0–9, and the hyphen (-) in site
names. For more information about creating Active Directory sites, see the Windows 2000 Server
Deployment Planning Guide.

Important
Do not use MS-DOS directory names that are not valid for your SMS site
codes, such as AUX, PRN, NUL, or CON. Although you might not encounter
problems during the SMS site installation, you can experience problems
later if the SMS site code is used as a folder name.

Determining the Locations and Types of Site Servers


Part of the design process is planning your central site, primary sites, and secondary sites, if
necessary. To do this, you must understand parent-child relationships, how many clients each site
will have, and how the sites communicate with one another. By determining the locations of your
primary and secondary sites, you are effectively designing the hierarchy itself.
Designing SMS Sites and the SMS Hierarchy 265

When you design your sites, consider how you will link them in a hierarchy, based on how each
SMS site fits into your project scope and objectives. Carefully balancing usage patterns against
available hardware resources is critical to the success of your hierarchy design. It is important
that you decide where to install the SMS Provider and Microsoft SQL Server™ before installing
an SMS site.
Management Scope and Parent-Child Site Relationships
Sites near the top of the hierarchy store information about sites lower in the hierarchy. With
proper permissions, administrators at the top sites can manage all computers at their sites and at
all sites beneath them in the hierarchy. Make sure that administrators at each level have a
legitimate need to manage the sites beneath them in the hierarchy. If possible, when you design
the site infrastructure, have each site report to the parent primary site that has the greatest need to
directly administer the site. This is especially important for secondary sites, which rely
completely on their parent sites for management. This approach might not always be practical,
but it is an important design goal.
Primary and Secondary Site Decisions
Plan your primary site locations and determine whether you need secondary sites in your
hierarchy. Remember that secondary sites report up to primary sites and do not have SQL Server
installed locally. Also, an SMS site running in advanced security mode cannot report to an SMS
site running in standard security mode. SMS administrators, using the SMS Administrator
console, administer secondary sites remotely. Secondary sites can be placed on both the LAN and
in remote locations, such as remote offices that do not have IT staff.
All site systems within an SMS site need to be well-connected. The recommended design is to
always have an SMS site at the end of a WAN link because, for site-to-site communications,
SMS provides bandwidth scheduling, throttling, and data compression. This site can be a
secondary site, which requires fewer resources than a primary site.
Determining the number of child sites per parent
When you are planning how to group child sites in the SMS hierarchy, do the following:
u Optimize your management plan by effectively grouping child sites.
u Take into account how communication between sites affects design.
u Review your plan for performance weaknesses and excessive costs.
Optimizing your management plan
One common method that is used to group sites is by company division. Leaders in each division
might want to manage their own software distribution because they have the clearest
understanding of the division’s internal needs. This can also reduce the load levels on the site
systems. For example, the manufacturing division wants to distribute quality control software to
its client computers, and the sales division wants to distribute sales support tools to its client
computers. You can set up one SMS site that includes the manufacturing division, and another
site that contains the sales division. This prevents a large, unnecessary load that can occur when
the central site distributes all the organization’s software to all the sites and clients in the
hierarchy. If the sales division reports to a different site than the manufacturing division, then the
software distribution load will be balanced between sites.
266 Chapter 8 Designing Your SMS Sites and Hierarchy

Another way to group sites is by region. Grouping sites by region can reduce the cost of the site-
to-site links by reducing the distance between sites. Also, many organizations have faster links
available within local regions. A regional grouping can also reduce the software distribution load.
For example, if a company distributes updates to the inventory database, the sales force for the
Southeast region might not require updates for local inventory for the Northwest region. On a
large scale, the primary site for South America might not need to distribute the Greek version of
Microsoft Office, but the primary site for the Mediterranean region would.
These two strategies are not mutually exclusive, however. You might create sites according to
work function within a region, for example.
Site communications
Communications between sites requires SMS senders. When planning your deployment,
determine which types of senders you will implement. For more information, see Chapter 10,
“Planning Your SMS Deployment and Configuration.”
Performance, server sizing, and cost issues
Performance is measured by system resources that are used as data is processed. Performance can
be increased by increasing throughput efficiency.
Proper server sizing ensures that your hierarchy design provides a scalable solution — one that
can adapt to increased demands without a