SMSCPDG

Concepts, Planning, and Deployment Guide
Microsoft Systems Management Server 2003
Scalable Management for Windows-based Systems
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Discovery and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Legacy Client Installation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Client Installation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site System Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PART 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 2 Understanding SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parent-Child Site Relationships and the SMS Hierarchy . . . . . . . . . . . . . Site Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roaming and Roaming Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchy Modeling Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flat vs. Deep Hierarchy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building the SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Senders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 3 Understanding SMS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collections and Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware and Software Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Update Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14 14 14 15 15 16 16 17 17 17 18 19 21 23 24 24 25 27 31 32 42 43 44 47 47 47 49 51 53 55 62 72 79 84 88 90 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Advanced Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Standard Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Accounts and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Complete List of SMS Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Server Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Database Accounts and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Accounts Through Site Setup and Site Reset . . . . . . . . . . . . SMS Object Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The SMS Object Security Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing SMS Object Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Feature Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Query and Report Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Remote Tools Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Distribution Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inventory Collection Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 6 Understanding Interoperability with SMS 2.0 . . . . . . . . . . . . . . . . . Administering a Mixed-Version Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interoperability of SMS 2.0 Features with SMS 2003 Features . . . . . . . . . PART 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 7 The Pre-Planning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 1 Understand the Methodology and the Risks . . . . . . . . . . . . . . . . . . . . . The Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 2 Analyze Your Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Previous Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geographic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IT Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
143 144 146 147 148 150 152 153 166 172 174 178 180 180 182 188 191 193 194 198 209 211 213 213 216 218 220 221 221 222 223 224 227 228 231 231
Contents vii
Step 3 Analyze Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identify Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assessing Time and Budget Allotments . . . . . . . . . . . . . . . . . . . . . . . . . Step 4 Assemble the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Occupation Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 5 Begin Assembling the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 6 Learn SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Groups to Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Training Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 7 Establish Test Lab Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 8 Designing Your SMS Sites and Hierarchy . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing SMS Sites and the SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . Business and Technical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Site and Hierarchy Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Site Boundaries and Roaming Boundaries . . . . . . . . . . . . . . . Determining the Locations and Types of Site Servers . . . . . . . . . . . . . . Assigning Site System Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advantages of Multiple Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multilanguage Site Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrade and Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing and Testing the Design in the Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . Changes to Hierarchy Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Lab Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Minimum Recommended Configuration . . . . . . . . . . . . . . . . . . . . . . . . . Standard Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Duplicating Network Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Design Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample Design Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
232 232 234 234 235 237 238 240 242 242 243 243 244 247 248 250 251 251 253 256 256 264 269 278 279 280 280 281 281 281 282 282 283 283 283 283 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 . . . . . . . . . . . . . . . . . . . . . . . . Capacity Planning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modeling Principles for Sizing and Capacity Planning . . . . . . . . . . . . . . Performance and Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Activities That Affect SMS Server Performance . . . . . . . . . . . . . . . . . . . . . Server Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sizing SMS Component Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Expectations and Service Level Agreements . . . . . . . . . . . . . . . Methods and Formulas Used to Determine Server Capacity . . . . . . . . . Determining Site Server Hardware Requirements . . . . . . . . . . . . . . . . . CHAPTER 10 Planning Your SMS Deployment and Configuration . . . . . . . . . . . Strategies for Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High Level Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key Elements of a Successful Deployment . . . . . . . . . . . . . . . . . . . . . . . Sample Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware and Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Site Server Deployment Considerations . . . . . . . . . . . . . . . . . . . . . SMS Site Database Server Considerations . . . . . . . . . . . . . . . . . . . . . . . SMS Administrator Console and Related Tools . . . . . . . . . . . . . . . . . . . Setup Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain and Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetBIOS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an SMS Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an SMS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Site Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaching SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Which Client Type to Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 291 292 294 294 296 299 299 304 309 309 309 313 325 326 326 327 330 333 334 335 338 341 342 342 345 346 347 347 348 358 358 362 363 363
Contents ix
Developing Strategies for Discovery and Client Installation . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choosing a Discovery Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Discovery and Client Installation . . . . . . . . . . . . . . . . . . . . . . Deploying SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Clients to SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Performance Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Remote Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Design and Making Changes . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Hierarchy Design Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . Burst and Recovery Effects on Design . . . . . . . . . . . . . . . . . . . . . . . . . . Total Processing Time and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dismantling the Pilot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 11 Planning an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing to Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrade Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconsider SMS Objectives During Upgrade Planning . . . . . . . . . . . . . Determine the Effect of the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . In-Place Hierarchy Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overnight Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phased-site Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Side-By-Side Hierarchy Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a Transition Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restricting Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deciding When to Upgrade a Flat Hierarchy . . . . . . . . . . . . . . . . . . . . . . Upgrading Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replacing Secondary Sites with Protected Distribution Points . . . . . . . Replacing Multisite Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Clients by Attrition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finalizing Your Upgrade Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
364 364 366 372 374 381 387 388 389 390 392 392 392 393 393 394 394 395 396 397 398 399 404 405 405 406 406 407 414 415 415 416 417 417 418 419 420
x Contents
Post-upgrade Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unsupported SMS Features and Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . SMS 2003 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 12 Planning Your SMS Security Strategy . . . . . . . . . . . . . . . . . . . . . . . SMS Security Planning Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Security Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General SMS Security Planning Considerations . . . . . . . . . . . . . . . . . . . Security Considerations for Site and Hierarchy Design . . . . . . . . . . . . . Security Considerations for Planning Setup . . . . . . . . . . . . . . . . . . . . . . Planning SMS Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Optional Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Security Account Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning for SMS Account Lifecycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . Minimizing the Number of Accounts SMS Uses . . . . . . . . . . . . . . . . . . . Creating or Modifying SMS Accounts and Groups . . . . . . . . . . . . . . . . . Planning SMS Object Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Collection Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Object Security for Objects Other Than Collections . . . . . . . . Planning SMS Feature Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning to Use SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Security Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tightening SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating System Security Best Practices . . . . . . . . . . . . . . . . . . . . . . . Monitoring and Auditing SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing SMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 13 Planning for Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up and Recovering Throughout the SMS Hierarchy . . . . . . . . . . . . The Impact of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Minimizing the Risk of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Minimizing the Impact of a Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning for Backup and Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plan for Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plan for Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Develop a Backup and Archive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document the Backup and Archive Strategy . . . . . . . . . . . . . . . . . . . . . . . . .
420 420 421 425 426 427 429 430 431 433 433 434 435 442 444 453 454 454 455 455 456 457 458 459 460 460 463 464 467 467 470 472 475 475 475 476 479
Contents xi
Planning to Simplify the Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PART 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 14 Upgrading to SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Site Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing a Site for Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Primary Site Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing SMS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Secondary Site Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Secondary Site Upgrade Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Post-Upgrade Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Update Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 15 Deploying and Configuring SMS Sites . . . . . . . . . . . . . . . . . . . . . . Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setup Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SQL Server Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SQL Server Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running an Unattended Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing a Primary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Express Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custom Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing a Secondary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing a Secondary Site Using SMS Setup . . . . . . . . . . . . . . . . . . . . . . . . Installing a Secondary Site Using the SMS Administrator Console . . . . . . . Installing the SMS Administrator Console and Related Tools . . . . . . . . . . . . . . Configuring Your SMS Sites and Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Single Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Site Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extending the Active Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating SMS Containers in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 16 Using the SMS Administrator Console . . . . . . . . . . . . . . . . . . . . . . SMS Administrator Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
479 485 487 488 488 494 496 497 497 499 501 505 506 506 507 507 508 510 511 512 512 517 518 519 523 523 524 526 527 528 534 539 542 543 544
Supporting Different Versions of SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 Understanding the Console Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
xii Contents
Exploring the Console Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Items in the Details Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the SMS Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the Action and Shortcut Menus . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing and Modifying Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Import and Export Object Wizards . . . . . . . . . . . . . . . . . . . . . . . . . Starting SMS Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMS and Microsoft Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console Taskpads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Export List Views to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Print Items in the Details Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Custom Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 17 Discovering Resources and Deploying Clients . . . . . . . . . . . . . . . Enabling and Configuring Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discovery Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discovery Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heartbeat Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows User Account Discovery and Windows User Group Discovery . . . Active Directory Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing and Configuring SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Advanced Client Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automated Installation by Using the SMS Administrator Console . . . . . Initiating a Program File at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Computer Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automated Installation by Using the SMS Administrator Console . . . . . Initiating a Program File at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Clients with Insufficient Security Credentials . . . . . . . . . . . . . . . . Assigning SMS Clients to an SMS Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Advanced Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . Assigning the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
546 547 547 548 548 549 549 550 550 551 552 552 553 555 556 557 557 559 561 561 562 563 563 563 571 574 578 580 580 581 583 584 584 584 585 586 586
Contents xiii
Legacy Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Legacy Client Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading SMS Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading to the SMS 2003 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading to the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading to the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating an SMS 2003 Client to a Newer Version . . . . . . . . . . . . . . . . . . . . Updating the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing and Repairing SMS Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . Removing the Advanced Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing the Legacy Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repairing SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APPENDIX A Accessibility for People with Disabilities . . . . . . . . . . . . . . . . . . . . SMS 2003 Accessibility Features and Options . . . . . . . . . . . . . . . . . . . . . . . . . . SMS Help Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMC Navigation Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMC Navigation Mouse Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMC Main Window Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMC Console Window Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . SMS Administrator Console Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . Accessibility in Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows XP Professional and Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows 95 and Windows NT Workstation 4.0 . . . . . . . . . . . . . . . . . . . Adjusting Microsoft Products for People with Accessibility Needs . . . . . . . . . . . Assistive Technology Products for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microsoft Documentation in Alternative Formats . . . . . . . . . . . . . . . . . . . . . . . . Customer Service for People Who Are Deaf or Hard-of-Hearing . . . . . . . . . . . . . Getting More Accessibility Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TECHNICAL SUPPORT OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
586 587 588 588 588 590 591 591 592 592 592 593 593 593 594 595 597 598 598 598 599 599 600 601 601 601 602 602 602 602 603 604 605 605 607 623 625
P A R T
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 u An electronic version of the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. 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. 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. SMS Administrator Help, which provides information about how to use the SMS Administrator console to manage your sites. Release notes, which contain critical information about SMS. 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.
u u u
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 This book contains valuable information about 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. This book provides information about configuring and using SMS.
Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide
Microsoft Systems Management Server 2003 Operations Guide
These books are available in several different formats: u u u Administrator Help on the product CD (the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide only) PDF files that can be downloaded from the Web 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 rightclick 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 products 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 Bold Description 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). 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. 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. Represents examples of screen text or entries that you might type at the command line or in initialization files. Indicates a procedure.
Italic
ALL UPPERCASE
Monospace
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 u u u u u Windows 2000 Server Windows 2000 Advanced Server Windows 2000 Datacenter Server Windows Server 2003, Standard Edition Windows Server 2003, Datacenter Edition 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 Client access point Prerequisite 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. 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. To be a management point, the system must have IIS installed and enabled, and Windows 2000 SP3.
Distribution point
Management point
(continued)
System Requirements and Supported Platforms xxi
Table 0.3 Prerequisites for Site Systems (continued)

Site system Reporting point Prerequisite 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. To be a server locator point, the site system server must have IIS installed and enabled.
Server locator point
Requirements for Site Servers and the SMS Administrator Console

The minimum system requirements for running an SMS site server are: u u u A computer with an x86-based or later processor. Microsoft SQL Server 7.0 SP3 or later (required for the primary site server in standard security mode). Microsoft SQL Server 2000 SP3 or later (required for the primary site server in advanced security mode).
Remote SMS Administrator console
Table 0.4 Requirements for SMS Site Servers

Operating 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 Primary site Secondary site SQL Server 7.0 SQL Server 2000 Other SMS site system
(continued)
xxii Getting Started
Table 0.4 Requirements for SMS Site Servers (continued)

Operating 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
Remote SMS Administrator console
Primary site
Secondary site
SQL Server 7.0
SQL Server 2000
Other SMS site system
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 Legacy Client Advanced Client Installation requirement 40 MB of available hard disk space 25 MB of available hard disk space Usage requirement 40 MB of available hard disk space 25 MB of available hard disk 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 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 Legacy Client Advanced Client
(continued)
xxiv Getting Started
Table 0.6 Operating System Requirements for SMS 2003 Clients (continued)
Operating system 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 Legacy Client Advanced Client
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 Operating System Description 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 7.0 SP2 and earlier Intel IA64-based computers running SQL Server
SQL Server
(continued)
Unsupported Operating Systems and Features xxv
Table 0.7 SMS 2003 Unsupported Operating Systems and Features (continued)
Item Other Description Windows Management Instrumentation version 1.10.698 Netscape browser IP version 6 Windows XP Professional Fast User Switching Computers in workgroups 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.
SNMP Event to Trap Translator
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
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 u u u u Managing computers that roam from one location to another and connect to the network from different geographical locations Tracking deployment and use of software assets, and using this information to plan software procurement and licensing Providing IT administrators and management access to data accumulated by SMS Providing scalable hardware and software management to the growing population of computers running Windows operating systems 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 u u u u u u u u u u u u u u u u u u Collections and queries Hardware and software inventory Software distribution Software update management Software metering Remote tools SMS site maintenance and upgrade tools Reporting Product compliance Status system SMS Administrator console Advanced Client Security Active Directory Site installation Client discovery and installation Site configuration Site systems roles 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 Windows Management Instrumentation (WMI)-based hardware inventory Description SMS has been designed to use WMI (which is built into the Windows operating system) to collect inventory data. WMI is based on the 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. 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. SMS examines every configured file type for version and developer information rather than relying on file-to-product mapping databases.
Support for WMI 1.5 and later
Discovery-based software inventory
(continued)
Table 1.1 SMS 2003 Hardware and Software Inventory Features (continued)
Feature Granular file inventory search Description 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. 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).
Add or Remove Programs search
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 Rich distribution Description Software distribution can be directed to computers based on collected information including network and hardware configuration, group membership, and software installation status. 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 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.
Dynamic distribution
Courier Sender
(continued)
Table 1.2 SMS 2003 Software Distribution Features (continued)

Feature Software program removal Use of BITS technology Description SMS can be used to remove deployed software and applications from particular computers or groups. 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. 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 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. 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. When changes are made to existing software package source files, only 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. Existing SMS packages can be converted to packages that are 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. SMS 2003 can generate software packages for distribution from any 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. An SMS software package can be advertised and configured in the Add or Remove Programs in Control Panel.
Checkpoint restarts
Roaming boundaries
Download and run
Delta distribution between site servers
Convert older SMS packages to Windows Installer
Create packages from Windows Installer files
Add or Remove Programs integration
(continued)
Table 1.2 SMS 2003 Software Distribution Features (continued)

Feature Elevated rights installations Description 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. 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.
Protected distribution point
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 u u u Performing an inventory of the installed and applicable updates on managed computers. Evaluating and testing available updates. Authorizing and distributing the updates. 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.
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 Agent Software Update Reports Evaluates advertised software updates against missing or previously installed updates on an SMS client computer and installs the applicable updates. 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 Security Update Inventory Tool Description 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. Scans a client computer for installed software updates to 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.
Microsoft Office Inventory Tool for Updates
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 Persistent notification for software updates Description An icon appears in the notification area (formerly called the system 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. Provides a method to deploy mandatory updates to client computers silently. No notification icon appears in the notification area, and users with insufficient rights cannot terminate the process in Task Manager. 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. 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. 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. Allows specification of a reference computer to generate baseline software update templates, enabling faster authorization, package administration, and package deployment.
Unattended software update installation
Firewall authentication support
Scheduled installations
Dynamic package configuration
Reference computer inventory template
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.
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 u u u u Which software applications are being used and which users are running them. The number of concurrent software application usages. Actual software license requirements. Redundant software application installations. 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 Scalable Site-specific rules Offline metering Description SMS 2003 software metering is more scalable than in SMS 2.0 and can scale to large client deployments. Different rules can be set for each SMS 2003 site. A rule can also be set that flows to the entire SMS hierarchy. 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)
Table 1.6 SMS 2003 Software Metering Features (continued)

Feature Usage monitoring Description 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. 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.
Terminal Server monitoring
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 Remote Control Remote Reboot Remote Chat Remote File transfer Remote Execute SMS Client Diagnostics Ping Test Description Remotely operates a client computer from the site server. Remotely restarts a client computer. Remotely chats with a user at the Advanced Client computer. Remotely transfers files between an Advanced Client and the site server. Remotely runs commands and programs on a client computer. Remotely runs diagnostic utilities on a client computer. Remotely determines the network connection quality between a site server and a client computer.
For more information, see Chapter 3, Understanding SMS Features.
SMS Site Maintenance and Upgrade Tools

SMS 2003 offers additional tools to support SMS site maintenance and upgrade: u u u Deployment Readiness Wizard Network diagnostic tools 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.
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 u u Hardware and software inventory. Computer configuration details and status. 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.
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 u Compliance type (type of product guideline or standard) 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 u u u Component status (describes the SMS server components status at an SMS site) Site system status (describes the site systems status at an SMS site) Package status (describes software packages and distribution points status at an SMS site) 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.
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.
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 u Advanced Clients can perform global roaming 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 Active Directory synchronization Active Directory-based site boundaries Active Directory discovery Description An Active Directory structure of both clients and systems can be automatically discovered and imported. Site boundaries can be based on Active Directory site names rather than on IP subnets, which simplifies the enterprise infrastructure for enterprises that are using Active Directory and also reduces operating costs. 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.
Table 1.9 SMS 2003 Setup Features

Feature Security mode Description SMS administrators can select from standard security mode or advanced security mode depending on their organizations 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. This setting adjusts the amount of memory that is used, based on demand. SQL Server Memory option for dynamically configuring SQL Server Before changing this option, see the SQL Server product documentation for performance and tuning information. memory 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 u u u u u u Network Discovery Heartbeat Discovery Windows User Account Discovery Windows User Group Discovery Active Directory System Discovery Active Directory User Discovery Active Directory System Group Discovery
For more information about discovery methods, see Chapter 17, Discovering Resources and Deploying Clients.
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 u u Logon Script-initiated Client Installation Client Push Installation 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 u u Logon Script-initiated Client Installation Client Push Installation 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.
The Advanced Client is assigned to a site even if it does not currently reside within that sites 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 u u u u Client access point Distribution point Management point Server locator point 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.
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 u u You can now back up secondary sites. The backup control file is more user friendly and easier to use. The backup control file parser and syntax checking has also been improved. 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. Backup error logging has been improved. New tools for backup and recovery.
u u
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.
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
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
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 u u SMS Sites SMS Hierarchy 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 u u u u Site Types Parent-Child Site Relationships and the SMS Hierarchy Site Elements Site Boundaries 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 u Primary site 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 site Secondary 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.
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 u u u u u u u Site server Component server SMS site database server Client access point Distribution point Management point Server locator point Reporting point
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 u u u u u u Site server SMS site database server Client access point Management point Server locator point Reporting point 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 u u Provides specific configuration instructions and files for the Legacy Client during client installation and when changes are made after client installation. Serves as the location where Legacy Client computers check for advertisements. 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 u Provides specific client configuration details (also known as Advanced Client policy) for the Advanced Client after client installation. Serves as the location where Advanced Client computers check for advertisements.
u u
Locates distribution points for Advanced Clients. 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.

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 u u Locates a management point for the Advanced Client if the Advanced Client is configured for automatic SMS site assignment. Provides Advanced Clients with the location of the management point during Logon Scriptinitiated Client Installation and insufficient-rights installation. Provides SMS site assignment for the Legacy Client and locates CAPs during Logon Scriptinitiated 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 clients 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.

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.
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 sites 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 organizations 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 sites 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 sites 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 sites 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 clients 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.
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 u Runs the package directly from the distribution point 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 u u Does not run Downloads from a remote distribution point before running 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 wellconnected 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.
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 clients 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 Clients 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 point A Distribution point A Secondary Site C00
Client A2 Client A3 Client A1
Primary Site B00
Client A1
Client A2 Management point B Distribution point B

Wireless network, VPN or RAS dial-up
Client B1 Client A2
Secondary Site D00
Roaming boundaries of Site B00
Roaming path Site boundaries Site boundaries enabled as local roaming boundaries Remote roaming boundaries Client A3
Client B1 Management point D and distribution point D Roaming boundaries of Site D00
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 u Client A1 roams into the site boundaries of secondary site C00 where no roaming boundaries are defined. 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. Client A3 roams into the local roaming boundaries of secondary site D00. Client B1 roams into the site boundaries (also the local roaming boundaries) of secondary site D00.
Which distribution points can deliver available software content to the client and their availability Reverts to distribution point A (remote)
u u
Table 2.1 Regional Roaming Scenarios Depicted in Figure 2.3

Location where the client roams and the type of roaming boundary Site boundaries of secondary site C00, which has no roaming boundaries Site boundaries (enabled as local roaming boundaries) of primary site B00 Remote roaming boundaries of primary site B00 Which management point the client uses and the type of management point Reverts to management point A (assigned, resident) Management point B (resident)
Client A1
A2
Distribution point B (locally available) Or, reverts to distribution point A (remote) Distribution point B (remote) Or, reverts to distribution point A (remote) Distribution point D (locally available) Or, reverts to distribution point A (remote) Distribution point D (locally available) Or, reverts to distribution point B (remote)
A2
Management point B (resident)
A3
Site boundaries (also the local roaming boundaries) of secondary site D00 Site boundaries (also the local roaming boundaries) of secondary site D00
Management point D (resident)
B1
Management point D (proxy, resident)
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
Distribution point E Management point E Client G1 Roaming boundaries of Site G00 Primary Site G00
Roaming boundaries of Site E00
Primary Site F00
Distribution point G
Client G1 Client Management G2 point G Client G3
Management Distribution point F point F
Client G2 Roaming boundaries of Site F00
Wireless network, VPN or RAS dial-up
Secondary Site H00 Roaming path Site boundaries enabled as local roaming boundaries Remote roaming boundaries
Protected distribution point F
Client G3
Table 2.2 shows which management point and distribution points each client uses in each global roaming scenario depicted in Figure 2.4: u u u Client G1 roams up the hierarchy into the site boundaries (also the local roaming boundaries) of primary site E00. Client G2 logs on to the wireless LAN in the remote roaming boundaries of primary site F00. Client G3 roams into the site boundaries (also the local roaming boundaries) of secondary site H00.
Which distribution points can deliver available software content to the client and their availability Distribution point E (locally available) Or, reverts to distribution point G (remote) Protected distribution point F (locally available) Or, reverts to distribution point G (remote) Distribution point F (remote)
Table 2.2 Global Roaming Scenarios Depicted in Figure 2.4

Location where the client roams and the type of roaming boundary Site boundaries (enabled as local roaming boundaries) of primary site E00 Remote roaming boundaries of primary site F00 Which management point the client uses and the type of management point Management point E (resident)
Client G1
G2
Management point F (resident)
G3
Site boundaries (also the local roaming boundaries) of secondary site H00
Management point F (resident) because, in the absence of a 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 points 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.
Package source file requests and protected distribution points
To download or run a package program, the client sends a package source file request to its resident management point. If the client is in a set of boundaries that are configured for a protected distribution point, the management point provides the client with a list of distribution point locations that contain the requested package source files. If the client is outside of the boundaries configured for a protected distribution point, then the management point does not provide the protected distribution point to the client as a source file location.
If configured properly, protected distribution points ensure that Advanced Clients that are well-connected to an SMS site do not download packages from a distribution point located across a WAN link.
For example, you might have a primary site in your main office and a secondary site at a remote office. The secondary site boundaries are enabled as local roaming boundaries. You designate a protected distribution point at the remote office and include the site boundaries in the protected distribution point configuration. Only Advanced Clients that are in the boundaries of the protected distribution point use the protected distribution point to download or run package programs. These clients avoid using the parent primary site distribution point, unless the advertised package is not available at the protected distribution point. This can occur if you inadvertently send an advertisement to clients in the protected distribution points 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 offices 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.
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 sites 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 NYC (child site)
Primary site London (parent site and child site)
Site server SMS site database (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.
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 Site
Secondary Site
Secondary Site
Secondary Site
Secondary Site
Secondary Site
Secondary Site
Secondary 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.
Figure 2.7 Sample deep hierarchy

Central Site CH1
Primary Site
Primary Site
Secondary Site
Primary Site
Primary Site
Secondary Site
Secondary 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-tosite 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.
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 u u u u SMS Administrator console connectivity to a site elsewhere in the hierarchy. Remote Tool connectivity to clients of other sites. Communication between clients and the server locator point. Communication between Advanced Clients and their assigned management point. 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 Standard Sender Description Used in all LAN communications. Standard Sender is also used for WAN communications when routers are used to connect LAN segments. 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. 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.
RAS Senders
Courier Sender
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
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 u u u u u u u u u u u Collections and Queries Hardware and Software Inventory Software Distribution Software Update Management Software Metering Remote Tools Reporting Product Compliance Status System Backup and Recovery Network Monitoring Tools 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

SMS collects and uses a large amount of data to manage sites. That data is stored at each primary sites database. Different SMS administrative tasks require different sets of data from the SMS site database. Queries are run against the sites 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 sites 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 collections member list are referred to as the collections membership rules. Query-based collections are dynamic objects. If a resource no longer meets the collections query, it is automatically removed from the collection. And if a resource that originally did not meet the collections query has changed in a way that it now meets the collections 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 sites 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.
When SMS propagates a collection, primary child sites receive only the definition of the collection. This includes the collections 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 collections 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 u Less information is transmitted over the network. 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 sites parent site evaluates the collections 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 sites database or into another sites database. However, when running a query that was imported from another site, it runs against the current sites 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 collections 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 sites 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 sites 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 clients 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 clients 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.
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 organizations 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 sites database, and in an up-todate copy of the file that is stored on the sites 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. 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.
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. 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. The inventory data is corrupted. A client has changed sites since the last inventory collection. A client upgrades from SMS 2.0 to SMS 2003.
u u u
Because changes to inventory rules do not trigger a resynchronization on Advanced Clients, Advanced Clients have much less resynchronizations compared with the Legacy Client.
Figure 3.1 Inventory process

Central site
Primary site
Site server/ Site database server
Site server
Site database server Management point CAP Advanced Client Inventory Client Agent Legacy Client Hardware Inventory Client Agent Software Inventory Client Agent
Primary site
Site server
Site database server Management point CAP Legacy Client Advanced Client
Secondary site
Site server CAP Legacy Client
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 sites clients: u u 2. 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). SMS sends to management points the Advanced Client policy that enables the Inventory Agent on Advanced Clients.
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. 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. 4.
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. 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 sites 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 sites clients and of clients of lower sites in the hierarchy.
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 sites 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 clients computer is offline, the inventory data file is sent as soon as connectivity is re-established. 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 sites clients and of clients of lower sites in the hierarchy. You can then use any of the clients upper level sites to perform management tasks that require the clients 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 clients 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.
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 clients 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 u Custom MOF files allow you to add WMI classes that are not included in the original SMS_def.mof file. 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. 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.
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 clients 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 sites 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.
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 clients 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 collections criteria, but meet the criteria now, automatically become members of the collection. Clients that initially meet the collections 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. 2. 3. 4. 5. You distribute a program to the All Windows XP Systems collection. Only client computers running Windows XP receive the program. A few client computers running Microsoft Windows 98 upgrade to Windows XP. The newly upgraded clients automatically become members of the All Windows XP Systems collection. 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.
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 programs 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 clients 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 packages 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.
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 clients 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 sites clients will not be able to receive advertised programs until you enable the software distribution client agents on the sites 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 u u u 2. 3. 4. 5. Configure the software distribution client agents. Prepare CAPs, management points, and distribution points. Prepare collections. Prepare security.
Create packages. Specify distribution points. Create programs. Create advertisements.
Figure 3.2 Software distribution process

Central site
Primary site
Site server
(A) Management point Distribution point CAP (A) Advanced Client Software Distribution Client Agent (A) Legacy Client Advertised Programs Client Agent
Primary site
Site server
(B) Management point Distribution point CAP (A,B) Advanced Client (A,B) Legacy Client
Secondary site
Site server Distribution point
CAP
(A,B) Legacy Client
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 sites clients as follows: u u 2. SMS installs the SMS Advertised Programs Client Agent on all Legacy Clients in the site (the agent is preinstalled on Advanced Clients). SMS sends the appropriate Advanced Client policy that enables the Software Distribution Client Agent on Advanced Clients.
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. The Advertised Programs Client Agent on Legacy Clients periodically checks the CAP to determine if any advertisements are applicable to the client. u u The Advertised Programs Client Agent runs assignments automatically. 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.
4.
5.
Advanced Clients periodically check the management point to determine if any advertisements are applicable to the client. u u The Software Distribution Client Agent runs assignments automatically. 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.
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 u On Legacy Clients, the client agent connects to a distribution point and runs the specified programs command line. 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 programs command line.
If there are no package source files, the client agent runs the programs 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 noncontinuous 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. Advanced Clients manage their download cache. When Advanced Clients download package source files in advance, the package source files are stored in the clients 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. 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. 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 clients site assignment. This reduces the Advanced Clients 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 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 packages distribution point list, the package source files are compressed and sent to the child sites 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. 2. Distribute the package to the child site and to the grandchild site. This happens if the initiating site has addresses to both sites. 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.
Figure 3.3 Software distribution with and without fan-out

Central Site Central Site
Site ABC
Site DEF
Site ABC
Site DEF
Site MNO
Site PQR With Fan-out
Site STU
Site MNO
Site PQR Without Fan-out
Site STU
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 clients 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.
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 clients 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 users context, such as adding icons to the users desktop. You can create a program, which is a Windows Installer script, and configure the program to run with administrative credentials but in the users 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 u u u u u u Install software on client computers, providing different installation options for the same software. Use Add or Remove Programs in Control Panel to add or remove programs. Copy data files to client computers. Run utilities such as virus checks or disk defragmentation. Perform any function that can run from a command line. Distribute the Skpswi.dat file that clients can use to prevent software inventory collection from a specific drive or a specific directory. 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. 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.

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 u u u Software update inventory tools Distribute Software Updates Wizard Software Updates Installation Agent 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 u The Security Update Inventory Tool, which handles security software updates for software such as Microsoft operating systems, Internet Explorer, SQL Server, and Exchange. 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 u u u A list of currently installed updates and service packs. Software updates that are available and applicable. The date and time the update was posted. 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 sites copy of the security catalog or the office catalog with the latest catalogs posted by Microsoft. It updates the sites 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 clients 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 clients 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.
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 u u Displaying dialog boxes that allow users to postpone the installation. Installing the software updates. Controlling the computers 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 u u u u Creates and manages software update SMS packages. Downloads software update source files from the Internet to a specified local package source share. Distributes software update source files to specified distribution points. Creates software distribution programs for software update packages. 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.
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. b. 2. 3. 4. Sets up the synchronization host. Creates the packages, collections, programs, and advertisements for installing the software update inventory tools scanning components on the clients.
Software update inventory tools scan the SMS clients and provide information about installed and applicable software updates. Administrators use the Distribute Software Updates Wizard to assess, authorize, and deploy software updates. The synchronization host periodically updates the sites local catalogs (weekly by default) and scans components.
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 host
Inventory tools synchronization component
SMS Site Server
Inventory tools scan component
Synchronization Process
Software Update Process Software distribution
Internet Synchronization host Inventory tools scan component updates
Software distribution Clients Distribute Software Updates Wizard
Software distribution
Software Updates
Catalog updates SMS Site Server
Internet
Package source share host
Figure 3.4 illustrates the process of managing software updates. The detailed steps are as follows: 1. Starting the software update inventory cycle: a. b. c. The SMS administrator downloads from the Microsoft downloads site the Security Update Inventory tool, the Microsoft Office Inventory Tool for Updates, or both. The administrator runs the respective installer program on the SMS site server. Each inventory tool installer program creates the necessary packages, collections, and advertisements for distributing the software update inventory tools scan components to the sites clients. Each inventory tool installer program creates the necessary packages, collections, and advertisements for distributing the synchronization component to the designated synchronization host. SMS leverages the software distribution feature to distribute the software update inventory tools scan components to the sites clients. The clients run the advertised program and install the software update inventory tools scan components.
d.
e. f. 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. 5.
The Distribute Software Updates Wizard downloads from the Microsoft downloads site the source files for the specified software updates. The Distribute Software Updates Wizard stores software update source files on a specified package source share.
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. The Distribute Software Wizard copies the required source files from the package source share to the specified distribution points. SMS leverages software distribution to advertise the software updates programs to clients. 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.
7. 8. 9.
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. The synchronization host updates the local copy of software update catalogs. The synchronization host updates the packages, programs, and advertisements that are associated with the software update inventory tools scan components. SMS leverages the software distribution feature to advertise to clients the programs that update software update inventory tools scan components. Clients run the advertised programs and update their software update inventory tools scan components.
b. c. d. e.
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 u u u Deploying mandatory software updates without user interface. Defining multiple scopes for the same package, where the same package is distributed with different runtime parameters to multiple collections. Applying updates within specified beginning and end times on the Advanced Client. 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.
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 executables 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 executables 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.
Figure 3.5 Software metering process

Central site
Primary site
Site server
Site database server Management point CAP Advanced Client Software Metering Client Agent Legacy Client Software Metering Client Agent
Primary site
Site server
Site database server Management point CAP Legacy Client Advanced Client
Secondary site
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.
When you enable software metering for a site, SMS enables software metering on the sites clients as follows: 1. 2. 3. SMS installs the Software Metering Client Agent on all Legacy Clients in the site (the agent is preinstalled on Advanced Clients). SMS sends to management points the Advanced Client policy that enables the Software Metering Client Agent on Advanced Clients. 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 u Legacy Clients download these rules from the CAPs. 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. 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 sites 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.
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 sites 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 servers 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 sites set of rules consists of the sites 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.
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 clients location to provide assistance. Remote Tools give you full control over the clients computer and allows you to perform any operation as if you were physically at the clients 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 clients computer by sending mouse clicks and keyboard strokes from the SMS Administrator console. You can work with a clients computer just as if you were physically at the clients desktop. Remote Reboot, to remotely restart a clients computer. Remote Chat, to chat with a user at the Advanced Client computer. Remote File Transfer, to transfer files between an Advanced Client and your site server.
u u u
Remote Tools 85
u u u
Remote Execute, to run programs on a client computer. SMS Client Diagnostics, to run diagnostic utilities on a client. 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 clients 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.
Figure 3.6 Remote Tools process

Central site
Primary site Site server/ Site database server Site database server Management point CAP Advanced Client Legacy Client Remote tools Site server Primary site
Site server
Site database server Management point CAP Advanced Client Legacy Client Secondary site
Remote Tools 87
Remote Tools works as follows: 1. 2. SMS collects discovery data from the sites clients. 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 u Secondary sites send discovery data to their parent sites. 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 sites 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 sites clients as follows: u u 4. SMS installs the Remote Tools Client Agent on all Legacy Clients in the site (the agent is preinstalled on Advanced Clients). SMS sends the appropriate Advanced Client policy that enables Remote Tools on Advanced Clients.
You can now use Remote Tools to access a client from any of its parent sites that contains the clients 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 sites database. Because discovery data propagates from clients up the hierarchy, you can run Remote Tools to access a client from any of the clients parent sites. From the central site, which has discovery data of all the clients 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 clients 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 clients screen, instead of depending on the user to paraphrase the error message.
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 administrators 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 reports name. The primary property in a reports 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 reports 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 sites 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 clients 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.
A report can also have prompts. You can use prompts to limit the reports 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 u Software inventory data. Product compliance data.
Product Compliance 91
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 products name, the products version, and the products .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 u u Office XP is compliant with the Office standard compliance type. Office 2000 is compliant with the Office standard compliance type. 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.
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 organizations 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 sites 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.
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. 2. 3. 4. 5. Collect hardware inventory data, including data about clients hard disks. Create a query that retrieves all the clients that have at least 500 MB of free disk space. Create a client collection that is based on that query (you can perform steps 2 and 3 together). Advertise the software to that collection. 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. 2. 3. 4. 5. Collect software inventory data, including information about installed products on client computers. Create a query that retrieves all the clients that have Office 2000 or Office 97 installed. Create a client collection that is based on that query (you can perform steps 2 and 3 together). Advertise the Office XP upgrade to that collection. 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 sites 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 organizations help desk be more effective: u u u u Remote Tools Software inventory Hardware inventory 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 clients 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 clients history of hardware inventory, you can determine how the clients hardware has changed and this can help in diagnosing problems. By using the software inventory feature, you can store copies of files from the clients 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
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 u u u u u For information about how sites support roaming and how clients operate within sites, see Chapter 2, Understanding SMS Sites. 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. For detailed client deployment procedures, see Chapter 17, Discovering Resources and Deploying Clients. For information about supported platforms and configurations for SMS clients, see the Getting Started chapter. For information about upgrading clients to SMS 2003, see Chapter 11, Planning an Upgrade, and Chapter 14, Upgrading to SMS 2003. 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 u u u SMS Clients Client Deployment Client Maintenance 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 organizations 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 u Advanced Client 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.
The Advanced Client provides the following advantages: u u u u Better support for mobile computers. Better support for remote computers. Enhanced security. For more information about security, see Chapter 5, Understanding SMS Security. 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. The Advanced Client can download the package source files to the local computer before running an advertised program. 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. 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. The Advanced Client is highly scriptable, which allows for the automation of Advanced Client configuration and operations. Extensive use of Windows Management Instrumentation (WMI), which allows access to many Advanced Client internal details for troubleshooting purposes. 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. When downloading the Advanced Client software during installation, the Advanced Client installation programs continue to run even if the network connection occasionally becomes unavailable. 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. The Advanced Client is installed from a Windows Installer package, which provides all the benefits of Windows Installer.
u u
u u u
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 u Can access package source files on distribution points in a site that the client is not assigned to. 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. 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. BITS uses HTTP so that the Advanced Client can send and receive files in any situation in which an HTTP link can be established. 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. 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.
u u u
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 u You must deploy the Legacy Client when the client computer is running Windows 98 or Windows NT 4.0. 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 u The Legacy Client supports operating systems that the Advanced Client does not. 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. 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. 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. 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.
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 u When installing Legacy Clients, SMS obtains the Legacy Client software from CAPs. 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 u u u 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. An Advanced Client finds advertised programs from the management point of the site to which it is assigned. A Legacy Client finds advertised programs from the CAPs at the sites to which the Legacy Client is assigned. Clients also use CAPs and management points respectively to send inventory and status information to the site server. 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 u 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. 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. 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.
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 sites roaming boundaries the Advanced Client is located. Active Directory returns the site code of the clients 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 clients 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 Clients 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 sites 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 clients 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 u Advanced Clients use a server locator point to get information about management point that they can use to install the client. 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. Legacy Clients use a server locator point to get information about CAPs that they can use to install the client. Advanced Clients can use server locator points for automatic site assignment if Active Directory has not been extended.
u u
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 administrators discretion).
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. 2. 3. 4. Discovering resources locating computers and other types of resources on the network. Installing SMS client software installing core SMS client components on supported platforms for both client types and installing client agents on Advanced Clients. Assigning clients to sites evaluating which SMS site the computer should be assigned to, if any. 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 organizations 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 u u u u u u u u u SMS unique identifier (GUID) NetBIOS name IP addresses IP subnets Operating system name and version Domain or workgroup Last logon user name Agent name (the discovery method that generated the DDR) Active Directory container 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.
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 u u u u u u Windows User Account Discovery Windows User Group Discovery Heartbeat Discovery Network Discovery Active Directory System Discovery Active Directory User Discovery 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. 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. 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.
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. 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 Windows User Account Discovery Windows User Group Discovery Heartbeat Discovery Network Discovery Discovered resources Windows user accounts Windows user groups Computers Computers, routers, and other devices that respond to network requests Computers Users, user groups, and containers Containers for computers that are already discovered Computers serving as SMS site systems or site servers Computers Computers, users, user groups, or any other kind of resource (including new resource types) Source of discovery data Domain controllers Domain controllers The discovered computer Network devices
Active Directory System Discovery Active Directory User Discovery Active Directory System Group Discovery Site system discovery Inventory discovery Scripted discovery
Domain controllers Domain controllers Domain controllers The discovered site system Inventory data Depending on script
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 u Discover potential SMS clients. Collect resource discovery data so that the Client Push Installation method can later install client components on those resources.
u 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. 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.
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 u If the device is not active, Network Discovery does not use SNMP to contact the device. 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.
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
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.
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 u u u u u u u u Windows NT 4.0 Windows 2000 Windows XP Windows Server 2003 family Windows 95 Windows 98 Windows for Workgroups Some UNIX workstations 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.
Figure 4.3 Topology, client, and client operating system discovery

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.
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.
Figure 4.4 Router hop count

Server 1 Router C Router B 0 Router A 1 1 2 Router E Router D 1 2 2 Router F
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 u u u A database of the MAC addresses belonging to computers requesting IP addresses. The IP address of each computer. The name of each computer. 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.
The Active Directory System Discovery method gathers discovery information such as: u u u u Computer name. Active Directory container name. IP address. Active Directory site.
Active Directory System Discovery does not include the computers 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 u u u u User name. Unique user name (includes domain name). Domain. Active Directory container names. 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.
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 u u u u Organizational unit. Global groups. Universal groups. Nested groups. 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.
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 u Using the Client Push Installation method in the SMS 2003 Administrator console Initiating a program file at the client to install the client software, as follows: u u u u u Using Logon Script-initiated Client Installation Manually running a program file Using Windows Group Policy Using SMS software distribution or some other software distribution mechanism to advertise and run a program file
Installing the Advanced Client on a computer master image and imaging that computer to other computers
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 Push Installation method Client type Both How it is initiated and applied An SMS administrator enables the Client Push 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 scripts are customized to run Capinst.exe. A user or SMS administrator initiates Smsman.exe to install a Legacy Client or Ccmsetup.exe (Advanced Client Installer) to install an Advanced Client.
Logon Script-initiated Client Installation Manually
Both Both
Windows Group Policy Software distribution Imaging
Advanced Client Windows Group Policy. Advanced Client Advertising an Advanced Client installation program and then running that program. 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.
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.
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 u The SMS administrator specifies a server locator point as an argument to Capinst.exe. 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.
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.
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 computers IP subnet or Active Directory site assignment. If the computers IP subnet or Active Directory site assignment matches any sites 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.
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 sites 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 u u For Legacy Clients, the SMS client software is not installed. For Advanced Clients, the SMS client software might be installed, but the client is dormant. The Components tab, which is accessed by clicking the Systems Management icon, is empty. 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.
In Control Panel: u 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 clients 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 clients 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.
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. 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 clients local classes and instances in WMI. For more information, see the Microsoft Systems Management Server 2003 Software Development Kit. 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 clients 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 u Advertised programs that become available Advertised programs that run or count down before they run
User Control of Clients 131
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.
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 clients 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 clients 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 clients 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 clients software version, you can check WMI. The clients 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
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 organizations 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 companys 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 u u u Provides an advanced security mode that takes advantage of local system and computer accounts that are automatically maintained by the operating system Provides an Advanced Client that takes advantage of local system and computer accounts to run client-based tasks Uses hashing to ensure the integrity of software distribution packages Reduces the impact on domain controllers by eliminating the need for SMS 2.0 logon points
134 Chapter 5 Understanding SMS Security
u u u
Eliminates the requirement that the SMS Service Account have domain administrator rights Signs all site-to-site communications between SMS 2003 sites, and between SMS 2003 and SMS 2.0 sites running Service Pack 5 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 u u u u SMS Security Environment SMS Security Modes SMS Accounts and Groups SMS Object Security 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 u u u u u Operating System Security SQL Server Security Windows Management Instrumentation Security Internet Information Services Security Network Security 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 systems 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 loggedon user. For these reasons, the client side of the SMS security model does not apply to computers running Windows 98.
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 objects 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.
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 others 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.
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 users 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.
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 servers 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. 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 u u u u Use the latest version of IIS that is available. Usually this means using the latest operating system available. Apply service packs and security-related hotfixes as they become available. Disable IIS functions that you do not require. Put IIS on servers that are separate from other applications, or on servers with few other functions. 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.
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 u Packages have hash values, which SMS signs. 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 sites 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.
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. 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. 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.
Key /KEYFORPARENT Purpose How to use
Table 5.1 Preinst.exe Switches for Exchanging Site Keys

Dump this sites public key into the file Copy this file to the parent sites <sitecode>.ct4 at the root of the SMS hman.box inbox (Not drive. hman.box\pubkey) Dump this sites public key into the file Copy this file to the child sites <sitecode>.ct5. hman.box inbox. Dump this and all child sites public keys into the file <sitecode>.ct6. Dump this and all parent sites public keys into the file <sitecode>.ct7. Copy this file to the parent sites hman.box inbox. Copy this file to the children sites hman.box inbox.
/KEYFORCHILD /CHILDKEYS /PARENTKEYS
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.
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)
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 u u Install the management point, the SMS site database, and the SMS site server on same physical computer. Isolate the management point, the SMS site database, and the SMS site server on a private network and secure the private network. 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.
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 u u The local system account is local to the computer itself so the jurisdiction of the account is very limited. Only the operating system knows the password for a computer account so network users cannot use computer accounts to access network resources. 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. 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 u u SMS 2003 advanced security site reporting to an SMS 2003 advanced security central site SMS 2003 standard security site reporting to an SMS 2003 advanced security site 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 servers 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 sites 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.
3. 4.
Click Set Security on the General tab of the Site Properties dialog box. 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 accounts 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 u u u Those that are used in both advanced security and standard security Those that are used with advanced security Those that are used with standard security 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.
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 Common server and client Account name Local system Client Push Installation Common server Site Address Logged on user (logged on the SMS Administrator console) SMS Administrators Internal client group Reporting Users Common group Site System to Site Server Connection Site System to SQL Server Connection Site to Site Connection Site Database Server Locator Point Database Common database Management Point Database Web Report Application Role SMS Schema Users User or group name N/A Administrators choice Administrators choice Varies greatly SMS Admins SMSInternalCliGrp SMS Reporting Users SMS_SiteSystemToSiteServerCon nection_sc SMS_SiteSystemToSQLConnectio n_sc SMS_SiteToSiteConnection_sc sa if SQL Server account (might vary) sa if SQL Server account (might vary) sa if SQL Server account (might vary) webreport_approle smsschm_users
(continued)
Table 5.2 Complete List of SMS Server-Level Accounts (continued)

Account category Common access list Advanced security Account name Package Access Accounts N/A User or group name
Remote Tools Permitted Viewers N/A Computer SMS Service computername$ Administrators choice SMSServer_sc (can vary) Administrators choice SMSSvc_sc_xxxx SMSCCMBootAcct& SMS#_dc Varies greatly Administrators choice SMS&_dc SMSCliSvcAcct& SMSCliToknAcct& SMSClient_sc Administrators choice SMSCliToknLocalAcct&
Standard security
Server Connection Site System Connection Remote Service Client Configuration Manager (CCM) Boot Loader (Non-DC)
Common client
CCM Boot Loader (DC) logged on user (logged on to clients)
Advanced Client
Advanced Client Network Access Client Services (DC) Client Services (Non-DC) Client User Token (DC)
Legacy Client
Client Connection Legacy Client Software Installation Client User Token (Non-DC)
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.
Table 5.3 Complete List of SMS Client-Level Accounts

Account category Account name Client Configuration Manager (CCM) Boot Loader (Non-DC) Common client CCM Boot Loader (DC) logged on user (logged on to clients) Advanced Client Advanced Client Network Access Client Services (DC) Client Services (Non-DC) Client User Token (DC) Legacy Client Client Connection Legacy Client Software Installation Client User Token (Non-DC) User or group name SMSCCMBootAcct& SMS#_dc Varies greatly Administrators choice SMS&_dc SMSCliSvcAcct& SMSCliToknAcct& SMSClient_sc Administrators choice 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 accounts function, whether SMS creates the account automatically, and whether SMS requires the account. Table 5.4 SMS Common Accounts Overview
Account Local system Account type Service Function Runs SMS client and server services Created automatically? Yes Yes Required?
Client installation
Can be used by No Client Configuration Manager to install SMS client software on computers.
No, but recommended for greater security. If not specified and if the site is using standard security, the SMS Service Account is used.
(continued)
Table 5.4 SMS Common Accounts Overview (continued)

Account Site Address Account type Server connection Function Site to site connections Created automatically? No Required? Yes, for parent/child site relationships, but the site server computer account or SMS Service Account can be used for this purpose. Yes, but already exists.
Logged on user
User
To use the SMS No 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.
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 accounts location, and its function. Table 5.5 SMS Common Groups Overview
Group SMS Administrators Location The site server and the server with the SMS Provider, if different Domain controllers that are SMS clients Function Provides its members with access to the SMS Provider, through WMI. Access to the SMS Provider is required for viewing and modifying SMS security objects and data in the SMS Administrator console or using similar tools. By default, members of the SMS Administrators group on the local computer and members of the local Administrators group have WMI access. Created on domain controllers to contain the Client User Token Account and the Client Services DC Account. Windows security 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. Controls access to the SMS Reports Web site. Provides its members with access to the site server resources that are necessary for the operation of the site systems (such as CAPs, management points, and server locator points). Site system computer accounts other than distribution point computer accounts should be added to this group. Management points, server locator points, and reporting points are given access to the computers running SQL Server using this group. The database accounts should be members of this group. Site to site communications are enabled using Site Address Accounts. Those accounts should be put in this group.
Internal Client Group
Reporting Users Site System to Site Server Connection
Reporting point Site server
Site System to SQL Server Connection Site to Site Connection
Database servers Site servers
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 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 sites 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. 2. Start the SQL Query Analyzer with the SMS site database selected. Run the following queries to add the login for the machine account:
exec exec exec exec exec sp_grantlogin '<machine account>' sp_changedbowner '<machine account>' sp_grantlogin 'NT AUTHORITY\SYSTEM' sp_addrolemember 'db_owner', 'NT AUTHORITY\SYSTEM' sp_droplogin 'BUILTIN\Administrators'
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
SMS Access Account List name Package Access Accounts Are any user or user group accounts listed by default? Yes: Administrators and Users Are any accounts in the list required? Yes: Administrators
Description User accounts and group accounts with access to package source files on distribution points. User accounts and group 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).
Remote Tools Permitted Viewers
No
No
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 serverlevel 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.
Figure 5.1 SMS advanced security server connectivity

Another SMS site Site server
An SMS site Site server
Reporting Point
Distribution point
CAP Server locator point Site database SQL Server
Management point
Accounts: 1 2 3 4 Site server computer account Site system computer account Site Address Site Database
n = Optional accounts
Standard Security Server Accounts and Groups

Table 5.7 provides an overview of each server-level account associated with standard security, the accounts 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 SMS Service (SMSService) Account type Site server Function Created automatically? Required? Yes
The site server services run Yes 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). Provides SMS services running on remote site 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. Yes
SMS Server Connection (SMSServer_sitecode)
Server connection
Yes
Site System Connection
Site system Used by site server connection services for managing site systems.
No
No, but recommended for greater security. If not specified, the SMS Service Account is used.
(continued)
Table 5.7 SMS Standard Security Accounts Overview (continued)

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

The SMS Service Account is used: u u u u To provide the security context the SMS Executive service runs in. To create operating system objects (such as directories, files, and services) on the site server and the other servers it is used on. To access SQL Server, if SQL Server is accessed using Windows Authentication. 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.
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 u Client access point 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.
Figure 5.2 SMS standard security server connectivity

Another SMS site Site server
An SMS site Site server
Reporting Point
Distribution point
CAP Server locator point Site database SQL Server
Management point
Accounts: 1 2 3 4 5 6 SMS Service Site Address Site Database Server Connection (SMSServer_sc) Site System Connection Logged on user
n = Optional accounts Note: sc=site code
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 accounts function, whether SMS creates the account automatically, and whether SMS requires the account. Table 5.8 Client Account Overview
Account Account type Function Provides SMS with access to install CCM Boot Loader on non-domain controllers. Provides SMS with access to install CCM Boot Loader on domain controllers. Might be used during client installation and other steps. Used for all purposes on computers using Windows 98. Provides access to file servers for Advanced Clients on computers running Windows NT 4.0, Windows 2000, or Windows Server 2003 family operating systems Used to run the SMS Client Service on domain controllers. Used to run the SMS Client Service on non-domain controllers. Used to create user tokens on client computers that are domain controllers. Used to create user tokens on client computers that are not domain controllers. Created automatically? Yes Required? Yes
CCM Boot Loader Client (Non-DC) service (SMSCCMBootAcct&) CCM Boot Loader (DC) (SMS#_domain_ controller_name) Logged on user Client service
Yes
Yes
User
No
Yes
Advanced Client Network Access
Client connections
No
No
Client Services (DC) (SMS&_domain_ controller_name) Client Services (Non-DC) (SMSCliSvcAcct&) Client User Token (DC) (SMSCliToknAcct&)
Client service Client service Client service
Yes
Yes
Yes
Yes
Yes
Yes
Client User Token Client (Non-DC) service (SMSCliToknLocalAcc t&)
Yes
Yes
(continued)
Table 5.8 Client Account Overview (continued)

Account Account type Function Provides access to CAPs and distribution points for Legacy Clients on computers running Windows NT 4.0, Windows 2000, or Windows Server 2003 family operating systems Created automatically? Yes Required? Yes
SMS Client Client Connection connection (SMSClient_sitecode)
Legacy Client Software Installation
Client connections and advertised program installation
Provides a security context No for certain advertised programs running on computers running Windows NT, Windows 2000, or Windows Server 2003 family operating systems. This account is recommended for use when network resources that are not on the distribution point must be accessed.
No, but recommended for greater security. If this account is not specified but a program is told to run with it, the program fails to run. The default is to not to use 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 u CCM Boot Loader (Non-DC) - used on computers that are not domain controllers 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.
The Advanced Client Network Access Account must always include a domain name. Passthrough 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 u Client Service (Non-DC) for SMS client computers that are not domain controllers 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.
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.
Figure 5.3 SMS Legacy Client connectivity

SMS Site server
CAP Client
Distribution point
SMS Administrator console Accounts: 1 2 3 4 Logged on user Client push installation account SMS Client Connection account 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.
Figure 5.4 SMS Advanced Client connectivity

SMS Site server
Client
Management Point
SMS Adminstrator console Active Directory domain controller Accounts: 1 2 3 4 5 6 Logged on user Computer account Advanced client network Access account Client push installation account Anonymous htm connection Permitted viewers list
Distribution point and Non-SMS servers
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.
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.
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 u u u u SMS Server Connection Account if the site server is on a domain controller Site System Connection Account Site Address Accounts SMS Client Connection Accounts Client Push Installation Account (if used)
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.
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 nonadministrative users log on to SMS servers, they could read this file. To prevent this, remove the Users and Power Users permissions on this file.
Site Reset
SMS site reset stops the core SMS site services, removes them, and then reinstalls them. This can be done: u u u To repair a damaged site server. To make account or password changes effective. 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 u u Site reset from the SMS Administrator console. Site reset from setup. 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 u u u SMS_Site_Component_Manager SMS_Executive (only on the site server itself) SMS_Site_Backup 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 sites CAPs, and the server running SQL Server, and affects the following services: u u u u SMS_Site_Component_Manager SMS_Executive (on the site server or component servers) SMS_Site_Backup SMS_SQL_Monitor (on the site server or component server)
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 u u SMS component shutdown is completed. SMS components are flagged for reinstallation. 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.
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 SMS_Advertisement SMS_Collection SMS_Package Advertisements Collections Packages Console item
(continued)
SMS Object Security 173
Table 5.9 SMS Classes for Granting Security Rights (continued)

Object class SMS_Query SMS_Report SMS_Site SMS_MeteredProductRule SMS_StatusMessage Queries Reports Sites Software Metering Rules Status Messages Console item
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.
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 users 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 users 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 users 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 u The local system account (NT Authority/System). 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.
Table 5.10 SMS Object Security Rights

Right Administer Applies to All secured object classes Grants the ability to 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 to a collection. Subcollections to the 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 an instance of an object type. 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 an instance of an object type.
Advertise
Collection object classes and instances
Create Delegate
All secured object classes All secured object classes
Delete
All secured object classes and instances (except status message instances) Collection object class and instances Package object class and instances Site object class and instances Site object class and instances Site object class and instances
Delete Resource Distribute Manage SQL Commands Manage Status Filters Meter Modify
Delete a resource from a collection. Send packages to distribution points. Create, modify, and delete site maintenance SQL commands. Create, modify, and delete status filter rules. Apply software metering rules to the site.
All secured object classes Modify an instance of an object type. and instances (except status message class and instances, which cannot be modified)
(continued)
Table 5.10 SMS Object Security Rights (continued)

Right Applies to Grants the ability to Modify a resource in a collection. View an instance and its properties. Modify Resource Collection object class and instances Read All secured object classes and instances (except status message instances) Collection object class and instances.
Read Resource
Read a resource in a collection. Resource Explorer 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 Tools on a resource. View the files collected from a client. Resource Explorer can be used on the resource to view collected files.
Use Remote Tools View Collected Files
Collection object class and instances Collection object class and instances
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.
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.
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 sites 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 u u u Change the class and instance rights directly Use the SMS User Wizard Use the Clone SMS User dialog box 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.
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.
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 users 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 featurelevel security. This section describes additional security details for the following SMS features: u u u u SMS Query and Report Security SMS Remote Tools Security Software Distribution Security 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. 2. Add the user, or a group the user is a member of, to the SMS Reporting Users group on the reporting point. 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.
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 users 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 organizations needs. The Permitted Viewers list provides an authorization step at the client before a user can start a remote session. Asking the users 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.
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 clients 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 Administrators group, and the Domain Administrators group is included in the local Administrators group, the user cannot control the client unless the users 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 Administrators 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.
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 systems 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 users 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.
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 users 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 users permission on at least one site that the clients running Windows 98 are assigned to. You can set this option so that users 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 u u u u Remote tools sessions Remote tools client agent security settings Membership in the Permitted Viewers list Remote.exe 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 users 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.
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.
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. 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. If any trusted staff are available at the remote location, you can ask them to log you off the computer.
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 packages 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.
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.
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 users 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 u u Has access to the necessary non-SMS network resources. Has access to the SMS distribution point share and directories for the package. 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 u u User account in user context. Network Installation Account otherwise on the Advanced Client. 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.
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
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. 3. 4.
Right-click the <site code><site name> item, and then select Properties. In the <site code><site name> Properties dialog box, click the Advanced tab. 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 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 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. 2. 3. Start the SMS 2003 Administrator console. Right-click Systems Management Server in the left pane. 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.
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 u The Software Metering Server site system role is not available. The following maintenance tasks are not available: u u u u u u u u u u Export Site Database Export Site Transaction Logs Export Software Metering Database Export Software Metering Transaction Log
The software metering tool is not available. When you right-click an SMS 2.0 client in a collection, the Start Event to Trap Translator option is not available. Hardware inventory data for 16-bit clients that are assigned to an SMS 2.0 site might not be available. You cannot run the Repair Wizard by right-clicking <site codesite name> of an SMS 2.0 site, and then choosing All Tasks. 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. 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. 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. 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.
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.
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.
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. 3. 4. u
In the right pane, right-click Component Status Summarizer. Select Properties. In the Component Status Summarizer Properties dialog box, click the Thresholds tab.
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.
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 u SMS 2003 sites cannot use SMS 2.0 logon points. 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 u u CAPINST /SLP=Servername -to install a Legacy Client CAPINST /ADVCLI /SLP=Servername -to install an Advanced Client 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). 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
Logon script command Legacy Clients Windows NT 4.0 Service Pack 6 or later SMS 2003 Legacy Client Windows 2000 and later SMS 2003 Legacy Client
In this environment, SMS determines which client type to install as follows: u
Windows 95 None
Windows 98 SMS 2003 Legacy Client
(continued)
Table 6.1 Determining Client Type to Install Within SMS 2003 Site Boundaries (continued)
Logon script command Advanced Clients Platform Dependent Windows NT 4.0 Service Pack 6 or later None SMS 2003 Legacy Client Windows 2000 and later SMS 2003 Advanced Client SMS 2003 Advanced Client
Windows 95 None None
Windows 98 None SMS 2003 Legacy 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 u For the computers that reside exclusively in an SMS 2.0 site boundaries. SMS installs the SMS 2.0 client. 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 computers operating system. Table 6.2 Determining Client Type to Install Within Overlapping Site Boundaries
Windows NT 4.0 Service Pack 6 and later SMS 2003 Legacy Client SMS 2.0 Client SMS 2003 Legacy Client Windows NT 4.0 Service Pack 5 and earlier SMS 2.0 Client None SMS 2.0 Client
Logon script command Legacy Clients Advanced Clients Platform Dependent
Windows 95 SMS 2.0 client SMS 2.0 client SMS 2.0 client
Windows 98 SMS 2003 Legacy Client SMS 2.0 Client SMS 2003 Legacy Client
Windows 2000 and later SMS 2003 Legacy Client SMS 2003 Advanced Client SMS 2003 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.
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.
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. On the Installation options page, you select Advanced Client or Legacy Client, as appropriate. 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. On the Client Installation Options page, when installing Legacy Clients, you select the Always install (repair or upgrade existing client) option.
u u

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 u 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. Collections or queries cannot be imported from sites running one version of SMS and then be imported into sites running another version of SMS. 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. 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 u u A clause that references a property that does not exist in SMS 2.0, such as SystemResource - ClientType. A clause that references Active Directory organizational units or any other Active Directory objects.
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.
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. 2. 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. 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. 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.
Whether the SMS_def.mof is standard throughout the hierarchy, the following interoperability issues exist with hardware inventory in a mixed-version hierarchy: u u Hardware inventory data for 16-bit clients assigned to an SMS 2.0 site might not be available. 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 sites 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 u Software inventory data for 16-bit clients assigned to an SMS 2.0 site might not be available. 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. 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.
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. Settings on the Advanced Client tab and the Suppress program notifications check box are ignored when the program reaches SMS 2.0 sites.
u 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. Advanced Clients can download package source files from SMS 2.0 distribution points. This is supported only for Advanced Clients that roam to the sites immediate SMS 2.0 child secondary site. 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. 3.
Run the executable file. Configure the Courier Sender in the same manner as you would configure it by using an SMS 2.0 Courier Sender Manager.

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. 2. Create a new shared folder on the SMS 2.0 site server named SMS_SUIAgent. Grant Read, Read and execute, and List folder contents file rights on the shared folders to the SMS Admins security group.
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 u u 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. Upgrade the SMS 2.0 site to SMS 2003. Upgrade the SMS 2.0 software update packages to SMS 2003 software update packages (see next procedure.)
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. Rightclick Collections or Packages, select All Tasks, and then select Distribute Software Updates. On the Specify a Software Update Type page, select the type of software update for the package you are upgrading. On the Create an Update Package page, select the name of the package you are upgrading, and then click Next. If you are making no other changes to the package, go through the rest of the wizard by clicking Next, and then Finish.
2. 3. 4.
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.
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. 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 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. 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. Some of the Remote Tools settings on an SMS 2.0 client might not be compatible with the Remote Tools settings of the clients site. This can happen in the next interoperability scenario: u u An SMS 2.0 client is assigned to multiple SMS 2.0 sites. One or more of the sites that the client is assigned to are upgraded to SMS 2003, but SMS 2003 does not support the clients 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 u You cannot use SMS 2003 Report Viewer to view reports that are created by Crystal Reports in SMS 2.0 sites. 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.
u u
You cannot use the SMS 2003 Report Viewer to access an SMS 2.0 site database. In SMS 2003, discovery methods report the clients types Advanced Client or Legacy Client. SMS 2.0 discovery methods do not report the clients 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. 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. 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.
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 u The collection contains a rule in which Limit to collection is set. 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
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
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 813 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 1417.
In This Chapter
u u u u u u u Step 1 Understand the Methodology and the Risks Step 2 Analyze Your Environment Step 3 Analyze Your Needs Step 4 Assemble the Team Step 5 Begin Assembling the Project Plan Step 6 Learn SMS 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 sponsors role to prioritize feature identification, develop the organizations 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.
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 Phase Pre-planning Steps
Management Server 2003 Concepts, Planning, and Deployment Guide
1. Understand the methodology and the 2. 3. 4. 5. 6. 7.
Chapter 7, The Pre-Planning Phase risks. Analyze and document current computing environment. Analyze your organizations needs and identify objectives. Assemble the team. Begin assembling the project plan. Learn SMS. Establish test lab environment. lab testing as you proceed with each step: u Design the SMS hierarchy. u Sites and Hierarchy
Planning
8. Complete the project plan, performing Chapter 8, Designing Your SMS
Chapter 9, Capacity Planning for Plan the deployment and site SMS Component Servers configuration and conduct a pilot Chapter 10, Planning Your SMS project. Deployment and Configuration Plan your security strategy. Plan for SMS site recovery. Chapter 12, Planning Your SMS Security Strategy Chapter 13, Planning for Backup and Recovery Chapter 15, Deploying and Configuring SMS Sites Chapter 17, Discovering Resources and Deploying Clients
u u Deployment
9. Deploy the SMS hierarchy. 10. Deploy SMS clients.
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 u Microsoft Operations Framework 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.
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 Deploying SMS without planning Risk Hindered network infrastructure stability, reduction in available bandwidth, reduced performance due to improper server sizing, and the potential for SMS to collect data that is not valid Best practice Create a project plan and follow the planning and installation guidelines in this book or in the Microsoft Solutions Framework documentation.
(continued)
Table 7.2 Risk Avoidance and Best Practices (continued)

Action For large- and medium-sized organizations, using the Express Setup feature to install an SMS site server without planning or considering the customizable SMS and Microsoft SQL Server settings Not testing in a lab environment before deployment Risk Network infrastructure instability, performance issues, and productivity interruptions due to a reduction in available network bandwidth Best practice Use Custom Setup unless you are evaluating SMS within a lab environment that is physically isolated from your production environment.
Interoperability problems and reduced ability to: Provide support staff with needed skills and experience Eliminate the costs associated with incorrect design, which could lead to a costly redeployment Inability to troubleshoot system failure if changes to system are not tracked
Thoroughly test your SMS deployment, run a pilot project, and document your results before deploying any SMS component on your production network.
No use of change control or change management
Develop a formal change management process and tracking system to ensure that changes are made only where necessary to fulfill objectives, and that all implications and risks are understood in advance. Plan for recovery as you plan your deployment, not after you have already deployed SMS. Plan for security early, so that you can ensure the security of your computing environment. As you assign roles to your SMS project staff and trainers, ensure that these individuals are trained in the areas of expertise needed for planning, installing, supporting, and maintaining SMS. Plan a schedule for informing the SMS team and all other groups of planning and deployment progress.
Not planning for recovery
SMS data loss and complex recovery process Security breaches unauthorized access of client computers or malicious destruction of client computers Improper installation and use of SMS, failure to meet requirements, and poor support for end users, all of which can result in forming a negative reputation for SMS in the organization Insufficient support from management, colleagues, end users, or other groups in the organization
Not understanding and planning for SMS security policies
Not planning for training and education
Not planning and carrying out a good communications strategy
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 data is information that you plan to collect using the discovery and inventory features of SMS 2003,
then collect as much data about your environment as you can during the pre-planning phase. This helps you to determine your objectives when you proceed to the Analyze Your Needs section later in this chapter.
Start by collecting and collating the data described in this section. See Table 7.3 for an overview of the type of data you can collect. As you examine your environment, review how SMS integrates into existing operational processes and the effect it will have on existing operational roles and responsibilities. Also, be sure to anticipate and track proposed infrastructure changes.
Step 2 Analyze Your Environment 219
Table 7.3 Collecting Computing Environment Data

Environment Previous installations Geographic profile Data needed The history of your organizations systems management solutions Diagram of the geographic locations of your organizations sites, including information about international operating system languages and time zones Diagram of the divisions or departments within your organization and their associated managing and reporting structures Diagram of your network infrastructure, including LAN and WAN architecture, physical topology, network size, bandwidth, usage, traffic patterns, network protocols, and subnets 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) 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 Diagram of your organizations Microsoft Windows NT and Windows 2000 domain models and trust relationships 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) 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 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 organizations infrastructure projects
Organizational structure
Network topology
Client environment
Active Directory site structure
Domain models
Server environment
Security
Information Technology (IT) organization
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 organizations 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 organizations current systems management guidelines and make decisions about changing appropriate aspects of it with your SMS implementation. 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. 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 vendors 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.
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 Date and time zone information Data needed List the time zone for each location and any date and time difference between the remote site and headquarters. List the operating systems in use and locations that use language versions that are different from those of your platform operating systems.
Operating systems and international operating system versions
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 organizations 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 Departmental organization Data needed 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 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)
End users, clients, and software applications
(continued)
Table 7.5 Gathering Organization Data (continued)

Organizational structure Mobile clients IT organization and administrative policies Data needed A list of laptops that travel from one location to another The structure and technical level of local and remote IT divisions, their reporting hierarchies, and local and global IT administrative policies Any major business changes planned for the future, such as mergers, acquisitions, major physical moves, or network migrations
Long-term business direction
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 High-level WAN/LAN architecture Data needed Links, gateways, geographic locations, firewalls, and extranets or virtual private networks, where applicable Number of servers and clients at each location Link speeds and available bandwidth, including any known bandwidth issues Light, moderate, heavy times of day when network usage is heaviest (peak times) and scheduled times for backup and maintenance (non-peak times) Windows NT, Windows 2000, or Novell NetWare and other third-party network operating systems TCP/IP, NetBEUI, IPX/SPX, AppleTalk, DLC, DecNet, Banyan VINES, etc., and name resolution methods such as DNS and WINS The IP subnets on your network by subnet ID Active Directory organizational units, site names, trees, and forest
Network size Network bandwidth Network usage and traffic patterns
Network types Network protocols
IP subnet structure Active Directory site structure
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 Number of clients Data needed Total number of client computers in use on your network, and the physical and logical groupings of clients Number and types of client computers on each IP subnet, including projected number of clients in the upcoming year Whether or not users use logon scripts, and if those scripts are customized Desktop security rights granted to end users 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) Computers that are shared by multiple users, those that travel from one location to another, all homebased client computers having remote access to the network, and any other client computer environments A database or spreadsheet of all major applications in use in the enterprise, categorized by organizational division or by IP subnet
IP subnet size
Logon scripts Security rights Operating systems
Client stability/mobility
Software
(continued)
Table 7.7 Collecting Client Data (continued)

Clients Special applications Data needed Divisions or departments that use Windows Terminal Services to run applications, or use other special applications, such as internally manufactured or obsolete applications 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)
Connectivity
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 u u u Windows NT domains Windows 2000 Active Directory native mode domains Windows 2000 Active Directory mixed mode domains All Windows Server 2003 Domain functional levels
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 u u u u Single domain Single master Multiple master Complete trust Mixed mode (see the Active Directory Structure section later in this chapter)
Los Angeles domain
Figure 7.1 Sample master domain model diagram
Advertising Sales2 Development Manufacturing PDC Master domain
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.
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 upgraded PDC upgraded but not all BDCs upgraded PDC and all BDCs upgraded native mode switch not yet set PDC and all BDCs upgraded native mode switch has been set
Windows NT Domain
Mixed Mode Domain
Mixed Mode Domain
Native Mode 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 Windows 2000 mixed (default) Domain controllers supported Windows NT 4.0 Windows 2000 Server family Windows Server 2003 family Windows 2000 Server family Windows Server 2003 family Windows NT 4.0 Windows Server 2003 family Windows Server 2003 family
Windows 2000 native Windows Server 2003 interim Windows Server 2003
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 u u u Organizational units Domains Trees Forests
The physical structure of your organization is represented by the following Active Directory components: u u Active Directory sites (physical subnets) 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.
Figure 7.3 Sample Active Directory structure depicting domain modes and operating systems
Contoso.com
Contoso-acct
Contosocorp
Windows 2000 Windows NT Professional 4.0 Workstation
Windows 2000 Windows 2000 Server Server Contososales
Key
Windows 2000 Server Mixed-Mode Domain Native-Mode Domain
Windows NT 4.0 Server
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.
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 u u u u u u u u u u u Type and speed of the microprocessor and amount of RAM installed Disk and array controller characteristics and configuration, including whether Windows Cluster Service or Windows Network Load Balancing Service is enabled Naming conventions Devices and their characteristics, including size, MB of cache, and the drive models and types (for example, ultra-wide SCSI, 18 GB, 7200 RPM) Primary domain controllers and backup domain controllers Servers running Terminal Services Platform operating system, version, and language DHCP servers and IP address scopes WINS servers DNS servers Relevant software applications located on servers, including anti-virus software 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.
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.17.4.2/22 172.16.8.10/22 172.16.8.1/22 Cabling: 100BASE-T Category 5 UTP Ethernet
172.16.16.1/22 UNIX Server Solaris 2.6 172.16.16.5
Windows NT 4.0 DHCP Server 172.16.8.46/22 Sv21.Corp.Com Windows NT 4.0 PDC 172.16.8.22 Sv10.Corp.Com
Windows NT 4.0 Server DHCP Assigned Sv23.Corp.Com
172.16.8.60/22 172.17.8.1/22 Public IP Address Range Internet DS3 Proxy Server Sv33.Corp.Com 172.17.8.2/22
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 organizations security policies, such as: u u u u Account password policies (age, length). Account cycling policies (account expiration). Account rights policies. 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). Auditing policies (activities being audited, if any). Separation of duties between IT divisions within the enterprise (be aware of any overlap). The degree to which users must retain control of clients, and any exceptions to such policies (for example, servers or computers used by programmers). Sensitivity to security risks. Importance of ease of administration. Special needs you have for secure data access and transmission.
u u u u u u
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 preplanning, 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?
Create an organization chart that maps your IT organization to your geographic profile. Include the following in your organization chart: u u IT reporting hierarchy 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) Points where management control issues or policy issues exist Level of technical sophistication and security clearance of IT staff members who will be working with SMS before, during, or after SMS deployment Service level agreements for departments, end users, and IT groups Operating systems used to support the network and end users Change control policy
u u u u u
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 projects 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 Configuration management Track hardware and software assets and collect files from client computers. Produce and share reports on computer assets and application monitoring from any Web-based computer. Centrally administer client reporting across products that can use Active Directory. Manage site boundaries by Active Directory site names instead of (or in addition to) IP subnets. Release management and license compliance Deliver software to clients for automatic or user-assisted installation. Create preconfigured self-extracting software packages and perform unattended software installations on clients. Convert SMS Installer packages to Windows Installer format (.msi). Increase efficiency of site-to-site software package replication (conserve bandwidth in updating software packages on distribution points). Manage laptops over slow network links and reduce the cost of remote client operation over expensive WAN links. Monitor usage of software programs. Incident management Perform remote troubleshooting. Remote Tools Software distribution SMS Installer SMS Installer Delta replication Hardware and software inventory Reporting Active Directory discovery Active Directory site boundaries SMS 2003 features
Advanced Client Software metering
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.
In accordance with Microsoft Solution Framework best practice, requirements must be: u u u u u Specific. Measurable. Achievable. Results-oriented. 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 organizations 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 organizations 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 Project sponsor Critical work functions 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. 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.
Project manager
(continued)
Table 7.10 SMS Occupation Taxonomy (continued)

Role Administrator Critical work functions 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. Perform SQL Server administration and maintenance for SMS site database. Troubleshoot database problems. 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. 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.
Database administrator
Help desk specialist
Trainer
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. Contosos 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. Contosos 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.
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 u u u u u u The amount of staffing resources you can devote to testing SMS and running the pilot project. The amount of long-term staffing resources you have during and after deployment. 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). A path for escalating problems to higher-level support tiers. The hours that support will be available to users. Methodology for reporting, tracking, prioritizing, and resolving problems. 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.
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 u u All participants are regularly informed about the progress of the project. All participants are aware of their roles and responsibilities. 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 u Progress updates sent to specific e-mail distribution lists A Web site for quick access to frequently asked questions, procedures, and status reports
u u u
Articles in your organizations newsletter A newsletter, flyer, or memo devoted to the pilot project 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.
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 u u IT professionals SMS users 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 u u u u Self-paced computer-based training courses. Instructor-led classroom sessions. Webcasts offered online at http://www.microsoft.com/smsmgmt/default.asp. Printed and electronic product documentation provided by Microsoft and third-party resources. 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 u u On site Authorized Microsoft training centers, such at the Microsoft Authorized Academic Training Program and the Microsoft Certified Technical Education Center Third-party training facilities
More Information
The following Web sites provide additional information about SMS and other training options offered through Microsoft: u u u SMS training Web site: http://www.microsoft.com/smsmgmt/training/default.asp Microsoft Training and Certification: http://www.microsoft.com/trainingandservices/redirect/mcp.htm 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.
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 u u u u u Designing the SMS hierarchy Planning the deployment and site configuration Planning your security strategy Planning for backup and recovery Deploying the hierarchy Deploying SMS clients
Also, use the lab to perform tests throughout the steps of the deployment phase:
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
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 u u Chapter 2, Understanding SMS Sites Chapter 3, Understanding SMS Features 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 u u u Overview Designing SMS Sites and the SMS Hierarchy Advanced Design Issues 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 organizations 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 NYC (child site)
Primary site London (parent site and child site)
Secondary site Milan (child site)
Site server
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 point Server locator point Parent Primary site Seattle COM Distribution point CAP Management point Site server Distribution SMS site database point (SQL Server) CAP Distribution point CAP CAP Distribution point Child CAP Management point Primary site Seattle RES Site server SMS site database (SQL Server) Distribution point Central site server SMS site database (SQL Server)
CAP Distribution point 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 u u u Collected the computing environment data listed in Table 7.3 Determined your objectives Developed a clear understanding of the SMS 2003 features to implement 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.
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.
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 organizations finance department or for a partially owned subsidiary. Your organizations 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 organizations 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.
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 u u u u Connection speed and reliability Available bandwidth Line quality Latency 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 sites 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.
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.
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 u u Several primary sites that have approximately 10 child sites. Several secondary sites that have approximately 25 clients. 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.
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 site. supported as SMS 2003 site
boundaries. To take advantage of any subnet grouping technologies in SMS, such as supernetting, you must use Active Directory site names for your site boundaries instead of IP subnets. For information about supernetting, see the Windows 2000 Resource Kit.
Computers must be members of a domain to be included in SMS site boundaries. Workgroup computers are not supported in SMS.
Because site boundaries generally reflect the layout of your enterprise, use the network diagram you created in the pre-planning phase when considering where to set 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.
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 sites 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 u u Site boundaries are composed of IP subnets and/or Active Directory site names and define which resources the site manages. Roaming boundaries are used by Advanced Clients to access distribution points that can provide them with advertised software packages. 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. By default, site boundaries are included in the sites 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.
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 u u u Client access points Management points Distribution points 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 u u If you have Advanced Clients reporting to a site, you must make a management point available to those clients. Advanced Clients are assigned to primary sites, not to secondary sites. An Advanced Client is assigned to only one site.
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. 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. 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. The use of the Advanced Client through a proxy server that performs network address translation is not supported. 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.
u u
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 u Because Legacy Clients are managed by CAPs, you must plan to install a CAP in each site that has Legacy Clients. You can install a server locator point at a primary site in the hierarchy to help your Legacy Clients locate CAPs.
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 u u u u Heartbeat Discovery Hardware and software inventory Polling for new advertisements (software distribution) Running an advertisement (software distribution) 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 u u u Communications within an SMS site Site-to-site communications Client communications 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.
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 siteto-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 u u u You are using the Microsoft Windows Server 2003 family The forest functional level is set to Windows Server 2003 SMS is running in advanced security mode 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 clients 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.
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 organizations 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 AZ, az, 09, 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.
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 u u Optimize your management plan by effectively grouping child sites. Take into account how communication between sites affects design. 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 divisions 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 organizations 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.
Another way to group sites is by region. Grouping sites by region can reduce the cost of the siteto-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 significant investment in more resources. When you have a tentative plan for grouping your SMS sites, review the plan for performance, scalable servers, and cost. For example, dozens of primary sites that each have high-end server hardware but support only four small child sites might be very expensive. Consider reducing the number of primary sites and grouping the small child sites with other sites to take advantage of the high-end equipment at the primary site. For more information about capacity planning and server sizing, see Chapter 9, Capacity Planning for SMS Component Servers.
Server sharing at secondary sites

A secondary site server does not require the same resources as a primary site server because it does not run SQL Server. For this reason, secondary site servers at small, simple sites might be able to share the workload with servers already located close to their clients. If you are considering using this configuration, test the effect of these applications on the secondary site server and the effect that SMS might have on other applications.
Note
Do not install your SMS site servers on computers running the Windows Cluster Service without understanding SMS interoperability with the Cluster Service. For more information, see the white paper at http://www.microsoft.com/smserver.
Central Site
Whether you have clients reporting to your central site depends on the size and complexity of your organization and whether you use the central site server for other purposes. Alternatively, clients can report to child sites beneath the central site. Because all status and client data flows up in the hierarchy to the central site, adding a large number of clients to this site can diminish central site server performance and client performance. If you plan to use your central site server for other purposes, such as SMS reporting, consider not having clients report directly to the central site. A deciding factor in what roles you assign to the central site server, and whether clients report directly to it, is the robustness and capacity of the hardware on this server. If you do assign roles to the central site, the server should be robust enough to handle both local processing and organization-wide processing. After you have designed your sites and determined the site reporting structure, you connect your sites to form a single hierarchy that reports up to the central site server. It is recommended that you begin at the bottom tier of your hierarchy, planning the lower level sites that attach to higher level sites. Work your way up the hierarchy, attaching to higher level sites as you go. From this structure you can determine the most logical location of your central site.
Flat vs. Deep Hierarchies

Building a hierarchy is influenced by many internal and external factors. Depending on the business needs and physical layout of your organization, your hierarchy design will ultimately resemble a flat hierarchy or a deep hierarchy.
Note
It is recommended that you design a flatter hierarchy, which makes the hierarchy easier to configure, administer, and support. With fewer tiers in your hierarchy, SMS needs less time to deploy software to lower level sites and report status back to the top of the hierarchy.
Limiting the Impact of Site Failures

When deciding on a hierarchy design that best suits your organization, consider how much you need to limit the effect of possible site failures. In a deep hierarchy, if a site server with a relatively large number of lower level sites fails, the detrimental effects will be greater because a relatively large number of clients will be disconnected from the parent of the failed site. However, in a flat hierarchy, the sites and the SMS clients are more distributed. If a site server in a flat hierarchy fails, fewer clients are affected. Figure 8.4 shows a deep hierarchy containing 4,500 lower level clients. Figure 8.5 contains the same number of clients, but it is a flat hierarchy. If the second-tier site fails in the deep hierarchy, as shown in Figure 8.4, 3,400 clients will lose connectivity to the central site. In Figure 8.5, which shows one possible second-tier site failure, only 500 clients are disconnected.
Figure 8.4 A deep hierarchy, with 3,400 clients disconnected by a site failure
Central Site CH1
Primary Site
Primary Site
(1,000 clients)
(1,000 clients)
Secondary Site
Primary Site
Primary Site
(100 clients)
(1,000 clients)
(1,000 clients)
Secondary Site
Secondary Site
(200 clients)
(200 clients)
Figure 8.5 A flat hierarchy, with only 500 clients disconnected by a site failure
Central Site NY1
Primary Site
Secondary Site
Secondary Site
Secondary Site
Secondary Site
Secondary Site
(500 clients) (1,000 clients)
(500 clients)
(500 clients)
(500 clients)
(500 clients)
Secondary Site
Secondary Site
(500 clients)
(500 clients)
Although there are many model combinations that might fit your organization, be sure to test your hierarchy design during the pilot project. For information about running the pilot project and refining hierarchy design, see Chapter 10, Planning Your SMS Deployment and Configuration.
Assigning Site System Roles

You can assign all of the system roles to the primary site server or distribute them among other servers. When planning the placement of site system roles in your hierarchy, remember that some of the roles are assigned during installation and others are assigned through the SMS Administrator console. See Table 8.2 for server assignment during installation, Microsoft Internet Information Services (IIS) requirements, and role restrictions. For site system supported platforms, see the Getting Started chapter in this book. Be aware of the changes that you can and cannot make to your sites after deployment. Some site system roles can be moved after installation but others cannot.
Site Servers and Site System Relocation

If your organizations needs change and expand unexpectedly after you deploy SMS, you might find that your original hierarchy design reduces performance to unacceptable levels. If this occurs, you must revisit your design. You might be able to improve the performance of your site by moving and assigning site system roles to additional computers. Table 8.1 describes the site system roles that can be moved from one computer to another. For more information about moving the SMS site server, SMS site database server, or SMS Provider, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide. Table 8.1 Moving SMS Site Servers and Site Systems
Site system or role Site server Can the role be moved? No, you cannot move the site server to another computer. However, you can move the site server to another domain, or you can restore the site server to a different computer with the same server name. Yes, you can move the SMS site database from the site server to a remote server running SQL Server, or you can move the SMS site database from one remote server to another remote server. However, after you have moved the SMS site database from the site server, you cannot move it back. No Yes Yes Yes Yes Yes Yes
SMS site database server (SQL Server)
SMS Provider SMS Administrator console Client access point Distribution point Server locator point Management point Reporting point
After you have installed a reporting point on a server, you cannot move your IIS installation on that server from one disk to another without reinstalling the reporting point. For information about locating your site servers, see the Determining the Locations and Types of Site Servers section earlier in this chapter.
Site System Roles

Assigning site system roles to servers in your organization is a task you perform for each site after installing its SMS 2003 site server. Include site system placement in your hierarchy design. Table 8.2 summarizes the SMS site systems and roles that are assigned automatically during SMS setup. Note that the site server is automatically assigned during installation and can share roles with site systems.
Table 8.2 Server Assignment During Installation, IIS Requirements, and Role Restrictions
Site system, role, or SMS Provider SMS site database server (SQL Server) SMS Provider Client access point Distribution point Distribution point with BITS enabled Server locator point Management point Reporting point Assigned during installation Can share roles with other site systems
Requires IIS
Can exist in a secondary site
Note
If you want to assign a CAP, distribution point, management point, or server locator point role to a server in another domain, see Chapter 5, Understanding SMS Security.
SMS site database server and the SMS Provider

Before deployment, it is important that you decide where to install the SMS Provider and SQL Server. The SMS site database server must be installed with SQL Server. When initially deploying an SMS 2003 site, you can install SQL Server wherever you want. The SMS Provider can be installed on either the site server or a remote computer running SQL Server that contains the SMS site database. For information about SQL Server version requirements, see the Getting Started chapter in this book.
However, it is recommended that you install your SMS site database on your site server. If not, SMS competes with other applications on the LAN segment for network bandwidth, and SQL Server has the increased overhead of completing network operations before responding. This might slow the processing of SQL Server. After a site is set up, the SMS Provider cannot be moved to the site server if it is installed on a remote computer running SQL Server. Installing the SMS site database on your site server also simplifies the recovery process. For more information, see Chapter 13, Planning for Backup and Recovery. Be aware of your organizations policy with regard to database servers. For example, if a separate department controls all the computers running SQL Server in your organization, the policy might mandate that the SMS Provider not be installed on the remote computer running SQL Server. Or, the policy might not allow installation of SMS on your SMS site server. Be sure you have this information during the design phase. If possible, plan on dedicating your SQL Server database to SMS 2003. In general, it is recommended that you do not share the SMS site database server with other SQL Server applications because doing so can reduce SMS performance. This recommendation mainly applies to organizations hosting a large number of SMS clients and to other SQL Server applications that use excessive amounts of processor time. Check your IT organizations policy before sharing your SMS site database with other SQL Server applications.
SQL Server database replication

If you anticipate heavy network traffic between your server locator points or management points and the SMS site database server, consider implementing an extra database for the purpose of SQL Server database replication. To improve the performance on the SMS site database server, Advanced Client policy tables of the SMS site database that are used by management points can be replicated to a separate computer running SQL Server. In this case, SQL Server database replication automatically keeps the replicated Advanced Client policy database synchronized with the SMS site database. SQL Server database replication allows management points and server locator points to query the SMS data they need and service client requests without placing additional load on the SMS site database server. The work is then distributed among one or more computers running SQL Server that are not hosting the SMS site database, which improves performance of SQL Server resources. The replication process is handled entirely by the SQL Server publication and subscription services.
SMS Administrator console

The SMS Administrator console is easy to install from the SMS product CD to any computer running Microsoft Windows 2000 Professional Service Pack 2 or later. Appropriate permissions must be assigned for a user to run it and administer SMS sites. Because the SMS Administrator console is a snap-in for Microsoft Management Console (MMC), you can customize your SMS Administrator consoles for varying levels of access by different groups of SMS users, such as your help desk staff. For more information, see Chapter 16, Using the SMS Administrator Console.
Client access point

Plan to have at least one CAP in every SMS site. If the SMS site contains only Advanced Clients, you do not need to have multiple CAPs, because without Legacy Clients, the CAP is used only by SMS site server components. If the SMS site contains a significant number of Legacy Clients, be sure you have enough CAPs to support those clients. Consider assigning the CAP role to one or more site systems, other than the site server, to reduce the load on the site server. When determining the number of CAPs you need, consider the load on the CAP and whether you require fault tolerance across your CAPs. Your goal is to keep the number of CAPs deployed to a minimum, while still enabling the CAPs to service Legacy Client needs effectively. This ensures that clients do not experience any unacceptable reductions in service, such as not receiving timely advertisements. Because SMS site server processes perform replication serially and must cycle through each CAP, it takes longer for this process to complete if you have many CAPs. This is an important consideration, because all Legacy Client files are replicated to each CAP. When you make configuration changes to an SMS site, all the Legacy Clients contact the CAPs at their next wakeup interval and update the client from the CAPs based on these changes. An example of a configuration change is installing an SMS service pack. The default wakeup interval is 25 hours. Although your CAPs might not always be heavily loaded, make sure that you have enough capacity to perform these operations after your hierarchy is set up. This is especially true for sites that contain a large number of clients. It is important to remember that CAPs also receive data from clients, including inventory and status messages. The SMS site server is automatically installed as a CAP. If you want to dedicate a primary site to performing only SMS server activities, you can remove the CAP role from the site server after you have created another CAP in the site and assign it to another server. This ensures that the primary site is dedicated to performing site server activities and that these services are not affected by client requests. This is especially true in a large site with thousands of clients. For information about sizing CAPs and determining the number of CAPs per site, see Chapter 9, Capacity Planning for SMS Component Servers.
Distribution point
The load on a distribution point varies with the number and size of the packages you distribute. You determine the necessary computing capacity of distribution points the same way you would size any file server in your organization through testing and the collection of empirical data in your test lab.
The number of distribution points needed in a site depends on the number of clients that need access to packages for software distribution. The number of distribution points might also depend on the location of clients. It is preferable to specify a distribution point that is in close proximity to a group of client computers. The more software distribution you do, and the larger the software packages you deploy, the more distribution points you need.
Note
Distribution points receive packages and package updates from the site server without bandwidth throttling. Customers might choose to install a secondary site in the remote office to gain the site-to-site bandwidthsensitive and scheduling capabilities of SMS senders
BITS-enabled distribution point

As clients roam from location to location, computers with the Advanced Client installed check for the availability of SMS sites with distribution points that contain needed software content. The Advanced Client remains assigned to its original site. However, when the Advanced Client needs to retrieve an advertised package, it can download or run the package from a local distribution point, rather than from its assigned site. Remember this when you choose remote servers to be distribution points. To protect your Advanced Clients from excessive bandwidth consumption, enable BITS on your distribution points that serve Advanced Clients. This provides an efficient file transfer mechanism through client-sensitive bandwidth throttling. It also provides checkpoint restart download of packages, which allows files to be transferred to the client in a throttled manner. Plan to have both your CAPs and distribution points on the same high-speed, reliable connection as the site server. Although these site systems can function over a WAN, the consequences can be detrimental and potentially cause significant network activity on your WAN.
Important
BITS requires Microsoft Internet Information Services on the management point and that you enable BITS on the distribution point.
Protected distribution point

The protected distribution point is designed to protect network links to distribution points from unwanted traffic. The SMS administrator specifies which roaming boundaries or site boundaries Advanced Clients must be in to use the protected distribution point. Any clients outside those boundaries are unable to download or run packages from that distribution point. To restrict access to a distribution point that is across a slow or unreliable network link, plan to enable it as a 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. For example, consider configuring a protected distribution point on secondary site servers that are connected to their parent primary site by a WAN link.
Management point for Advanced Clients

Even though Advanced Clients are only assigned to primary sites, management points can be installed on both primary and secondary sites. A management point on a secondary site is known as a proxy management point. It can be set up and used for roaming Advanced Clients if roaming boundaries are enabled. Proxy management points increase bandwidth efficiency by servicing roaming clients that are within the secondary sites roaming boundaries. For more information, see the Management points at secondary sites section later in this chapter. Multiple management points Typically, an SMS site containing Advanced Clients uses only the default management point. However, multiple management points can be implemented in one site to meet either network load balancing or backup needs. Network load balancing is having two or more management points on sites that have a high percentage of Advanced Clients. This balances the load of network traffic flowing from clients to the management point. Backup is having an extra management point on a site in case the default management point fails. In this scenario, the administrator designates the backup management point as the default management point. Note that the secondary management point does not provide automatic failover. It remains idle until it is designated as the default management point.
Note
Network Load Balancing Service is a Microsoft Windows 2000 Advanced Server feature that is used to build a server cluster, which is a set of computers that work together to provide a service. The typical setup involves using one network adapter to manage the computers and a second network adapter to service clients. The latter network adapter has a single virtual IP address. The other computers in the cluster share the same virtual IP address as the network adapter used to service SMS clients. For information about configuring Network Load Balancing, see the Windows 2000 Advanced Server documentation.
Management points at secondary sites Advanced Clients located at a secondary site and reporting to a management point at a parent primary site across a WAN link might have an effect on the available bandwidth of the WAN link between the secondary site and its parent primary site. Significant network traffic can be produced when client status and hardware or software inventory data is sent to the parent primary site. Because an Advanced Client can be assigned only to a primary site, network traffic generated by Advanced Client policy requests also reduces the available bandwidth between the two sites.
Installing a proxy management point at the secondary site can significantly reduce the effect on available network bandwidth created by Advanced Clients located within that sites roaming boundaries or site boundaries. Advanced Clients send inventory data, software metering data, and status data to the proxy management. The proxy management point uses the sites sender functionality to transfer the data to the parent primary site. By using the senders bandwidth control functionality, you can specify when the data is sent to the primary. The proxy management point also caches some Advanced Client policy information. Advanced Clients obtain this Advanced Client policy information from the proxy management point, rather than from the management point at the primary site. Figure 8.6 represents these communications. Figure 8.6 Proxy management point communications over a WAN link
Primary Site Assigned management point
WAN Connection Advanced Client policy assignments Advanced Client policy requests Proxy management point
Inventory, DDR, and status
Secondary Site
Advanced Client
Connection by SMS sender Connection by HTTP
Plan to include a single proxy management point at a secondary site if you have a significant number of Advanced Clients using resources in that site. SQL Server database replication for management points If the number of Advanced Clients grows significantly, you can replicate the tables in the SMS site database to a different instance of SQL Server than the one used by the SMS site database. This reduces the load on the primary sites SQL Server database because the management points query a different instance of SQL Server when servicing Advanced Client requests. The replicated tables can be on the computer with the management point or on a stand-alone computer running SQL Server with no other SMS site system roles.
Some of the standard configurations that you can use include: u u A single management point accessing the site server SQL Server database directly. This is suitable when relatively small numbers of Advanced Clients must be supported. A single management point with its own replicated SQL Server database. This configuration takes the load off the site server SQL Server database and allows the management point to continue operation when the site server SQL Server database is unavailable. Multiple management points that are using network load balancing and accessing a single replicated SQL Server database. This is suitable when higher numbers of Advanced Clients must be supported. High resiliency is provided by isolation from the site server database and network load balancing with dynamic failover. Multiple management points that are behind a network load balancing server, each with their own local, replicated SQL Server. This is suitable when very high numbers of Advanced Clients must be supported. Local SQL Server installations and network load balancing provide maximum throughput and resiliency.
Management point requirements Remember the following requirements and features when planning management point roles: u u You must install Microsoft IIS and BITS on SMS management points. If you want to implement database replication, see the Getting Started chapter in this book for information about the SQL Server version requirements.
Important
For a management point to be assigned to a site, that site and all its parent sites must be running SMS 2003.

Plan for a server locator point in your SMS hierarchy when any of the following are true: u u You use Logon Script-initiated Client Installation to deploy Legacy Clients or Advanced Clients You want to automatically assign Advanced Clients to sites without extending the Active Directory schema for SMS
The server locator point requires minimal planning. Unlike management points, server locator points are supported only in primary sites, not secondary sites, and they are used for both Advanced Clients and Legacy Clients. The number of server locator points you include in your site depends on the number of clients in that site. Typically, you need only one server locator point in your SMS hierarchy. Typically, you install the server locator point at the central site. If the server locator point creates too much load at the central SMS site database, you have the option to use a replicated SQL Server database for that site. If there are excessive client requests, causing excessive traffic on a single server locator point, you can set up multiple server locator points at the central site.
Server locator points are only accessed by the Legacy Client at client logon time and produce minimal network traffic approximately a 1-KB upload and a 1-KB download to the client. Because the Advanced Client only accesses the server locator point once, for automatic site assignment at its initial logon time, the bandwidth impact is insignificant. Like management points, server locator points require IIS.
Note
Replication of both the management point and server locator point databases is supported by some versions of SQL Server. SQL Server supports replication to third-party heterogeneous databases; however, they are not supported by SMS 2003. For more information, see the Getting Started chapter in this book.
Reporting point
Reporting points communicate only with the local SMS site database. A reporting point server requires IIS. You implement reporting points only on primary site servers, not on secondary site servers. The placement of your reporting points depends on what data you want to report. For example, a reporting point placed as high as the central site can report on data that is produced by all tiers of the hierarchy, except for the status of advertisements sent only to a lower level site in the hierarchy. Large organizations with numerous report users and additional scalability needs might consider planning for multiple reporting points. With multiple reporting points, you can provide different reporting point access URLs to different sets of users for accessing reports. However, be aware of the potential for performance degradation of the SMS site database server if your use of reports and reporting queries is very high, especially if you have a large number of report users running the same reporting query.
Note
Although a Recovery Expert Web site is not a site system, it can share roles with other site systems. If you plan to install a Recovery Expert Web site, you must allocate an IIS server for it. For more information about Recovery Expert Web sites, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Advanced Design Issues

Advanced design issues do not affect all site designs, although they can affect some. Consider the following design issues: u u Advantages of multiple sites Multilanguage site hierarchies
Advanced Design Issues 279
u u u
Upgrade and interoperability Planning for domain migrations Planning for Active Directory
Advantages of Multiple Sites

The hierarchy provides a means of extending and scaling SMS support across a wide variety of organizational structures. A single site is the easiest to configure and manage, but there are circumstances in which it is beneficial to set up multiple sites in an SMS hierarchy. What is most important is data flow and ease of administration. It is important during the design phase to consider your need for additional sites. These needs might belong to one of the following categories: u u u u u u u Network performance with clients Number of resources Features required by users International considerations Number of sites Corporate structure Domain structure
Network Performance with Clients

Slow network connectivity between the site server and some clients might indicate a need to set up and manage those clients in their own site if the group of clients is well-connected.
Number of Resources
If there are more resources than can be supported by a single site using the SMS features you have chosen, consider creating additional sites.
Features Required by Users

You might have groups of users that require different SMS features. For example, if your IT administrators need remote access to servers residing in a locked room, and you want to disable the permission-required feature of remote access for just those computers, you might assign those servers to a separate site.
International Considerations
You might need to install an international version of SMS in the same hierarchy that contains an English or other localized version of SMS.
Number of Sites
If a hierarchy plan becomes large, you might need to add an additional tier of primary sites to help manage and organize the large number of sites that would otherwise report to the central site. If, in your test lab environment, the site server response in a parent site degrades to unacceptable levels, you might consider creating additional levels in the hierarchy. The main factors to consider before adding sites in the hierarchy are server performance, the number of clients per site, and administrative issues. Remember that the more tiers you have in the hierarchy, the longer it takes for status messages to propagate up the hierarchy. For more information, see Chapter 9, Capacity Planning for SMS Component Servers.
Corporate Structure
In some cases, an organizations policies can play a role in site definition. There might be multiple system administration groups within an organization that require administration of their own resources.
Domain Structure
Your existing domain model might dictate the use of certain discovery methods, or you might choose to organize or reorganize your domain model to more closely map to your SMS architecture (although single sites can handle multiple domains).
Multilanguage Site Hierarchies

International organizations might need to implement a multilanguage hierarchy. For a list of supported SMS site server languages and the client languages supported by each server language, see Appendix D, Using SMS in International Organizations, in the Microsoft Systems Management Server 2003 Operations Guide. The SMS client language that is installed must be compatible with the language of the site server to which the client reports. Your hierarchy can contain any combination of SMS site server language versions.
Upgrade and Interoperability

If you plan to upgrade to SMS 2003, you must consider upgrade issues when designing your SMS 2003 hierarchy. Before upgrading, use the SMS 2003 Deployment Readiness Wizard to identify potential interoperability problems and recommend corrective actions. For example, an SMS 2003 site cannot be attached to an SMS 2.0 site, but SMS 2.0 sites can be attached to SMS 2003 sites. Another unsupported scenario, for example, is promoting an SMS site server that is running a Microsoft Windows 2000 Server family operating system to a domain controller. Because this action changes or removes local groups, SMS functionality is damaged. These are just a couple of upgrade and interoperability considerations. For more information about using the SMS 2003 Readiness Analyzer and upgrading to SMS 2003, see Chapter 14, Upgrading to SMS 2003. For information about interoperability, see Chapter 6, Understanding Interoperability with SMS 2.0.
Reviewing and Testing the Design in the Lab 281
Domain Migration Planning

When you design your SMS sites, be aware that SMS Setup creates accounts in the domains that are appropriate at the time you run Setup. If you decide to change your domain model or change the domain that SMS servers are members of, you must make corresponding changes to some of the SMS accounts. For information about moving SMS servers from one domain to another, see Chapter 10, Maintaining and Monitoring the Network, in the Microsoft Systems Management Server 2003 Operations Guide.
Active Directory Migration Planning

You can take advantage of the simplified administration and many of the new features in SMS 2003 by migrating to Active Directory. As described throughout this book, SMS 2003 integrates with Active Directory in many ways. You can deploy SMS 2003 before, during, or after Active Directory deployment. It is not necessary to deploy Active Directory first. If Active Directory is already deployed in your organization, review your Active Directory infrastructure when you design your SMS hierarchy. Use the information about your Active Directory environment that you gather in the pre-planning phase. Meet with your Active Directory administrators to coordinate your SMS hierarchy design plans and determine if you are satisfied with the current Active Directory infrastructure. Control over your organizational policy might be an issue in planning for SMS 2003 and a migration to Active Directory. Typically, for larger organizations, one IT group manages Active Directory, and a different group is in charge of SMS. In this case, SMS planners must negotiate with the Active Directory administrators in achieving the best possible SMS hierarchy design. If you are upgrading from SMS 2.0 to SMS 2003, you do not necessarily need to change your hierarchy based on your new Active Directory design. Be aware of the issues and opportunities that your Active Directory migration presents to your SMS upgrade and determine from those whether you must change your SMS hierarchy design. For more information about upgrading to SMS 2003, see Chapter 14, Upgrading to SMS 2003.
Reviewing and Testing the Design in the Lab

When planning and refining your hierarchy and site design, periodically test your proposed design in a lab environment. Later, you will test your design in your pilot project. During these tests, you can identify and make modifications to your hierarchy.
Changes to Hierarchy Design

During the design phase it is important to understand what can later be changed in your hierarchy, after your SMS 2003 implementation. This section lists supported and unsupported post-deployment activities. SMS 2003 does not support the following post-deployment activities: u u Changing the disk drive letter on which SMS is installed Moving the SMS site database from a remote location to the SMS site server
Important
You can move the SMS site database from the site server to a remote server running SQL Server, or you can move the SMS site database from one remote server to another remote server. However, after you have moved the SMS site database from the site server, you cannot move it back.
u u u u u
Changing the site code Changing the site name Changing the computer name of the site server Changing the parent site of a secondary site Moving the SMS Provider from the site server to a remote server
Note
The SMS Provider always stays where it was originally installed, either on the site server or on the computer running SQL Server. If the SMS Provider is first installed on a remote computer, and the SMS site database is later moved to a different remote computer running SQL Server, then the SMS Provider must move with it.
SMS 2003 supports the following post-deployment activities: u u Moving the SMS site database from the site server to a remote server (the SMS Provider must remain on the site server) Moving the SMS site database from a remote server to another remote server
For information about how to perform these moves, see the Microsoft Systems Management Server 2003 Operations Guide.
Test Lab Development

Ensure that the lab environment matches the production environment as closely as possible.
Minimum Recommended Configuration

Lab computers must meet the minimum recommended configuration for the roles they will play in the SMS site design. For example, your site servers should have the minimum system requirements listed in the Getting Started chapter in this book.
Standard Configurations
If you have standard client and server configurations, use those configurations in the lab. To the extent that it is possible, use the same hardware, software, network, and logon scripts that are deployed 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. For more information about setting up a test lab, see Chapter 7, The Pre-Planning Phase.
Site Design Testing

When testing your SMS design, focus on the functions and configurations important in your particular production environment. For example: u u u If your design calls for many secondary sites, consider setting up your lab structure with as many secondary sites as possible. If you plan to use SMS for hardware and software inventory or to upgrade client operating systems, verify the procedures in your lab and in your pilot project before deploying SMS. Try to replicate and test the limits that you expect to encounter in your organization (for example, the slowest site server, the busiest management point, the least reliable network link, and the largest software packages).
This does not mean that you should set up a full production environment in your lab. However, you must set up a representative sample of your production environment. Plan your testing so that you can use the equipment you have to maximum advantage, and proceed in a logical and controlled manner. Start by testing features that are mission-critical to your company.
Sample Design Verification Plan

A design verification plan will help you proceed with logical and controlled testing of SMS. A staged design verification plan starts with the basics and builds with each successive phase. A sample plan for verifying your SMS design can include the following stages.
Stage 1
Analyze basic SMS functionality in a single-server environment. This approach makes it easier to identify hardware and integration issues with other management tools. It is easier to find and fix problems in the lab than in the production environment. You can complete a significant amount of the testing with a single computer running Windows 2000 Server SP2, and a laptop and desktop computer, each running Windows 2000 Professional.
Stage 2
Add additional servers, site systems, and subnets to the lab in the manner planned for deployment. Then, verify the added functionality. Configure the servers and site systems as you would configure them in production, including software and network protocols. If you have trusted domains in your production environment, set up some trusted domains in the lab. Set up accounts, logon scripts and profiles, and security as you would in your production environment.
Stage 3
Add clients and verify basic client functionality. Try to add at least one client for each platform that is used in your production environment. For example, if your company uses clients running Windows 98, Windows NT 4.0 Workstation, and Windows 2000 Professional operating systems, add at least one of each of these clients at this stage. Install and configure the clients as they would be installed and configured in your production environment.
Stage 4
Create an SMS hierarchy configured in a manner similar to your proposed SMS design. For example, if you plan to use many secondary sites reporting to a single central site, create and test at least four or five secondary sites in your lab. If you plan to create a hierarchy with many levels, create and test a similar hierarchy. If you plan to use an SMS 2.0 site in the hierarchy, create and test a similar site. Be sure that the hierarchy is created and functioning properly and then verify hierarchy-related functionality and system performance. Test over all the network link types and speeds you will actually use in your production environment. If you are using WINS, DNS, DHCP, SNA Server, or RAS, test them as you would use them in production. If you plan to use Courier Sender, test it at this stage. If the SMS site servers are not dedicated strictly to SMS, test them with the appropriate applications running on them. Ensure that they are installed with any standardized software, such as antivirus software, used throughout your organization.
Stage 5
Perform basic scalability and capacity testing to ensure that your site design and hardware scales to meet your current and future needs. If you can create real loads in your lab environment, do so. Otherwise, simulate expected loads so you can accurately test system performance. Ensure that your hierarchy design is well-documented in your project plan before proceeding to the deployment phase. Include a diagram of the hierarchy, site codes, server roles, and other relevant information.
Note
Be sure to document and verify the results of your tests against your project requirements. Rework your plan and resolve any major issues before proceeding to the deployment planning phase and pilot project.
C H A P T E R
Capacity Planning for SMS Component Servers

After you have completed the pre-planning phase, by using the methods described in Chapter 7, the The Pre-Planning Phase section and after you have designed your Microsoft Systems Management Server (SMS) 2003 sites and hierarchy, your next planning step is to develop a model for server sizing, performance, and capacity planning. Many of the performance issues described about in this chapter apply to various components of your overall network configuration, including server performance, network performance, overall SMS performance, and operating system performance. Performance issues that relate to a specific component of your network configuration refer to that component directly, for example, server performance instead of just performance. You perform the tasks that are described in this chapter before you deploy your SMS site so that you can avoid performance issues in production. However, you should also consider these tasks to be ongoing administrative responsibilities that can keep your SMS implementation running optimally.
In This Chapter
u u u u Introduction to Modeling for Sizing and Capacity Planning Performance and Capacity Planning SMS Activities That Affect SMS Server Performance Sizing SMS Component Servers
This chapter includes an overview of SMS server sizing, capacity planning, and performance issues that you should be aware of, and it provides you with some tools that can assist you when you plan for server performance and capacity. Sizing and capacity planning guidelines include: u u u u Being aware of how data flows in the SMS hierarchy. Ensuring that the actual performance load that SMS generates is effectively managed by the hardware that is in use. Building SMS component servers with as much fault-tolerant hardware as economically possible. Ensuring that your capacity plan can adapt when your organization grows and changes.
288 Chapter 9 Capacity Planning for SMS Component Servers
This chapter represents one integral part of the planning process that begins with Chapter 7, The Pre-Planning Phase. Understanding the basic concepts of SMS sites, features, and clients helps you generate a successful sizing plan. To benefit most from this chapter, you should be familiar with the following chapters in this book: u u u Chapter 2, Understanding SMS Sites Chapter 3, Understanding SMS Features Chapter 4, Understanding SMS Clients
Introduction to Modeling for Sizing and Capacity Planning 289
Introduction to Modeling for Sizing and Capacity Planning

Every network implementation is unique. The same thing is true of every implementation of SMS. Like many server-based applications, SMS does not perform the same way in every environment. Many hardware factors contribute to the performance of SMS on your server, including processor speed, disk access, and available memory. The configuration of the SMS deployment the number of SMS component servers and SMS clients you install, and the features you enable also affects server performance. Nevertheless, with some basic information about transaction types, file sizes, and network use, and with some useful formulas, you can develop an effective capacity planning and server sizing model. There are two strategies you can use to develop a capacity plan: u Develop a planning model that determines the number and hardware configuration of SMS component servers, based on the number of clients that must be managed and the SMS features that are enabled. Develop a planning model that determines the available capacity of existing SMS component servers, based on the number of clients that must be managed and the SMS features that are enabled. Create a test lab to gather server and network performance data. Determine the number and configuration of site servers that are required for the site hierarchy and the number and configuration of site systems that are required for each SMS site. Generate measurement standards for server performance that you can use to evaluate and identify peak performance periods and potential performance bottlenecks. Generate service level agreements that define acceptable levels of server performance. Use the measurement standard and service level agreements that you develop to help you plan for optimum hardware configurations for your SMS servers. Plan for capacity before you deploy the SMS site, and then make that plan an ongoing process after deployment.
Include the following steps in any planning model you develop: u u
u u u u
To avoid or rectify performance issues before they become serious, monitor server performance throughout the lifetime of the site, and make this part of your capacity plan for the SMS site. Modeling formulas can help you develop site capacity plans.
The following three sections can help you develop a capacity planning and server sizing model: u u u Capacity Planning Terms and Definitions Capacity Planning Tools Modeling Principles for Sizing and Capacity Planning
Capacity Planning Terms and Definitions

Before continuing, it is helpful for you to understand some of the terms that are used in this chapter to describe the capacity planning process. A model is a mathematical construct or formula that helps you understand how a physical system works within a defined set of parameters. Modeling typically uses a set of formulas that define performance characteristics, such as CPU utilization, transaction throughput, and transaction capacity. Because SMS server performance is affected by the type and number of transactions that SMS generates, these types of formulas are particularly useful. You can create a capacity planning model and use it to understand how SMS site servers and site systems perform, based on the design and configuration of the SMS site. Server sizing means determining the appropriate kinds of hardware that are required to process a specific amount of data in a specific amount of time. Hardware considerations include CPU, memory, disk array, and disk space. For example, if you have 50,000 SMS clients processing one hardware inventory delta file every five days, how does that affect SMS site server and SMS site database server performance? How is the CPU, memory, and disk usage affected by that task? When you are sizing servers and planning for current and future capacity, it can be difficult to define the service level agreement (SLA). The SLA represents the conditions of operation that all interested parties in a process agree upon. For example, the SLA might indicate that the SMS site server must experience no more than 85 percent utilization of server memory and must maintain a minimum of 15 percent available free disk space. A service request represents a task that is processed by the server, such as reading or writing a file to disk, or adding a record to a database. A queue length represents the number of service requests that are waiting to be processed by the server. In general, a small number one or two indicates that service requests are being handled in a timely and efficient manner. A service chain represents all the hardware resources that are used when a transaction or a service request is processed. This is sometimes referred to as a process flow. The total response time for the service chain is the sum of the response times for each service, resource, and transaction in the service chain.
A load signature is the set of the performance metrics of installed server components on a specific computer hardware configuration. Load signature on SMS component servers is affected by a variety of factors, including SMS hierarchy design, SMS site configuration, enabled SMS features, maintenance task frequency, and numbers of clients. The load signature for each site server is unique and is determined by measuring the usage of the SMS site components and their impact on hardware resources throughout daily, weekly, and monthly business cycles. The software in use, its level of usage, and its impact on hardware resources determine the load signature.
Capacity Planning Tools

It is important to have the appropriate tools available to help you understand how the SMS component servers perform in different scenarios. It is equally important to know how to use those tools effectively. The main tools that assist you in gathering server performance and network performance data are Windows System Monitor and Network Monitor, respectively. System Monitor is the recommended resource that is used for creating a server sizing model for SMS component servers. Use System Monitor to identify standards for acceptable server performance and to recognize periods of peak performance. The data that is collected is instrumental in both establishing and maintaining SLAs. Achieving this kind of analysis is a two-step process of baseline creation and real-time tracking. You create a baseline chart or log of acceptable server performance in accordance with the SLAs. You create real-time charts by using the same objects and counters that are used for the baseline chart, and then you compare them to the baseline charts to determine how server performance has been affected. Recommended System Monitor objects and counters are described later in this chapter. Network Monitor 2.1, included with SMS 2003, makes it easier to monitor and analyze network traffic that is generated among computers in the network. You use Network Monitor to identify heavily used subnets, routers, and WAN connections, to recognize where network bottlenecks occur, and to develop trends to optimize the network infrastructure and placement of SMS site servers and SMS site systems. For more information about how to install and use Network Monitor, see Chapter 10, Maintaining and Monitoring the Network, in the Microsoft Systems Management Server 2003 Operations Guide. As outlined in Chapter 8, Designing Your SMS Sites and Hierarchy, reviewing and testing the SMS site design in a lab environment is an essential task to determine sizing and capacity parameters within the network environment. Running a pilot project within the boundaries of the production environment, affected by the many external factors that can affect that performance, helps you identify how the network and servers perform within that environment.
Modeling Principles for Sizing and Capacity Planning

The first principle to consider when modeling for size or capacity is that you cannot determine appropriate hardware resource requirements without first creating a measurement standard for use of that hardware resource. Another way to look at it is that you cannot determine when the server is not performing optimally or within the bounds of the SLAs if you do not know how to measure optimal performance. The measurement standard is the baseline chart or log of acceptable server performance described in the last section of this chapter. There are several books that describe modeling principles and formulas in great detail. Because the SMS site database is a Microsoft SQL Server database, it is not unreasonable for you to consider applying many of the same principles and techniques that are used to determine appropriate hardware requirements for computers running SQL Server to your SMS component servers. For more information about modeling principles and server sizing formulas that are effectively applied to your SMS component servers, see Chapters 8-11 in the Microsoft SQL Server 2000 Performance Tuning Technical Reference, available from Microsoft Press. Among the many performance objects that you can track, there are three primary performance objects that you can track to determine server size and capacity. These are: u u u CPU utilization Disk utilization Memory (RAM) utilization
The key principle in achieving realistic and acceptable server performance is to avoid running the server at maximum hardware resource utilization on a regular basis. You must establish acceptable thresholds for hardware resource utilization to provide a reserve capacity for peak utilization periods.
CPU Utilization Thresholds

The relationship among CPU utilization, queue lengths, and response time is an important consideration when you are developing a sizing model for SMS component servers. There is a direct correlation between CPU utilization and queue lengths that affects the performance of a system. Generally, smaller queue lengths indicate better CPU performance. For most server configurations, queue lengths grow linearly until the processor reaches about 75 percent utilization as illustrated in Figure 9.1.
Figure 9.1 Graph of exponential queue length versus CPU utilization growth
20 18 16 14
Queue Length
12 10 8 6 4 2 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 Utilization (%)
At that point, queue length growth becomes exponential and rises quickly. This is referred to in some books as the asymptotic point. Whether your SLA stipulates 75 percent as a reasonable threshold between acceptable CPU utilization and a problem zone is up to you. As administrator, you are in the best position to understand the nuances of your own networking and server environment. Assume that your threshold for acceptable CPU utilization is 75 percent. You should expect that, on occasion, CPU utilization greater than 75 percent probably occurs for short periods of time. Nevertheless, the longer or more often such periods occur, the more likely queue lengths and response time are adversely affected.
Disk Utilization Thresholds

Similarly, disk utilization tends to take an exponential turn at about 85 percent. For example, a 9 GB disk should not store more than 7.6 GB of data at any given time. This allows for growth and helps keep response times at a reasonable level. By the same principle, if a disk has a read/write capability of 70 requests per second, a constant read/write arrival rate of more than 60 requests (70.85) per second in a steady state of operation indicates that the read/write capability of the disk is inadequate.
Memory Utilization Thresholds

Page faults occur when data cannot be found in memory and needs to be retrieved from disk. An operating system issues a page fault interrupt when a needed page of code cannot be found in its working set in main memory. The page fault interrupt prevents further processing until the required data has been retrieved from disk. Response time in memory is measured in microseconds (millionths of a second), whereas response time for disks is measured in milliseconds (thousandths of a second). This means that pages are retrieved from memory approximately 1,000 times faster than from disk. Consequently, to reduce the number of page faults that occur, you should increase the amount of memory in the computer.
Performance and Capacity Planning

Capacity refers to how well a server can adapt to increased demands, based on performance testing. Lab testing can identify capacity issues, such as network congestion that is encountered when the load on the SMS hierarchy increases. Capacity planning ensures that the actual load encountered by SMS is effectively managed by the hardware already in use. It is critical that you plan for capacity and performance not only before you deploy SMS, but also as part of your post-configuration capacity planning. You cannot accurately determine what hardware is required to successfully deploy SMS, or whether the current hardware is functioning optimally (in accordance with existing SLAs) without tracking the performance of key server hardware resources minimally CPU, disk, and memory. When you are planning for capacity and performance, ensure that the SMS component server hardware can handle increased capacity while your organization grows and changes. You should be aware of how data flows in the SMS hierarchy which data flows up from client to site system to site server to parent site (DDRs, inventory files, status messages, customized MIF information, and software metering data), and which data flows down from site server to site system and child site, and from site system to client (software packages, client installation components, and Advanced Client policy). See Chapter 2, Understanding SMS Sites, for a detailed description of data flow between sites. You calibrate performance by measuring throughput as load changes on fixed hardware configurations or by measuring throughput with a fixed load on differing hardware configurations. You gather performance data when you do lab testing, and then you review the data when you create and modify your SMS site design.
Monitoring Performance
An important step in troubleshooting backlogs and spotting load problems is to regularly observe key System Monitor counters and compare their values against the measurement standard and SLA values you recorded. The System Monitor (Perfmon.msc), is a snap-in control for Microsoft Management Console (MMC). It reads software counters that are built into SMS, SQL Server, Internet Information Services (IIS) 5.0, and Windows 2000 Server. You can also use it to log counter activity and set alerts. In addition to displaying information in a live chart view, System Monitor can log information to a file so that you can find load problems that occur at times when you are not monitoring the system. For more information about System Monitor, see the Microsoft Windows 2000 Server Resource Kit.
Key Objects and Counters

Table 9.1 lists the key system objects and counters to monitor. Keep in mind that the percentages outlined in the table represent recommended values only. You should determine optimum values for your own servers.
Performance and Capacity Planning 295
Table 9.1 System Monitor Objects and Counters

Object System Counter % Total Processor Time Instance Not applicable Comment Less than 80% means the level of processor performance is acceptable. Constant measurements above 95% mean there is cause for concern. Two or fewer means the level of processor performance is acceptable. Lower is better. You measure the thread counter to enable the processor queue length counter. Less than 80% means the level of physical disk performance is acceptable. The count minus the number of spindles on the disks should average less than two. (A RAID device would have more than one spindle.) If this value is smaller than the available amount of RAM, you have enough memory to support the running processes without excessive paging. If this value is consistently larger than available RAM, the computer is experiencing an unacceptable level of paging, and you must add more physical RAM Constant measurements greater than five indicate a requirement for more memory. 98% or greater is good because SQL Server queries are not delayed by paging off disk. Less than 80% means the level of processor performance is acceptable. Constant measurements above 95% mean there is cause for investigation.
System
Processor Queue Length
Not applicable
Thread
Context Switches/sec
_total
Physical disk
% Disk Time
Each disk
Physical disk
Current Disk Queue Length
Each disk
Memory
Committed Bytes
Not applicable
Memory
Page Reads/sec
Not applicable
SQL Server
Cache Hit Ratio
Not applicable
System
% Total Processor Time
Not applicable
Disk counters are disabled by default, because on x86-based computers, counters use five percent of CPU time. On faster computers, the impact of disk counters on system performance is insignificant. Because you cannot monitor disk performance with the counters disabled, you should either run only the disk counters locally, or run all of the counters remotely. Until you enable the disk counters, they always report zero. You can enable the counters by running DISKPERF -Y from the command line and then rebooting.
Important
Disk counter values are not exact on servers using hardware-based RAID because the disk controller hides the disk queue length data.
Note
It is recommended that you run performance counters remotely to minimize the effect on the SMS component servers performance.
SMS Performance Counters

Table 9.2 lists some of the pre-defined performance counters that are enabled when you install the SMS site server. Use these to track and log information about processes and tasks performed by SMS component servers and to help you determine load signatures. Table 9.2 System Monitor Objects and Counters for the SMS Site Server
Object SMS Discovery Data Manager Counter DDRs Processed/minute Description The number of discovery data records (DDRs) that Discovery Data Manager processed during its most recent minute. The number of DDRs waiting in Discovery Data Managers input queue (the last time Discovery Data Manager scanned the queue), minus each DDR processed. When a large number of DDRs are being copied to the input queue, this count can lag behind the actual number waiting to be processed. The total number of DDRs that Discovery Data Manager processed during its current session. The number of running threads. These are threads that are not blocked inside the Yield() functions. When this counter is associated with a single thread, instead of an entire process, its value will be zero or one.
Total DDRs Enqueued
Total DDRs Processed SMS Executive Thread States Running Thread Count
(continued)
Performance and Capacity Planning 297
Table 9.2 System Monitor Objects and Counters for the SMS Site Server (continued)
Object SMS In-Memory Queues Counter Total Objects Dequeued Description The total number of objects that the source component has added to the queue since the source and destination components were last started. The total number of objects that the destination component has removed from the queue since the source and destination components were last started. The number of inventory records (Management Information Format (MIF) files) that Inventory Data Loader processed during its last minute. The number of inventory records (MIF files) waiting in Inventory Data Loaders input queue (the last time Inventory Data Loader scanned the queue), minus each MIF file processed. When many MIF files are being copied to the input queue, this count can lag behind the actual number waiting to be processed. The total number of inventory records (MIF files) that Inventory Data Loader processed during its current session. The number of software inventory records (SINVs) that Software Inventory Processor processed during its most recent minute. The number of SINVs waiting in Software Inventory Processors input queue (the last time Software Inventory Processor scanned the queue), minus each SINV processed. The total number of SINVs that Software Inventory Processor processed during its current session. The number of software metering records that Software Metering Processor processed during its most recent minute. The number of software metering usage files waiting in Software Metering Processors input queue since the last time the Software Metering Processor scanned the input queue.
Total Objects Enqueued
SMS Inventory Data Loader
MIFs Processed/minute
Total MIFs enqueued
Total MIFs Processed
SMS Software Inventory Processor
SINVs Processed/minute
Total SINVs Enqueued
Total SINVs Processed
SMS Software Metering Processor
SWM Usage Records Processed/minute
Total SWM Usage Files Enqueued
(continued)
Table 9.2 System Monitor Objects and Counters for the SMS Site Server (continued)
Object Counter Total SWM Usage Files Processed SMS Status Messages Processed/sec Description The total number of software metering usage files that Software Metering Processor processed during its current session. The number of status messages SMS_STATUS_MANAGER processed in the most recent second.
When you install a management point in your site, a set of System Monitor counters specific to the management point are installed and enabled. Use those counters to help you track and log information about processes and tasks that run on the management point. Table 9.3 lists some of the management point counters that are enabled. Table 9.3 System Monitor Objects and Counters for a Management Point
Object SMS MP DAL Counter Connections Created Connections created/sec SMS MP Get Policy Cache hits/sec Requests/sec SMS MP PolicyMgr SMS MP HINV Mgr PA Requests/sec Delta Reports Report Size (Kb) Total Reports Total Reports/sec SMS MP SINV Mgr Delta Reports Report Size (Kb) Description The total number of database connections created by the management point. The number of database connections created by the management point per second. The number of policy requests resolved from cache on the management point. The number of policy requests generated per second on the management point. The number of policy assignment requests generated per second. The total number of delta hardware inventory reports generated. The average size of the hardware inventory reports generated during its current session. The total number of hardware inventory reports generated. The total number of hardware inventory reports generated per second. The total number of delta software inventory reports generated. The average size of the software inventory reports generated during its current session.
(continued)
SMS Activities That Affect SMS Server Performance 299
Table 9.3 System Monitor Objects and Counters for a Management Point (continued)
Object Counter Total Reports Total Reports/sec SMS MP Status Mgr Total Events Total Events/sec Description The total number of software inventory reports generated. The total number of software inventory reports generated per second. The total number of status messages generated during the current session. The total number of status messages generated per second during the current session.
SMS Activities That Affect SMS Server Performance

When you monitor the performance of hardware resources on SMS component servers, you gain insight into the way the server processes information under different conditions. It is important to spot potential problem sources, and to develop and analyze performance trends under different conditions, before problems materialize. Achieving this kind of analysis is a two-step process of baseline creation and real-time tracking. It is useful to examine different SMS server activities and how those activities alone and in combination can affect server performance. You should familiarize yourself with the activities that occur at site servers and at each site system, and you should understand how network communications among SMS servers and SMS clients within and between sites can affect server performance. For more information, see Chapter 3, Understanding SMS Features. Next, compose a list of SMS activities that might particularly influence SMS server performance in your SMS site. SMS activities fall into two categories: u u SMS server activities SMS-related network activities
Server Activities
SMS server activities that can affect overall server performance minimally include the following.
Active Directory discovery

Running Active Directory discovery on Active Directory domains that contain a large number of objects can create heavy throughput when the SMS site server needs to connect to an Active Directory domain controller and enumerate objects from Active Directory. Also, a backlog of DDR processing can occur on the SMS site server. Consider the potential effects of the following factors on the server performance before you run Active Directory discovery in large domains. All of the following can increase performance load on SMS servers: u u u u u u Running Active Directory discovery from the root of the domain or forest Maintaining very large domains with many systems and users Maintaining a large number of deeply nested groups (more than four to five tiers deep) Running Active Directory discovery from many SMS sites located within the same domain Running Active Directory discovery frequently Running Active Directory discovery during user working hours
Prior to running Active Directory discovery on a large domain, consider which systems, users, and groups you want to discover. You might choose to run discovery on selected containers, rather than on the whole domain. For more information see Chapter 17, Discovering Resources and Deploying Clients, and Chapter 10, Planning Your SMS Deployment and Configuration.
Propagating DDRs
Each DDR is relatively small by itself, but when many clients are discovered on a regular basis, this activity can use a lot of system resources. Discovery activities affect primary site servers and secondary site servers if Advanced Clients roam to secondary sites and client access points (CAPs) and management points. Various discovery methods are available. Activity level depends on the combination of methods used, the frequency at which they are used, and the number of clients involved.
Propagating inventory
A full hardware or software inventory can produce a large amount of inventory data. This data must be propagated throughout the SMS hierarchy. When many clients send this data to CAPs or management points at the same time, the load can be significant. The first time that hardware or software inventory is collected on the client, the appropriate SMS inventory agent on the client generates a complete inventory record. For subsequent inventory collections, the inventory agent calculates the difference between the current and previous hardware inventory (called a delta) at the client, and then uploads only the difference between the two inventories. This greatly reduces the amount of data that must propagate throughout the SMS hierarchy.
Inventory collection frequency is set on a site-wide basis. The timing and frequency of the inventory also directly affect server performance and network performance. For example, if you have 10,000 clients and set a start time for inventory collection at 11:00, then all 10,000 clients collect and send inventory either full or delta at 11:00. If no start time is specified, then the time when the Advanced Client policy for hardware inventory is received and processed by the client is the time the inventory is collected and sent. Because Advanced Client policies are polled on a configured cycle whenever the client computer is restarted , some randomization is introduced if no time is specified. However, you should plan the hardware requirements for the SMS component servers assuming that no randomization occurs. You can control the load on the clients, network, SMS site systems, and SMS site servers by: 1. 2. 3. Reducing the frequency of software and hardware inventory. Balancing inventory reporting requirements with acceptable server load. Testing the effects of different inventory frequencies in the test lab and during the pilot project.
Also, by phasing the rollout to clients, you can reduce the impact of processing inventory data. SMS inventories computers the day that they are installed as SMS clients. By default, SMS schedules these computers to conduct another inventory seven days later. By staggering the number of clients installed over a few days, you are also staggering the number of clients taking and reporting inventory information about subsequent inventory collections.
Propagating files between CAPs or management points and site servers

SMS moves files such as DDRs, inventory records, and status messages that reflect configuration changes, software distributions, and other client activities between CAPs or management points and SMS site servers. The activity pattern is often quite complex because of the interaction of many different components. The number of CAPs and management points within the site hierarchy can increase this workload on the site servers.
Distributing software from site servers to distribution points

One of the most important steps in distributing packages with SMS is getting the software to the distribution points. At the time that you distribute a package through the SMS Administrator console, the package source files are sent to the targeted distribution points. For large packages, this can place a significant load on the servers and network. However, you can control the load by managing the times when you distribute packages to distribution points. For example, you might choose to distribute packages during periods of lower network utilization such as at night or during the weekend. Delta replication for updates and refreshes of packages can also reduce the load. For more information about delta replication, see Chapter 5, Distributing Software, in the Systems Management Server 2003 Operations Guide.
Polling CAPs and management points for new advertisements

Legacy Clients poll the CAPs and Advanced Clients management points on a regular basis to determine if any new advertisements are available. The polling frequency is set on a site-wide basis. Each SMS Legacy Client accesses a small number of small files from a CAP, but depending on how often this occurs and the potential number of clients involved, this activity might be substantial.
Downloading software from distribution points to clients

When clients run advertisements, there is considerable activity when the package source files are downloaded from the distribution point. When a lot of software is distributed in a short period of time, there is also considerable activity from status files being sent to CAPs and management points.
Updating client configurations

Legacy Client computers compare their SMS configuration to the settings at the CAP every time they are rebooted, or every 25 hours, whichever comes first. This action consumes some hardware resources, but if configuration changes are required, there is more substantial activity. Advanced Clients check management points for these configuration settings (called Advanced Client policy) at the same time that they check for advertisements based on the policy polling period configured by the SMS administrator.
Maintaining databases
SMS site database maintenance tasks run on a routine basis to ensure that SMS runs efficiently. These tasks include: u u u u u u u Rebuilding database indexes Monitoring keys Deleting aged inventory history Deleting aged status messages Deleting aged discovery data Deleting aged collected files Summarizing software metering data
Because these tasks use CPU, memory and disk resources proportionate to the size of the SMS site database, it is important that you consider the effect that these tasks have on SMS site server performance. SMS performs these tasks automatically to maintain the SMS site database, but their frequency can be adjusted, and other tasks can be added. See Chapter 10, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide for a discussion of maintenance tasks.
Collecting status messages

SMS components report their status on a routine basis and as required, so that SMS administrators are aware of their status. SMS reports status about package distributions, advertisements, collection updates, site configuration changes, inventory updates, and all client activities. The status subsystem summarizes the collected status information to make it more useful to the SMS administrator. This summarizing process requires some processing time, and it results in queries and updates to the SMS site database. The summarizing process is highly configurable. Although you can significantly reduce the load on the site server by configuring how status messages are summarized and reported, it is important that you balance the appropriate server load with the appropriate number of status messages generated and reported.
Communicating between sites

Data sent between sites in an SMS hierarchy include status messages, site control information, collection data, package data, and advertisement data. You can significantly control site-to-site communications through the configuration of addresses and senders. The load is usually most significant on the wide area network (WAN) links, but there is some load on the sending and receiving servers. This is especially true when a site is sending data to multiple sites simultaneously. Because the SMS administrator is able to schedule when this data is sent, and how much bandwidth to use, the load can be balanced appropriately.
Software metering, server-side functions

How often software usage data is reported to the SMS site server and the amount of software metering data that is retained in the SMS site database determine how much processing power is utilized. Generally, running a larger report once per week is more efficient than running several smaller reports on a daily basis. You can choose when and whether to enable the summarizing task, and when summarization should take place. Nevertheless, the amount or type of summarized data that is transferred between sites is not configurable. Keep in mind that software metering summarization tasks run daily on SQL Server computers and are not configurable. In general, setting the software metering summarization interval to once every 7 days is sufficient. However, you should not set this interval any lower than once every 24 hours.
Polling CAPs and management points for software metering rules

On the Legacy Client, the polling schedule for software metering rules is configurable. On the Advanced Client, the software metering rules download with the Advanced Client policy.
Remote tools and network monitoring

Remote tools and network monitoring contact the SMS site server only when they are establishing the remote control session with the client and when they are verifying security in the remote control session. Otherwise, only the network, the SMS Administrator console, and SMS client computers carry the load for these activities. With network monitoring, the computer running the network monitoring agent carries the load. There is no load on the monitored client. The computer that is actually running the network monitor console experiences additional load.
Client communication with server locator points

When SMS clients request information from the server locator point, the server locator point queries the SMS site database. For example, the Server Locator Pointbased Client Installation program (Capinst.exe) runs a query to find CAPs each time an SMS client logs on. If the server locator point supports thousands of clients, this can add a significant load on the site server if the SMS site database is located on it. To reduce the load on the SMS site server, consider using SQL Server database replication for server locator points. For more information, see Chapter 15, Deploying and Configuring SMS Sites. Many of these activities depend on how you choose to use SMS 2003. These activities are also configurable, often with a tradeoff between timeliness and performance.
Network Considerations
The same activities that affect server performance can also affect network bandwidth utilization. Network Monitor is an effective tool to use to determine how SMS and other network-related processes affect network bandwidth utilization. All of the activities outlined in the preceding section can affect network bandwidth whenever those activities require communication between the SMS client and the SMS site server or between one site server and another site server. Additional SMS activities that affect the network are:
Polling intervals for client agents

The Advanced Client policy polling interval on clients is configurable on a site-wide basis. It determines the amount of load placed on the management point. It also determines the number of queries made by the management point to the SQL Server computer. The more clients you have in a site, and the more frequently you configure client agent polling intervals, the more traffic polling generates on the network. The following client agents have configurable polling intervals: u u u u Hardware Inventory Client Agent Software Inventory Client Agent Advertised Programs Client Agent Software Metering Client Agent
The Advanced Client polling intervals are based on those scheduled for software distribution in the Advertised Programs Client Agent. This includes requests for: u u u Site assignment New Advanced Client policy Location requests
Polling intervals for discovery methods

The process of discovering objects involves the request for an object, and a response containing basic information about the object such as its name or IP address. DDRs are relatively small (1 K on average). Nevertheless, the type and frequency of discovery that you configure can result in a large number of DDRs that are generated for specific periods of time. u u Windows User Account Discovery Windows User Group Discovery
If you enable Windows User Account Discovery or Windows User Group Discovery, you specify when the discovery method polls each domain. Discovery generates a new DDR for all user accounts or group accounts in each domain. u u Heartbeat Discovery Network Discovery
If you enable Heartbeat Discovery or Network Discovery, you specify the schedule when you want the discovery to occur. With Network Discovery you also configure how long you want discovery to run. To reduce network traffic, run Network Discovery from different servers, using a different configuration and schedule on each server. u u u Active Directory System Discovery Active Directory User Discovery Active Directory System Group Discovery
With the Active Directory discovery methods, SMS polls the closest Active Directory server to discover computers, users, or system groups in the containers specified. This process can cause significant network traffic, so you should plan to schedule it accordingly.
File sizes
The size of these files affects the load on the network when they propagate up the SMS hierarchy: u u u u u MIF Collected files Site control file Status summarizers Software metering summarization files
The size of these files affects the load on the network when they propagate down the SMS hierarchy: u u u Software metering rules (Meterrules.xml) SMS_def.mof Files related to software distribution
Client component installation

Every network-based client installation method that you choose to install the SMS client software on a computer consumes network bandwidth. SMS clients receive their component files from either a CAP for Legacy Clients or a management point for Advanced Clients. The number of files that are downloaded and the amount of bandwidth that is used depends on the client agents you configure. The method you choose can have some marginal effect on the amount of bandwidth. Installation methods include the following: u u Logon Scriptbased Client Installation Server Locator Pointbased Client Installation
The logon scriptbased client installation method uses a logon script to run Capinst.exe or a manual client installation. Capinst.exe finds a server locator point that provides the SMS client with a list of CAPs (for Legacy Client installation) or management points (for Advanced Client installation). A manual client installation can specify a CAP or management point to use for client installation. In either scenario, you have the added server and network performance overhead associated with running a logon script. u Software Distributionbased Client Installation Using SMS software distribution to install the SMS client software adds the additional network bandwidth and server performance loads associated with the SMS software distribution process. u Manual Client Installation Because you or the user initiates manual installation, you can control when and from what network location the SMS client software is installed. You can avoid periods of heavy network bandwidth utilization and the use of WAN connections. u u Client Push Installation Client Push Installation Wizard (resource-based and collection-based)
Client Push Installation finds newly discovered computers, initiates a remote connection to the computer, and installs the SMS client software. This method does not have the additional server performance load and network bandwidth load associated with the logon script installation method or manual installation method. The Client Push Installation Wizard controls installation of SMS client software by targeting collection membership or the results of an SMS query reducing the number of clients that are installed. u Advanced Client Installer The Advanced Client Installer is the manual method of installing the Advanced Client software. This method uses CCMSetup.exe to download the Advanced Client software to the computer before initiating the client installation. Because you or the user runs the Advanced Client Installer, you can control when and from what network location the Advanced Client software is installed. Similar to the manual installation method, in this scenario you can avoid periods of heavy network bandwidth utilization and the use of WAN connections. For more information about installation methods, see Chapter 4, Understanding SMS Clients.
Status messages and status filter rules

Most SMS components produce status messages. Its default settings are reasonable for most environments. However, how you configure the following three aspects of the SMS status system determines how much bandwidth status messages consume: u u u Status reporting Status filter rules Status summarizers
Filtering unnecessary status messages, and controlling how status messages are replicated from site to site can significantly reduce the amount of network traffic that status messages generate.
Remote secondary site installations

If you install the secondary site from the primary site server (by using the SMS Administrator console), then you potentially consume a great deal of bandwidth because all necessary installation files are downloaded from the primary site across the network connection, and because the network connection can include a WAN connection. Installing from a mapped network drive also produces significant network traffic. Alternatively, you can insert the SMS 2003 disc in a CD drive on the secondary site server and have SMS install all files from the local disc. The latter produces less network traffic than installing a secondary site from the primary site server.
Remote SQL Server

SMS and SQL Server communicate constantly. It is not recommended that you install your SMS site database SQL Server on a computer other than the SMS site server computer. If you must have SQL Server installed on a remote computer, then analyze the intervening network connection to ensure that it is well-connected. You might consider installing a second network adapter in both the SMS site server and the SMS site database server, and then dedicating this second card for communications between the site server and the computer running SQL Server. You can significantly increase the performance of SMS if the SMS site database and the SMS site server are both on the same computer, provided that computer has sufficient processing power to accommodate both roles.
Server locator point queries

SMS clients access server locator points when Capinst.exe is run to resolve site assignment and to provide a list of CAPs to the Legacy Client and a list of management points to the Advanced Client. Advanced Clients access a server locator point under the following conditions: u u u The Advanced Client is not yet assigned to a site and is in auto-assign mode. Active Directory is not yet extended with SMS extensions, and SMS is not publishing its component servers to Active Directory. The server locator point has been registered in WINs.
In this scenario, the Advanced Client accesses the server locator point at every auto-assignment cycle until the client is assigned to an SMS site. The network bandwidth utilization for a single client is insignificant. As more clients access the server locator point, network bandwidth utilization grows proportionately.
Package download for software distribution

Within an SMS site, package source files are sent when the SMS administrator designates a distribution point. In this scenario, SMS copies all package source files to the distribution point without compressing the files. This can place a significant load on network bandwidth utilization. When SMS sends package source files to a distribution point at an SMS child site, those files are compressed first. When they are received at the SMS child site, they are uncompressed and sent to the designated distribution point. In this second scenario, you can control how network bandwidth is utilized during site-to-site communications.
SQL Server database replication

Server locator points and management points can be configured to perform SQL Server database replication. This adds a new path for network traffic from the management point or server locator point to another SQL Server database. When you configure a site system to use a different database, the data is replicated from the SMS site database to the replicated database. Replication occurs thereafter each time a related setting is changed on the site server. This reduces the performance load on the SMS site database and reduces network bandwidth utilization if the replicated database is on the same server as the server locator point or management point.
Active Directory authentication

SMS activities authenticate in various ways, some more frequently than others. Authentication by SMS processes can affect network bandwidth, although the impact is minimal. Keep in mind that a large site with a lot of clients must respond to a greater number of authentication requests from those clients. Try to avoid client authentication over a WAN link.
Software metering
Be aware that, as the number of software programs monitored by software metering increases, the load on the network increases. Network traffic also depends on how you configure the software metering data collection schedule and the software metering rules download schedule.
Proxy management point

Advanced Clients can be assigned only to a primary site. Advanced Clients that roam to a secondary site across a WAN link can produce a significant load on network bandwidth utilization because client status and hardware or software inventory data is sent to the parent primary site. Advanced Client policy requests from the Advanced Client also reduce the available bandwidth between the two sites. Installing a proxy management point at the secondary site can significantly reduce the effect on available network bandwidth created by Advanced Clients located within that sites roaming or site boundaries. Advanced Clients send inventory and status data to the proxy management point. The proxy management point uses the SMS sites sender functionality to transfer the data to the primary site. The SMS administrator can control how the sender utilizes bandwidth. Because proxy management point also caches some policy information, Advanced Clients can obtain this policy information from the proxy management point, rather than from the management point at the primary site. For more information about implementing management points and proxy management points, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Sizing SMS Component Servers 309
Sizing SMS Component Servers

System Monitor is an effective tool for determining server performance. Remember that the process of sizing servers is not a one-time task. Server sizing is initially done to determine the appropriate server hardware given a specific operating scenario, such as supporting 50,000 clients running hardware and software inventory, and running five packages a day. However, you should continue to monitor the servers performance after you deploy SMS to ensure that that server continues to perform within acceptable thresholds. Ultimately, it is the server performance that determines the appropriate server hardware configuration and the need for future modifications, perhaps in the form of upgrades or replacement of equipment. This section covers the following topics: u u u Setting Expectations and Service Level Agreements Methods and Formulas Used to Determine Server Capacity Determining Primary and Secondary Site Server requirements
Setting Expectations and Service Level Agreements

Setting expectations for server and network performance and agreeing on acceptable levels of service is perhaps one of the hardest tasks to perform, yet a very necessary task when you are determining a sizing and capacity strategy for your SMS deployment. SLAs are the most common ways to establish conditions of operation agreed upon by all parties involved in the operation and performance of the system. One SLA might specify that the workload item or transaction in question should process within a certain span of time, for example, five seconds. Another SLA might specify that no more than 85 percent of memory can be used to ensure that page faults are kept to a minimum. If a violation of an SLA occurs, it generally indicates a hardware resource failure or overload that might require an upgrade or replacement of equipment. Consequently, performance tracking is an integral part of creating realistic SLAs.
Methods and Formulas Used to Determine Server Capacity

You can understand a servers workload and capacity when you determine the kinds of tasks carried out on that server. The performance statistics that are calculated by System Monitor reveal the effects of those tasks. You can use these statistics with a number of standard mathematical formulas to help determine server size and plan for capacity and growth.
Basic Model of System Capacity

There are three variables that form the basic model of system capacity. These variables are u u Observation time (T), the amount of time that the server is monitored for activity Busy time (B), the amount of time that the server was active during the observation time
Completions (C), the number of transactions completed during the observation period
With these three variables, you can calculate the six significant values, described in Table 9.4, that are used to develop a capacity planning model. Table 9.4 Capacity Planning Data Formulas
Data CPU Utilization Transaction throughout of the system Average service time Transaction capacity of the system Average queue length Average response time Description The percentage of CPU capacity used during a specific period of time. The average number of transactions completed during a specified period of time. The average time to complete a transaction. The number of transactions the server handles. The average number of transactions in queue. The average time to respond to a transaction. U = B/T X = C/T Formula
S = B/C Cp = 1/S Q = U/(1-U) R = (QS)+S
Here is an example of how to use these formulas to size a server. Suppose that you observe the server for 60 seconds (T), during which time there are 90 completed transactions (C), and the server is actually busy processing that workload for 48 seconds (B). Table 9.5 shows the resulting data values using this information. Table 9.5 Capacity Planning Resource Formula Results
Resource CPU Utilization Average transaction throughput of the system Average service time Transaction capacity of the server Average queue length Average response time Formula U = B/T X = C/T S = B/C Cp = 1/S Q = U/(1-U) R = (QS)+S Result 48/60 = 80 percent utilization 90/60 = 1.5 transactions/sec 48/90 = .53 seconds 1/.53 = 1.875 transactions/sec .8/(1 - .8) = 4 transactions (3 .53)+.53 = 2.12 seconds
The CPU utilization was at 80 percent, and handled an average of 1.5 transactions per second. The average service time for these transactions was .53 seconds, and transactions were completed in an average time of 2.12 seconds. On average, there were four transactions waiting to be processed at any given point in time during the observation period, and the server had the capacity to process 1.875 transactions per second.
If the SLA states that during any given 60 second period, the server should not utilize more than 85 percent of the processor and should be capable of handling at least 100 transactions, the calculated values shown in Table 9.5 indicate that the SLA is being met. If the SLA stated that during any 60 second period, the server should not utilize more that 75 percent of the processor or should not have more than three transactions waiting in queue, then the calculated values shown in Table 9.5 indicate that the server cannot perform within the limits of the SLA and probably must be upgraded. Use these formulas as tools to help you to determine current server performance levels, to develop acceptable and reasonable SLAs given current and expected server hardware configurations, and to identify where upgrades or new equipment is necessary.
End-to-End Response Time

When you consider response time, you should not think only in terms of a single servers response time and performance, but instead you should think of all the data components that make up the service chain for that transaction. So, the first step in determining end-to-end response time is identifying the data components that make up the service chain. For example, consider that information flows from an SMS client to a CAP or management point, and then to the site server. The service chain that emerges from this flow has five data components associated with it as shown in Figure 9.2: u u u u u Client Q, R, and S values Network connection between client and CAP or management point Q, R, and S values CAP or management point Q, R, and S values Network connection between CAP or management point and site server Q, R, and S values Site server Q, R, and S values
Figure 9.2 A service chain and the computation of end-to-end response time
1 Client R1=(QxS)+S 2 Network R2=(QxS)+S R3=(QxS)+S 3 CAP or Management Point 4 Network R4=(QxS)+S 5 Site server R5=(QxS)+S
The end-to-end response time, then, is the sum of each of the R values for each component in the service chain. Use this information to develop SLAs for service chain performance, and to determine when there are performance aberrations. There are no standard metrics for SMS performance. Your organization might want to consult its SLAs and perform a cost-to-benefit analysis to determine how fast the SMS site servers must run. Your organization might have time requirements. For example, mission-critical applications might require updating on 95 percent of desktops in an eight-hour period. Another SLA might state that critical virus signature update files must be distributed to all desktops within a two-hour period.
After running a pilot project and discovering the cost to distribute the package to all desktops on the network in four hours, you might compromise on a reduced hardware configuration and accept a window of five hours to complete the distribution. In general, faster response times require more expensive hardware, and lower acceptable response times require less expensive hardware. Because many SMS service requests come in surges, most SMS sites have service request backlogs that last for at least a few minutes. The two most common surges occur during the user logon cycle and when you send package advertisements. While you experiment to find the least expensive hardware configuration to meet your needs, consider future growth requirements and the potential for change, and monitor the SMS site for backlogs. If a site is backlogged most of the day and catches up between 3:00 A.M. and 4:00 A.M., then there is a risk that the site cannot catch up if the weekly load increases. Plan for extra capacity so that you can quickly meet unexpected software distribution or other feature demands. Also, when SMS users and administrators become familiar with SMS, their usage levels increase.
Determining Load Signatures

The combination of business objectives and operational styles in every organization creates unique load signatures. However, if an organization has ten remote offices with the same number of workers, the same software, and the same hardware, and you manage them all similarly, then they all might have a similar load signature. Grouping computers with similar load signatures can reduce planning time. By determining the load signature of servers in the SMS site, you can plan for an appropriate hardware component capacity. Then, by changing hardware capacity, you can increase or decrease the responsiveness of SMS and the time required to accomplish specific tasks. The load signature is determined by several factors, including: u u u u u u 1. 2. 3. 4. Number of optional SMS features installed and in use on the computer Location of site server in the SMS hierarchy (whether it communicates with parent or child sites) Number of objects in the site Size of objects being processed Frequency of scheduled events Frequency of feature use Define the load signature for each site component server. Determine throughput requirements using the formulas documented in this section. Use the throughput requirements to estimate hardware requirements. Use the hardware requirements to construct sample SMS configurations to test in your isolated test lab and later in the pilot project.
To successfully determine server sizes for an SMS hierarchy:
Testing your hardware configuration and conducting a successful pilot project helps ensure that your organizations deployment progresses smoothly, because the deployment itself is based on site designs customized for your organizations data and tested in your environment.
Determining Site Server Hardware Requirements

The hardware required for SMS site servers largely depends on the SMS features that you choose. When your business grows and changes, the SMS site server hardware requirements change accordingly. For the initial SMS deployment, you must develop initial hardware requirements that you can use to start the pilot project. To estimate hardware requirements for each SMS site server, determine the following: u u The number of clients you plan to install and the number of SMS objects you expect to have at the site. The load signature of installed SMS components.
It is important to build SMS site servers with as much fault-tolerant hardware as economically possible. Determine the load signatures of primary and secondary site servers, in addition to all other servers that are assigned SMS roles. After you have determined the load signature for the site component servers, you can establish initial hardware requirements. The recommendations in this section are based on a number of factors, such as the number of clients and the number, size, and frequency of objects processed by SMS. Regardless of these recommendations, performance results might vary. Consider all the factors and carefully select server hardware based on all potential variables in your environment. Important factors include: u SMS features enabled: u u u u u u u u u u u u u Number of collections and their refresh schedule Software distribution (frequency and size) Software metering Discovery methods used Hardware and software inventory frequencies Hardware and software inventory sizes Reporting Software Update Management
Available network capacity Other applications sharing SMS server hardware Number of clients in the SMS site User community and acceptable performance through service level agreements Budget constraints
Use the following guidelines when you develop your SMS site server sizing plan: u u At small SMS sites, processor, memory, and disk resources are generally not big issues and are easier to track and maintain. At medium SMS sites: u u u u Memory must grow proportionately to the number of clients. Disk I/O becomes a potential performance bottleneck; consider a RAID configuration. Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider dual processor servers. Memory must grow proportionately to the number of clients. Disk I/O becomes a likely performance bottleneck; consider a RAID configuration such as RAID 1+0, and separate hardware volumes and channels for increased performance. Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider quad processor servers.
At large SMS sites: u u u
The hardware requirements you develop after reading these sections are for production purposes only. For the test lab and pilot project, these numbers might require adjustment, based on the fraction of the production environment included in the pilot deployment. For more information, see Chapter 10, Planning Your SMS Deployment and Configuration.
Consider using SCSI RAID disk controllers

Hardware-based SCSI RAID controllers provide redundancy in the event of disk failure. Also, they can improve system performance when they are implemented. Many SCSI controllers provide read/write caches that can greatly reduce CPU usage during times of increased load. SCSI RAID controllers also spread read/write operations across multiple disks, and improve disk access times. The following is a sample SCSI implementation plan for a site server: Channel 1 4 volume RAID5 array for the SMS site database Channel 1 2 volume RAID1 array for the Windows system files, the SQL Server master database, and the systems virtual memory paging file Channel 2 6 volume RAID5 array for SMS Channel 2 2 volume RAID1 array for the SMS SQL Server transaction log (write caching disabled) Depending on a number of configuration factors, medium-sized primary sites (1,0005,000 clients) and large primary sites (20,00050,000 clients) might determine disk input/output (I/O) to be a bottleneck. For this reason, consider separating hardware volumes and channels for performance with a SCSI RAID controller.
The use of high-end SCSI controllers and disks is recommended for SMS site servers that are servicing a large number of clients and using many SMS features. However, budget limitations might prevent the feasibility of this. SMS works well on current integrated device electronic (IDE) disks. IDE disk subsystems are not as recoverable, but they can perform adequately. In general, if you are in a medium to large organization, you should consider the following tips when you are building SMS site system hardware: u u Place the SMS site server and SMS site database on different channels (if you are using SCSI hardware). Neither the SMS site nor the SMS site database share their disks with other applications.
Configure the SQL Server transaction log to run on a different disk than the disk where the SMS site database is located.
Estimating the Number of Clients and Objects

The hardware requirements of SMS site systems depend on the number of objects that the site servers must process. Objects are items that are processed and stored in the SMS site database. SMS uses objects to move and store client and server data. Each SMS feature creates different types of objects. The following are the most common objects: u u u u Discovery data records (DDRs), which are produced by discovery methods Hardware inventory files: hardware inventory complete (.hid), hardware inventory delta (.hid), and Management Information Format (MIF) files Software inventory files: software inventory complete (.sic) and software inventory delta (.sid) Status variable files (.svf)
You can configure many SMS components to control the number of objects they produce. Table 9.6 lists common objects generated by SMS components. Table 9.6 Objects Generated by SMS Components
Component Heartbeat Discovery All other discovery methods Hardware inventory Software inventory Software distribution Objects generated per interval 1 DDR per heartbeat interval 1 DDR per object found 1 status message and 1 MIF file per inventory interval 1 status message and 1 .sic or .sid file per inventory interval 6 status messages (.svf) per new advertisement 2 status messages (.svf) per existing advertisement
(continued)
Table 9.6 Objects Generated by SMS Components (continued)

Component Software metering - Legacy Client Objects generated per interval 1 rule file (.mux) and 1 status message for each cycle 1 status message for each usage report upload 1 status message each time a software metering rule is added or deleted from its policy 1 status message for each usage report upload
Software Metering - Advanced Client
The initial hardware and software inventory on clients is a complete inventory. Subsequent inventories produce delta inventory files that contain only changes to configuration , are smaller, and process faster than a complete inventory. When you perform sizing tests, however, be sure to consider that SMS occasionally requests an inventory resynchronization. When this happens, all the clients in the site report full inventories during their next inventory collection cycle. The site can become overwhelmed in this peak situation if you are using network connections, or server hardware that can only maintain the flow of the smaller delta inventory. For more information about the resynchronization process, see Chapter 3, Understanding SMS Features. Table 9.7 offers another way to look at objects that are generated given a specific site configuration. The numbers in this table are based on the following configuration: u u u u u u u u SQL Server 2000, installed on the same computer as SMS A five-day work week Three new advertised programs sent to all clients every week All SMS site systems running Windows 2000 Server SP2 or later Heartbeat Discovery run once per week Hardware inventory run once per week (MIF generation) Software inventory run once per week (.sic and .sid generation) Status messages enabled (.svf generation)
Number of objects per client per week produced with the specified configuration 1 1 1 1 (Legacy Client only) 22
Table 9.7 Number of Objects per Client per Week

Object type DDR MIF .sic or .sid .mux .svf
The values represented in Tables 9.5 and 9.6 are starting points. Use the values to facilitate the evaluation of your own site. Performance can vary considerably between organizations because of numerous variables, such as the number of clients, type of hardware, and available network bandwidth. The data is also based on the assumption that the SMS Administrator console is run remotely most of the time, instead of being run directly on the site server. If you plan to use the SMS Administrator console heavily on the site servers, consider a faster CPU and more RAM for the site servers to improve the performance of the console.
Note
The total number of clients in a site is actually the number of clients that physically belong to that site plus the number of clients that belong to the sites lower level sites. In addition, if you enable discovery of users and groups, the total number of manageable objects can increase significantly.
Developing Initial Hardware Requirements

Using the performance metrics derived from monitoring the system, from the capacity models and values you generated, and from the system load signatures you identified, you can plan initial hardware requirements for the SMS site servers. Document these requirements in your SMS 2003 project plan. Ideally the hardware recommendation should meet the following requirements: u u u Zero processing backlog Responsive help desk operations from remote consoles Additional processing capacity to ensure timely recovery and minimal hardware cost
However, these numbers might require adjustments when you perform testing in your own lab environment and run the pilot project as described in Chapter 10, Planning Your SMS Deployment and Configuration. For small remote secondary sites that service the organization by managing only a small number of clients, you might need only very basically equipped computers. By using basically equipped computers in these cases, you can save a substantial amount of money. For SMS 2003 sites that manage more than 100,000 clients for example, a central site with no clients assigned to it you should use quad-processor high-end computers with highperformance disk subsystems and plenty of memory. Because the performance variables become unpredictable at this size, it is especially critical that you run a pilot project to properly estimate the site server hardware.
Determining Site System Hardware Requirements

The CAP, distribution point, server locator point, management point, and reporting point roles require special consideration when you plan hardware requirements. This section describes these considerations.
Client access point

A CAP is primarily responsible for relaying the majority of the objects sent from Legacy Clients to the site server. It provides clients with the SMS 2003 client components during Legacy Client installation. The following items affect the load on a CAP: u The number of features that are enabled u u u u u u u Inventory collection Software distribution Software metering Status messaging
The number of Legacy Clients in the site The number of CAPs in the site The number of total users in the site if you are targeting users for software distribution.
The CAP is also responsible for providing the files the client requires to perform software installations. The Legacy Client connects to this computer on a regular basis to check for new packages to install. In addition, the SMS Executive service and Inbox Manager Assistant run on this site system.
Note
All the CAPs in an SMS site contain all the files required for all the clients in the site regardless of which CAP a client actually uses.
You should also consider the data sent from clients to CAPs when you consider the appropriate hardware configuration for CAPs. This data includes discovery files, inventory, and status messages. You should be aware that the load on a CAP increases at the following times: u u u u u u u During discovery During SMS Legacy Client deployment During software inventory (including file collection) on the Legacy Client During hardware inventory on the Legacy Client When a new advertisement is sent to the Legacy Client When status information is sent up from the Legacy Client When a large number of users log on to Legacy Client computers simultaneously
When you distribute greater amounts of software, you increase the amount of status that is propagated up the SMS hierarchy. The more inventory requirements you add to the SMS_def.mof file for hardware inventory, the larger the inventory becomes. The more files you collect with software inventory, the greater the amount of space required on the CAP. The shorter you configure the CCIM cycle, the higher the peak load on the CAP.
You can reduce the load on CAPs by: u u Increasing the number of CAPs in the site Lengthening the polling intervals for Legacy Client agents u u u u Inventory collection Software distribution Software metering
Scheduling advertisements for nonpeak periods
Note
One of the issues to consider with large sites is that some Legacy Client software distribution files become very large as the number of clients increases. In some cases, each client within the site must read the same client lookup file on the CAP. By increasing the number of CAPs in the site, you decrease the load across all CAPs in the site. The more CAPs deployed within the site, the better the performance is for the client. However, the more CAPs in the site, the more replication of files between the CAPs and the site server. Consequently, the load increases on the site server. Testing in your isolated test lab is the only way to determine the optimum solution of this balance for your environment. Start by deploying a minimum number of CAPs within this test environment. Then gradually scale up the number of clients in the site until youve reached optimum performance for the configuration.
The main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Legacy Clients communicate with CAPs, see Figure 8.3 in Chapter 8, Designing Your SMS Sites and Hierarchy.
Management point
You should size the management point server similarly to how you sized the CAP, because their roles are very similar. When you document the hardware requirements, remember that the management point also requires IIS. CAPs are simple file shares. Files are copied to them and forwarded to the SMS site server. Management points do additional processing of the files. CAPs use more disk space than management points, but management points use more processing time. Management points cache Advanced Client policy assignments for clients and as a result, memory is more of a concern than it is for CAPs. The following items affect the load on a management point: u The number of features that are enabled u u u u Inventory collection Software distribution Software metering Status messaging
u u
The number of Advanced Clients in the site The number of proxy management points (placed in a secondary site) in the site.
The management point relies on the SMS site database for its client responses. One sizing consideration is the performance of SQL Server. If performance is slow, plan to implement an additional SQL Server for replication purposes. You can reduce the load on management points by: u u u u Lengthening the Advanced Client policy polling interval. Scheduling advertisements for nonpeak periods. Implementing an additional SQL Server to replicate the SMS site database. Deploying multiple management points using Windows Network Load Balancing Service.
As with the CAP, the main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Advanced Clients communicate with management points, see Figure 8.3 in Chapter 8, Designing Your SMS Sites and Hierarchy.
Note
Advanced Clients are managed by Advanced Client policy. This architecture is more scalable than CAP architecture. The replication issues mentioned for CAPs do not exist for management points. Each management point is able to support many more clients than a CAP can support. For sites consisting of a large number of Advanced Clients, the capacity planning strategy consists of deploying multiple management points using Windows Network Load Balancing Service and SQL Server database replication.
Distribution point
SMS 2003 clients access a distribution point to retrieve the package source files that are required to run advertised programs. Determine hardware configuration requirements for distribution points just as you would for any other file servers in the organization. For example, a large organization might have tens or hundreds of clients requesting 100 MB files from a distribution point. Software packages vary in size, so plan accordingly. The following items affect the load on a distribution point: u u u u u The number of packages you distribute The number of clients in the site The number of distribution points in the site. Deploying one distribution point for each network segment within a site. Deploying protected distribution points for network segments where bandwidth utilization causes a bottleneck.
You can reduce the load on distribution points by:
u u u
Scheduling software distribution for nonpeak periods. Scheduling advertisements for nonpeak periods. Keeping target collections small.
You can control the load on distribution points by carefully scheduling software distribution. For example, if you are distributing Microsoft Office to the organization, you might want to spread out the load by creating several small advertisements targeted to different collections at measured intervals throughout the night. Alternatively, you can roll out Microsoft Office to every client at one time, but spread the load across multiple distribution points. Also, you can limit the load on the distribution point by limiting the number of simultaneous connections allowed.
Note
When you are distributing packages to child sites, you can also 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 sites, through child sites rather than distributing the package directly. Fan-out distribution occurs automatically if the initiating site does not have an SMS address for the destination site. For more information, see Chapter 3, Understanding SMS Features.
The main performance objects to track for sizing and capacity are those related to disk utilization, particularly read/write activity, and CPU utilization when read/write requests queue up quickly.

A server locator point is used primarily in client installation and is generally implemented in the SMS central site because the central site has information about the SMS hierarchy and the structure of the SMS sites in that hierarchy. It provides site assignment information and locates a CAP for Legacy Clients, or a management point for Advanced Clients, and directs the client there to complete installation. When you document the hardware requirements, remember that the server locator point also requires IIS. The following item affects load on a server locator point: u Client access for site assignment and installation If you have enabled the logon script-based installation method, the Legacy Client accesses a server locator point at client logon time and produces minimal network traffic approximately a 1 K upload and a 1 K download to the client. Similarly, the Advanced Client accesses the server locator point at client logon time for auto-assignment at its initial logon time, and generates the same amount of traffic as the Legacy Client. However, server locator points do rely on accessing the SMS site database to obtain information about CAPs and management points, so it is necessary to monitor the network traffic generated between a server locator point and the site database server. For more information, see Chapter 8, Designing Your SMS Sites and Hierarchy.
You can reduce load on server locator points by: u u Creating a phased roll-out of SMS client software Implementing an additional SQL Server to replicate the SMS site database
Reporting point
A reporting point provides read-only access to SMS reports using IIS. The reporting point can be installed on any computer running IIS, including the SMS site server. The following items affect load on a reporting point: u u The number of custom reports you create The number of SMS users that require access to the reports
Because people require SMS information in many different forms, the requirements for SMS reports can vary widely. Depending on the amount of data and the complexity of the reports, SMS reporting can use considerable system hardware resources. You can reduce load on reporting points by: u u u Deploying the reporting point on a server other than the SMS site server. Scheduling large reports to run at nonpeak times. Creating multiple reporting points for a site and assigning groups with similar reporting needs to a specific reporting point.
Note
Depending on the load that is generated during your lab test, you might consider deploying the reporting point on a dedicated server.
Determining SMS Site Database Server Requirements

SMS 2003 depends on SQL Server as its database engine. The database device configuration of SQL Server and the hardware resource needs of SMS 2003 are linked and have hardware interdependencies. It is recommended that the SMS site database be installed on the SMS site server. The performance of SMS 2003 is directly related to the performance of SQL Server. You must be sure to provide adequate hardware resources for both applications. To do so, you need a clear understanding of how these two applications work together.
Should SQL Server be installed remotely or locally?

SMS 2003 performs best when SQL Server is dedicated to SMS 2003 only. You can also significantly increase the performance of SMS if the SMS site database is installed on the same computer that performs the SMS site server role if the server has been sized to accommodate both applications. Running SQL Server on the site server computer reduces network load. If you are using SQL Server for other applications within your organization, you must decide whether to use a remote installation of SQL Server for those applications. Running the SMS site database on the SMS site server is considered a best practice. Running SQL Server on a computer that is not the site server only benefits the site if you are using SQL Server for other applications within your organization.
Disk input/output is the most important factor in deciding where to locate the computer running SQL Server. Installing the data devices and log devices onto separate physical disks or RAID arrays improves the disk performance of SQL Server and indirectly benefits the performance of SMS.
How much data is written to the SMS site database on a daily, weekly, and monthly basis?
You can determine the amount of data written to the SMS site database by reviewing the number of clients that are reporting to the site and by reviewing the overall usage patterns, such as the flow of status messages, hardware and software inventory records, and DDRs, into the SMS site database. The total amount of data that SMS writes to the SMS site database can dramatically change the hardware that is required to optimize SQL Server performance. Often, if a large amount of data is written to the SMS site database only once per month, you require less processor power and disk space for SQL Server. Similarly, if a large amount of data is written to the SMS site database only during a particular part of the day, and you are not enabling many SMS features that require SQL Server processing, the server running SQL Server requires less processing power and disk space. SQL Server uses memory for extensive caching. If it is given more memory, it uses it and runs more efficiently. Limiting SQL Server memory to a specific maximum amount reduces page faults and improves server performance. For more information about tuning the SQL Server memory cache, see the SQL Server documentation. Another issue to consider when you are determining the hardware requirements for SQL Server and SMS component servers is the total amount of data that is likely to accumulate in the SMS site database. If you have an accurate and complete picture of the network before you run the pilot project, you can begin to estimate the amount of data that can accumulate and the size of the database required to store it. To estimate the required SMS site database size for a single site, use the following formula as a baseline: 50 MB + (x 220 KB) (where x is the number of clients in the site) This formula is based on the following site settings: u u u u u u Weekly hardware inventory, default SMS_def.mof Weekly software inventory Delete aged discovery records after 90 days Delete aged inventory history after 90 days Delete aged status messages after seven days Weekly software metering summarization
The formula also allows for as many as 20 status messages per client, per week.
The algorithm used by SMS 2003 Setup allows 220 KB per client with a minimum SMS site database size of 50 MB.
Note
This value must be adjusted if these settings change. For example, if the default SMS_def.mof is modified to include additional inventory items being reported, the value might increase significantly.
After you have sized the database, then use the formulas and System Monitor counters suggested earlier in this chapter to generate a complete size and capacity plan for the site database server.
C H A P T E R
1 0
Planning Your SMS Deployment and Configuration

Before you run Microsoft Systems Management Server (SMS) 2003 Setup, it is important that you allocate plenty of time and resources to planning your SMS deployment. This planning can occur with both the hierarchy design phase described in Chapter 8, Designing Your SMS Sites and Hierarchy, and capacity planning, described in Chapter 9, Capacity Planning for SMS Component Servers. In the hierarchy design phase, you design your SMS sites and test them in a representative test lab that closely replicates your production environment. Based on these test results, you create a deployment and configuration plan, test the plan, and run the pilot project. Finally, you refine your deployment plan and any necessary hierarchy design modifications based on the analysis and the conclusions from the pilot project. Only then are you ready to deploy SMS 2003 in your production environment.
In This Chapter
u u u u u Strategies for Planning Site Deployment Planning Site Configuration Planning Client Deployment Planning The Pilot Project
If you follow the guidelines in the rest of the Planning part of this book and complete the steps in this chapter, you should be well prepared to deploy SMS 2003. This chapter does not describe any scenarios for upgrading to SMS 2003. If you plan to upgrade to SMS 2003, see Chapter 14, Upgrading to SMS 2003.
326 Chapter 10 Planning Your SMS Deployment and Configuration
Strategies for Planning

Your goal is to deploy and configure SMS successfully and efficiently, with minimum interruption to your users and the network. Proper planning and a well-documented pilot project can help you achieve this. Divide your deployment and configuration into phases, communicating and documenting the results at each phase. See the High Level Planning section for guidelines on dividing your deployment and configuration into phases. As you do this, review the Key Elements to a Successful Deployment section later in this chapter. A sample high-level deployment plan is provided at the end of this section. For more information about deployment scenarios, see Chapter 1, Scenarios and Procedures for Deploying SMS, in the Microsoft Systems Management Server 2003 Operations Guide.
High Level Planning

Plan your steps, and then document the results as you proceed from one step to the next. There are four general phases in an SMS deployment: u u u u Site deployment Site and hierarchy configuration Client deployment Feature configuration
In the site deployment phase, you install your SMS sites. In the site and hierarchy configuration phase, you configure each site and build a hierarchy by attaching sites. In the other phases, you deploy your clients and configure the SMS features you want to use, such as software metering. Feature configuration is not covered in this book. For information about configuring features, see the Microsoft Systems Management Server 2003 Operations Guide. Table 10.1 shows the high level steps for deploying and configuring an SMS hierarchy and SMS clients. Depending on the complexity of your SMS hierarchy design, and the size of your computing environment, you might perform these steps in varying order in different areas of your organization. Table 10.1 High Level Deployment and Configuration Steps
Phase Site deployment Install primary sites. Install secondary sites. Steps
(continued)
Strategies for Planning 327
Table 10.1 High Level Deployment and Configuration Steps (continued)

Phase Site and hierarchy configuration Steps Configure site security. Configure tasks, alerts, and status system. Configure site boundaries and roaming boundaries. Prepare site system computers. Assign site system roles. Configure site communications. Attach SMS sites. Enable resource discovery and client installation methods. Enable and configure the SMS client agents.
Client deployment Feature configuration
You can approach deployment and configuration in different ways, depending on the size and complexity of your SMS hierarchy. Table 10.1 shows one approach. Be aware that you can customize the order of these steps differently for your environment. This is especially true for larger or more complex environments. For example, you might choose to deploy all your SMS sites before deploying any SMS clients. Or, as you deploy each SMS site, you might deploy SMS clients to that site. Or, you might choose to deploy SMS clients when you have finished connecting the sites in each hierarchy branch. Make these decisions when you plan your deployment and configuration. The plan you design is dependent on many factors. Your pilot project can help you optimize the plan.
Key Elements of a Successful Deployment

An understanding of the key elements of a successful SMS deployment is important as you plan your deployment and configuration. Incorporate these elements into your plan. Practice these recommended strategies during the pilot project and during the actual implementation of SMS. Deploying SMS to the production environment shares many characteristics with deploying SMS during the pilot project. You should use the pilot project to validate the deployment and configuration plan that you create. The pilot project is described at the end of this chapter. The key elements to a successful SMS deployment are listed here.
Communicate to Managers and Administrators Throughout the Deployment

While you are deploying and configuring SMS, inform the project manager and all appropriate personnel at each phase of deployment. Inform network administrators and Active Directory administrators about your site installation schedule and the active network links that will be affected during the installation so that they are prepared for any surges in network activity. Inform your help desk staff in advance of any SMS installations, so that they are prepared for questions or problem reports from end users.
Schedule Major SMS Activities for Nonpeak Hours

Minimize the effect of the deployment by carefully scheduling major SMS activities for nonpeak hours. For example, if your plan includes deploying secondary sites over slow or unreliable links, you should schedule these deployments to occur after critical business hours. Also, if one group of users is in the midst of completing a major project or deadline, consider waiting to deploy SMS to that group until their project is finished.
Inform and Educate Your Users About SMS Before Deploying It

Develop an information and training strategy for users in your organization, and test the strategy on the users in your pilot group. By educating users about SMS functionality, you can alleviate any privacy concerns they might have about running the SMS client on their computers.
Document the Installation Steps

Each administrator who is involved in deploying SMS sites should use procedural documentation as a guideline and checklist. Creating this documentation is part of the planning process. In your deployment and configuration plan, include step-by-step instructions for setting up and configuring the operating system (if necessary), Microsoft SQL Server, SMS 2003, Internet Information Services (IIS), and other necessary components that are outlined in the Getting Started chapter. Test the documented plan in your lab and during the pilot project. Revise the plan as needed when you test it so that you can successfully implement the plan when you deploy SMS in your production environment. Your plan revisions might involve modifying the deployment steps described in the High Level Planning section earlier in this chapter.
Include Risk Management in Each Phase

Be sure you analyze the risks that are introduced at each phase of the pilot project. To avoid risks, you must exercise change control and management. Potential risks are described in Chapter 7, The Pre-Planning Phase. Keep your project plan document updated with identified risks and results at each phase. This information will be valuable to you later, when you implement SMS in your production environment.
Pay Attention to Detail

The simplest logistical details must be planned for any enterprise-wide software deployment. Otherwise, something as seemingly insignificant as a lost key to your server room can cause your deployment to fail. Prepare a checklist of the logistical details of each site deployment, and include items that your administrator must be prepared for, such as: u u u u u u Server room access codes or keys. Emergency contact phone numbers and working communication devices. Problem escalation plan. Any electrical or other wiring work required in the server room before deployment. Server rack reorganization, if necessary. Location of the SMS installation media.
u u
Required system password information. Log book for recording installation and site configuration information, problems, and results.
Schedule Resources
In the pre-planning phase, the project manager creates a team of SMS administrators with varying roles. Planning your deployment requires scheduling the assigned administrators to perform their roles in the pilot project, site deployment, site configuration, and client deployment. If you do not secure resources early in the project, your SMS deployment will be at risk. Scheduling resources might include arranging for long-distance transportation and accommodations in other regions. Ensure that your support and administrative teams are properly trained and prepared for the deployment. For more information, see Chapter 7, The PrePlanning Phase.
Configure SMS Properly and Document the Effects of Configuration Changes

Ensure that you plan to configure SMS properly so that it does not unnecessarily load the network during deployment. Be especially careful when you configure components, such as Network Discovery and inventory, which could use substantial bandwidth or disk space. For example, do not configure any network-intensive feature for a brief interval on a busy network. Consider the business reasons you have defined for using particular SMS features. For example, if inventory reports are not required to run and be revised on a daily basis, then you do not configure inventory to run on a daily basis. Document the effects of each configuration change in your project plan. For more information, see Chapter 15, Deploying and Configuring SMS Sites.
Important
Enable SMS features in a controlled manner. Avoid enabling multiple features simultaneously, which can cause unexpected network bandwidth consumption and result in a loss of productivity in your organization.
Test Your Design and Implementation in a Test Lab and Pilot Project
As you plan your deployment, it is important that you test configuration variations and deployment scenarios in your test lab environment on an isolated network in your organization. Not testing can result in undesirable results in your production environment at deployment time. 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. Because site codes and server names are registered in Windows Internet Name Service (WINS), be sure to reserve special names to use in your test lab. Do not use these again in your production environment. Ensure that your test lab closely replicates your proposed production environment. For information about setting up a representative test lab, see Chapter 7, The Pre-Planning Phase.
Later, conduct a pilot project to deploy SMS to a small fraction of your production environment, and then monitor the results. The pilot project verifies that your SMS design is valid, and that the testing of that design is valid. For more information, see the section entitled The Pilot Project, later in this chapter.
Create and Document a Backup and Recovery Plan

Incorporate backup and recovery preparation into your SMS deployment plan. A solid backup plan enables you to recover more quickly and easily if you encounter any problems during the deployment. Test these plans in your test lab and pilot project. For more information, see Chapter 13, Planning for Backup and Recovery.
Sample Plan
This section includes a basic, sample deployment plan for a particular scenario. Although the scenario is fictitious, it is designed to give the reader an idea of how to document the plan at a high level. The rest of this chapter describes in detail the decisions you must make when devising your plan. This sample deployment plan is primarily designed to show you how to create a high level plan for deploying and configuring SMS. It is not designed to replace your customized plan. This sample deployment plan is for a large organization called Contoso Pharmaceuticals that has 20,000 newly installed client computers in one central location. All of these clients are in one Active Directory site. Contosos Active Directory infrastructure uses only one Active Directory forest. Contoso has three other locations in different geographic regions. Each location is in its own Active Directory site and is connected to the central locations network by a 1.5 Mbps T1 link. Contosos IT department is divided into two administrative areas. One IT group is responsible for supporting computers at headquarters, and the other supports computers at the remote offices. The company is planning for significant future growth, both at its headquarters and in remote locations. Based on this divided management scope, the decision is made to create one administrative SMS site that directly manages all the desktop computers at headquarters, and another SMS site that manages the computers at all remote branch offices. After thorough planning, Contosos IT department might create and document a high level SMS site and client deployment plan like the one shown in the following worksheet. Central headquarters has three primary sites: one for the secondary sites to report to, another to assign local Advanced Clients to, and one to be the central site for reporting. The clients at the secondary sites are required to run the Legacy Client. Contosos IT department creates a document similar to this:
Figure 10.1 Sample high-level SMS 2003 deployment and configuration plan
Central Site C01
Primary Site A01
Primary Site B01
Management point Distribution point Secondary Site A02 Secondary Site A03 Secondary Site A04
High Level SMS Deployment and Configuration Plan at Contoso Pharmaceuticals

1. Install an SMS primary site server at headquarters. Use site code A01. Use this site for administrative purposes only, like reporting and gathering status. Perform the following tasks at site A01:
____ Remove existing SMS site boundaries to prevent client installations. ____ Configure SMS object permissions. ____ Configure maintenance tasks, alerts, and status system. ____ Lock down and configure Internet Information Services (IIS) for SMS reporting. ____ Set up the reporting point. 2. Using the SMS Administrator console at primary site A01, install secondary sites at each of the three remote offices. Use site codes A02, A03, and A04. Perform the following tasks as each secondary site is installed:
____ Configure SMS object permissions. ____ Configure maintenance tasks, alerts, and status system. ____ Configure site communications (senders and addresses). ____ Add a CAP and a distribution point to each secondary site server. ____ Configure the secondary site with site boundaries. ____ Configure a discovery method at the secondary site. ____ Use Client Push Installation to install the SMS Legacy Client on each computer assigned to a secondary site. 3. Install another SMS primary site server at headquarters. Use site code B01. Perform the same tasks listed in step 1. Then perform the following tasks at this primary site:
____ Add a management point and distribution points to the site. ____ Configure SMS site boundaries. ____ Enable Active Directory System Discovery but not SMS client installation. 4. Install another SMS primary site server at headquarters. Use site code C01. This will become the central site. Then:
____ Perform the same tasks listed in step 1. ____ Install a server locator point at site C01. 5. Complete the hierarchy: ____ Configure site communications (senders and addresses) as needed. ____ Attach sites A01 and B01 each to their parent central site CO1. ____ Create queries in site B01 to divide your clients up into collections. ____ Use the Client Push Installation Wizard to install the Advanced Client one collection at a time in site B01.
The final project deployment plan that Contoso creates is much more detailed than the high level plan displayed in this worksheet. The final project plan includes all the details created in the project plans for hierarchy design, security strategy, backup and recovery, site and client deployment, and configuration.
Site Deployment Planning 333
After Contoso administrators have deployed the SMS hierarchy, they enable SMS features, one at a time, at each SMS site. As they enable each feature, they monitor it and test it before enabling another feature. Contoso is careful to verify the integrity of the SMS hierarchy at each step, even as they are testing their deployment plan in the test lab and pilot project. For example, the site systems for the planned hierarchy are put in place, and the integrity of the SMS hierarchy is confirmed before any site boundaries are configured or clients installed. For other deployment scenarios, see Chapter 1, Scenarios and Procedures for Deploying SMS 2003, in the Microsoft Systems Management Server 2003 Operations Guide.
Site Deployment Planning

After designing your hierarchy and testing the design, you should plan and carefully document how you will deploy SMS. Some of your deployment decisions depend on the SMS features that you plan to use and how you plan to use them. Chapter 7, The Pre-Planning Phase, contains guidelines on analyzing and documenting your environment and your requirements. You must take this information into account when you create a deployment and configuration plan. This chapter does not include information about configuring SMS features. SMS feature configuration is described in the Microsoft Systems Management Server 2003 Operations Guide.
Caution
Use your test lab to verify and modify the plan. Then, finalize the plan during the pilot project. Do not merely insert the SMS 2003 product CD and run Setup.exe without planning your deployment. This is extremely risky and is not recommended. Installing SMS in your production environment without planning can cause unexpected network activity resulting in reduced productivity.
SMS site deployment should be done using a phased approach. In creating your plan for deployment, there are a number of things to consider, and many decisions to make. Be sure to consider the following items in your deployment plan: u u u u u u u u u Hardware and licensing Active Directory SMS site server deployment SMS site database server SMS Administrator console and related tools Setup options Domain and security requirements NetBIOS requirements Site naming
Hardware and Licensing Requirements

Determine the number of SMS site licenses and SQL Server licenses you must have to deploy your SMS hierarchy. Your exact SMS hardware requirements are dependent on numerous factors that are derived from your computing and network environment, and from how you will use SMS features. Use the information in Chapter 9, Capacity Planning for SMS Component Servers, with your pilot project results to determine server sizing. Also, review the basic hardware recommendations in the Getting Started chapter. You should adjust your hardware requirements as needed during the pilot project. Your deployment plan should include the following tasks: u u u Checking the hardware compatibility list Obtaining SMS site licensing and SQL Server licensing Determining how to allocate hardware
Checking the hardware compatibility list

Before you install Microsoft Windows Server 2003 or Microsoft Windows 2000 family products on a computer, check the Microsoft hardware compatibility list (HCL) to determine whether the computer is certified by Microsoft as being compliant with Windows 2000 or Windows Server 2003, and that the computer hardware is listed in the HCL. You can access the HCL at http://www.microsoft.com/hwdq/hcl. SMS runs successfully on a variety of host systems. There are no SMS-specific reasons to run SMS on hardware certified by Microsoft. However, if you do require the assistance of Microsoft Product Support Services, they might require that your hardware be certified by Microsoft before they can assist in resolving any issues you have.
Obtaining SMS site licensing and SQL Server licensing

Carefully plan to purchase the correct number of SMS site licenses and SQL Server licenses that you estimate needing before deploying SMS. For licensing requirements, see the Getting Started chapter.
Determining how to allocate hardware

Consider the logistical aspects of deploying your SMS site server hardware at locations that do not have existing server hardware in place. Determine who will do the server installations and how to ship the computers to remote locations. You might decide to install SMS on the servers before shipping the servers to their locations. Or, you might choose to ship the servers to their production location and then install SMS on them.
Three possible staging methods for server installations are described in the following sidebar.
Three Possible Server Staging Methods

1. Perform the SMS installation at a central location for all primary and secondary site servers, and then ship the preinstalled servers out to each site. At primary site locations, the local SMS administrator physically installs the primary site server computer. At secondary sites, a local user physically installs the secondary site server computer, according to instructions accompanying the computer. 2. Perform the SMS software installation centrally for all primary site servers, but do not install SMS on the secondary site servers. Install and configure the operating system on the secondary site servers and ship those computers to each site. A local user at the secondary site installs the secondary site server computer equipment. The SMS administrator installs SMS from the SMS Administrator console at the central location. Or, if network bandwidth is limited, the administrator uses another method to install the remote secondary site. 3. Perform the installation of each primary and secondary site server computer and SMS software on location. This is done by an SMS administrator who travels to the location.
Active Directory Considerations

To take advantage of the simplified administration and many of the new features in SMS 2003, migrate to Active Directory. Active Directory migration can be performed before or after your SMS deployment. Important considerations are: u u u u u Active Directory schema extensions for SMS. Active Directory environment preparation. Managing Active Directory replication. Domain controller issues. Active Directory forest considerations.
Active Directory Schema extensions for SMS

In planning your SMS 2003 deployment, an important decision for organizations using Active Directory is whether or not to extend the Active Directory schema for SMS. In Windows 2000 domains, you cannot remove the SMS schema extensions after you have extended the schema. If you choose to extend the Active Directory schema, you must decide whether to do it before, during, or after setup. Determine who the Active Directory administrator is and what permissions are needed to perform the schema extension. For more information, see the Setup Options section later in this chapter.
Active Directory environment preparation

Carefully consider your Active Directory site configuration before you define SMS site boundaries. If the SMS site server is in an Active Directory domain, then you must ensure that the Active Directory administrator has configured the IP subnets for the forest and that the chosen Active Directory site configuration is relatively stable. Do not set up Active Directory site boundaries in SMS if the Active Directory site configuration is only temporary, except during the pilot project.
Managing Active Directory replication

To understand Active Directory replication issues when you are deploying SMS Legacy Clients, you must have an understanding of both Active Directory account replication and SMS client account activity. Determine whether the interaction of Active Directory replication and SMS might be an issue in your organization. It is important that Active Directory replication is monitored during your SMS deployment. Due to the creation and modification of domain accounts during SMS Legacy Client deployment to domain controllers, an SMS client deployment in a large, highly dispersed network with slow network links generates a lot of updates to the Group Security Policy file. Many copies of the Group Security Policy file are replicated to domain controllers. On a domain controller, this file could reach a size of several hundred kilobytes. This can cause severe backlogging and disruption of File Replication Service and a detrimental effect on domain controller activity. It can also generate many Windows security log messages. Be sure to monitor Active Directory replication in your test lab and during the pilot project. Consult with your Active Directory administrator to ensure that Active Directory replication is optimized. For more information about SMS accounts and file replication, see Chapter 5, Understanding SMS Security, and Chapter 17, Discovering Resources and Deploying Clients. For more information about Active Directory replication, see Chapter 6, Active Directory Replication, in the Microsoft Windows 2000 Distributed Systems Guide in the Microsoft Windows 2000 Resource Kit.
Domain controller issues

Carefully consider your Active Directory deployment. If you are planning to upgrade your domain controllers to an operating system in the Windows 2000 Server family or in the Windows Server 2003 family, be aware of the best practices and potential issues that are described in this section.
Important
As a best practice, when you are upgrading a Microsoft Windows NT 4.0 operating system, upgrade the primary domain controller (PDC) to Windows 2000 or the Windows Server 2003 family before upgrading any other domain controller computer in the domain. The first domain controller computer in the domain that you upgrade adopts the role of the PDC. For example, if the first computer that you upgrade from Windows NT 4.0 is a backup domain controller (BDC), that computer automatically becomes PDC emulator for the domain.
Consider, for example, a scenario in which you plan to implement an SMS 2003 site at each of your organizations remote branch offices. Each branch office has a Windows NT 4.0 BDC connected over a slow WAN link. You plan to install SMS 2003 on each branch office BDC. SMS requires that you first upgrade these BDCs to an operating system in the Windows 2000 or Windows Server 2003 family. However, when you upgrade the BDCs at your branch offices, the first BDC you upgrade automatically becomes the PDC emulator. If you allow this to happen, all of the Active Directory replication traffic is sent to and from this branch office, over the slow network link, creating bottlenecks on your network. When you plan your deployment, consider the following alternatives if you must install an SMS 2003 site on a domain controller: u u Upgrade your PDC to Windows 2000 or the Windows Server 2003 family before you upgrade any SMS site servers that are domain controllers. Properly plan and deploy Active Directory throughout the organization before you deploy SMS 2003. This is a significant task that should be performed by the Active Directory administrator. This alternative could delay your SMS 2003 implementation. Instead of deploying SMS to your branch office BDCs, install SMS on stand-alone servers that are running Windows 2000 or Windows Server 2003 family operating systems. This alternative might require you to acquire new hardware, which could be expensive.
Replace the Windows NT 4.0 BDCs at your remote locations with stand-alone servers that are running Windows 2000 or Windows Server 2003 family operating systems, and let all the authentication traffic flow over the WAN to the nearest domain controller. If this scenario is not feasible for your organization, a recommended best practice is to set up a newly upgraded domain controller at a location close to the domain controller that is acting as PDC emulator, and then ship the new domain controller to the remote office after domain controller replication is completed. Or, create a domain controller on a portable computer that is running Windows 2000, and connect it to the network at the remote office. Then, to avoid the initial replication traffic, upgrade the older Windows NT 4.0 BDC to Windows 2000 Server or Windows Server 2003 family. Afterward, you can decommission the portable computer.
Active Directory forest considerations

When you are deploying SMS sites in an Active Directory environment, be aware of limitations across forests, described in the Active Directory Considerations section in Chapter 8, Designing Your SMS Sites and Hierarchy.
SMS Site Server Deployment Considerations

You should plan the sequence in which you deploy and connect your SMS site servers. You build the SMS hierarchy by attaching sites to other sites. You attach sites by specifying parent sites for each site, except for the central site. Typically, you install the primary sites first, configure them for security, maintenance tasks, and status alerts, and then set up communications between them. After you install and configure the senders and addresses between sites, install secondary sites. You cannot install a secondary site until you install its parent primary site. By using the guidelines here, create and document a plan for deploying your sites. For more information about SMS site concepts, see Chapter 2, Understanding SMS Sites.
Caution
If you are using the Windows Cluster service, do not install the site server or any SMS site system on the shared disk (cluster disk) of a Windows server cluster. For more information about SMS interoperability with the Windows Cluster service, download the Microsoft Windows 2000 Server Clustering Interoperability with SMS white paper from http://www.microsoft.com/smserver/techinfo.
Deploying Central and Administrative Sites

The first SMS site you deploy is a primary site. It is not required that this site be your central site, although you can choose for it to be the central site. Large organizations that do not use their central site for administrative purposes might use the first primary site that is installed as an administrative site and later attach it to the central site. Often, a central site does not directly manage any clients (no SMS clients are assigned to the central site). Instead, the central site acts only as an administrative site the central repository of information and administration, such as SMS reporting and remote tools.
Figure 10.2 shows a sample central and administrative site deployment plan, indicating only the order in which the SMS administrator plans to deploy the sites in the SMS hierarchy. Client deployment and site configuration is not included in this basic plan. 1. Set up and configure primary site A00 as the administrative site for the hierarchy. It is used for reporting, help desk functions (such as remote control), and other administrative purposes. No clients will be assigned to this site. Install and configure a secondary site reporting to primary site A00. Install and configure another secondary site reporting to primary site A00. Install a fourth SMS site as a primary site with no clients reporting to it. Then, configure this site as a parent to primary site A00. It becomes the central site in the hierarchy, and all data propagates up to it. To reduce the load on the central site server, primary site A00 remains an administrative site for SMS software distribution. Install primary site B00 and configure it to use the central site as its parent. Both Advanced Clients and Legacy Clients will be assigned to this site. Attach a secondary site to primary site B00. Legacy Clients will be assigned to this site. Figure 10.2 Sample site deployment plan
Central Site C00
2. 3. 4.
5. 6.
Primary Site A00
Primary Site B00
Secondary Site
Secondary Site
Secondary Site
Configuring Primary Sites with Clients

After you install an SMS site, you use the SMS Administrator console to configure the site boundaries and other site settings. For planning information about these tasks, see the Site Configuration Planning section later in this chapter. In general, plan to perform post-installation tasks in the following order: 1. 2. 3. 4. 5. 6. 7. 8. 9. Configure SMS object permissions. Configure tasks, alerts, and status system. Configure site boundaries and roaming boundaries. Prepare site system computers. Assign site system roles. Configure site communications. Attach SMS sites. Enable resource discovery and client installation methods. Enable SMS features one at a time.
If you attach sites that have existing hardware or software inventories, a burst of network traffic occurs as the inventory data is sent up the hierarchy. Remember this when you deploy your sites, so the extra traffic has as little effect on business functions as possible.
Deploying Secondary Sites

Before you install a secondary site, you must install a parent primary site. By default, the SMS Administrator console is not installed on a secondary site server. You can install the SMS Administrator console on the secondary site server or at a workstation that can connect to the parent primary site if you must distribute duties among administrators. You can set object permissions in the remote SMS Administrator console to limit access to only secondary site clients. There are several different methods of installing a secondary site. The method you choose is dependent on the resources that are available to you at the location of the secondary site, available network bandwidth, and administrative privileges configured at your SMS site. For each secondary site in your hierarchy, plan to use one of these methods: u u u Use the SMS 2003 product CD. Connect to an image of the SMS 2003 CD on a mapped network drive, hard disk, or a removable disk of the secondary site. Use the SMS Administrator console at the primary site.
You can install the secondary site from the primary site server by having SMS transfer all required files from the primary site to the secondary site server during the installation process. Alternatively, you can reduce network traffic during the installation by inserting the SMS 2003 CD on the secondary site server and having SMS install the files from the CD.
SMS Site Database Server Considerations

Using the guidelines here, create and document a plan for deploying your site systems. While you are designing your SMS hierarchy, you decide whether to implement your SMS site database on your SMS site server, or on another computer. Either way, SQL Server must be installed before you run SMS Setup. If you are using an older version of SQL Server and plan to upgrade to SMS 2003, see Chapter 14, Upgrading to SMS 2003. Typically, performance is better if the SMS site server and the SMS site database are installed on the same computer. For more information, see Chapter 8, Designing Your SMS Sites and Hierarchy. If your organization requires you to install SQL Server on a remote computer, analyze the intervening network connection to ensure that a high-availability, high-bandwidth network connection is in place. In this scenario, you might consider installing a second network adapter in both the site server and the computer running SQL Server and then dedicating this second card for communications between the site server and the computer running SQL Server. For more information, see Chapter 9, Capacity Planning for SMS Component Servers.
Important
When you create the SMS site database, ensure that you use the default SQL Server 2000 Sort Order option with the Collation Designator. SMS supports case-sensitive sort orders only. For more information about specifying SQL Server 2000 collations when you create a database, see your SQL Server documentation.
Preparing the SQL Server Computer

Although multiple SMS sites can share a SQL Server database for storing data, it is recommended that you do not share SQL Server databases among SMS sites. For more information, see Chapter 8, Designing Your SMS Sites and Hierarchy. One consideration for your SMS 2003 implementation is which version of SQL Server to use for your SMS site database. Check the requirements in the Getting Started chapter in this book before you make this decision. As with all other site systems, ensure that the computer running SQL Server has sufficient memory, CPU capacity, and disk I/O capacity to manage the SMS and SQL Server processes.
Planning for SQL Server Database Replication

If your plans include implementing SQL Server database replication to improve performance on the SMS site database server, ensure that you plan to deploy a server that is running SQL Server to host the replicated tables. Plan to install SQL Server on this server. Configure your server locator point or management points or both to connect to the replicated SQL Server computer instead of the SMS site database server. SQL Server provides a tool for configuring replication. See the Getting Started chapter to find out which version of SQL Server is required for replication support in SMS. See your SQL Server documentation for SQL Server version considerations when you replicate SQL Server databases. For information about configuring SQL Server database replication, see Chapter 15, Deploying and Configuring SMS Sites, and your SQL Server documentation.
SMS Administrator Console and Related Tools

Plan how you will implement the SMS Administrator console to administer your SMS sites and how you will implement the Recovery Expert to back up and recover your SMS sites.

SMS Setup automatically installs the SMS Administrator console when you are installing a primary site. You can also install the SMS Administrator console on any computer in your site that is running a Windows operating system. This operating system must be on the list of supported operating systems in the Getting Started chapter. Consider who will be using the SMS Administrator console and what level of access to give to each SMS user. Anyone with permissions for SMS Administrator console items for a site can use the console to connect to an SMS site database and administer those items.
Backup and Recovery

Planning for backup and recovery is a crucial part of planning your SMS deployment. Do not wait until you have deployed SMS to implement your backup and recovery plan. At this stage in planning, it is important that the appropriate members of your SMS team are educated in the SMS backup task, the Recovery Expert tool, and other recovery tools that are included in SMS 2003. Be sure to plan for a Recovery Expert Web site, document your backup and recovery plan, and keep the plan in a secure location. The documentation and backup data must be available to the appropriate personnel if the system fails. For more information, see Chapter 13, Planning for Backup and Recovery.
Setup Options
To run SMS Setup, you must have administrative credentials on the computer. Before you run Setup, plan for making the following choices during setup: u u Express vs. Custom setup Advanced vs. Standard security mode
Extending the Active Directory schema for SMS
Important
Before you install SMS, ensure that the time settings on computers in your organization are synchronized, and then perform network time synchronization routinely. A number of problems can arise in your SMS hierarchy if time is not synchronized, such as a backlog of status messages and software metering summarizations that are not valid, to name just two issues.
Express vs. Custom Setup

Carefully choose one of the two options for installing a primary site: Express Setup or Custom Setup. Many SMS 2003 features are enabled by default if you use Express Setup, but they are disabled by default if you use Custom Setup. Always use Custom Setup to deploy SMS in your production environment. Express Setup is only appropriate for setting up evaluation sites on an isolated network. Custom Setup allows you to control which features Setup installs, and it is required for Advanced Security. Table 10.2 describes which SMS components are available with each setup option. Table 10.2 Component Data by Setup Option
SMS Administrator console installation Not available Installed Not available Not available
Option Site server
Custom primary site installation Installed
Express primary site installation Installed Installed Installed Installed
Secondary site installation Installed Available Optional Not available
SMS Administrator Installed console Remote Tools Optional
Package Optional automation scripts
By default, the Express Setup option: u u u u u Installs all core SMS components and client agents. Enables Legacy Client Push Installation. Enables all discovery methods. Creates all necessary service accounts. Enables the client access point (CAP), management point, and distribution point roles on the site server.
Table 10.3 lists default settings that result from the Express Setup option. Table 10.3 Express Setup Default Settings
Feature Network Discovery Windows User Group Discovery Windows Networking User Account Discovery Heartbeat Discovery Active Directory System Discovery Active Directory User Discovery Active Directory System Group Discovery Legacy Client Push Installation Advertised Programs Client Agent Remote Tools Client Agent Hardware Inventory Client Agent Status summarizers (summarize and replicate) Collection update Software Metering Client Agent Software Inventory Client Agent Enabled or disabled Disabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Disabled Disabled Interval Not applicable One day One day One week One day One day One day Not applicable One hour Not applicable One week One hour One day Not applicable Not applicable
Advanced vs. Standard Security Mode

It is important that you plan to choose which security mode, standard or advanced, to implement when you install SMS. The security mode you choose has an effect on the kind and number of accounts that are created and used for SMS security.
Important
If you choose advanced security mode, then you can never change the mode to standard security.
Advanced security mode has some prerequisites that you should plan for. For example, advanced security mode requires that Active Directory be enabled. These prerequisites are described in Chapter 12, Planning Your SMS Security Strategy.
The supported parent-child configurations for advanced security mode are: u u u SMS 2003 advanced security site reporting to SMS 2003 advanced security site. SMS 2003 standard security site reporting to SMS 2003 advanced security site. SMS 2.0 site reporting to SMS 2003 advanced security site.
If you choose the standard security mode during setup, you can switch to advanced security mode after installation.
Extending the Active Directory Schema for SMS

You extend the Active Directory schema to publish SMS objects in Active Directory. If you do not extend the schema, SMS cannot publish objects, and the following features are not available for Advanced Clients in SMS: u u Global roaming Automatic site assignment where the server locator point is not specified
Although SMS 2003 Setup prompts you to extend the schema, you can extend schema before, during, or after you run Setup.
Note
If you do not extend the Active Directory schema for SMS, your server locator point and management points are not published to Active Directory, and you must manually register the server locator point (and any management points that are operating in a Network Load Balancing cluster) in WINS.
If you choose to extend the Active Directory schema during setup, be aware that you perform this task only once per Active Directory forest, and the logged-on user who is running SMS Setup must have administrative credentials. For information about using ExtADSch.exe to extend the SMS schema before or after running SMS Setup, see Chapter 15, Deploying and Configuring SMS Sites.
Important
Before enabling any Active Directory Schema changes in a Windows 2000 domain, the option to allow the schema to be extended has to be enabled. This does not apply to the Windows Server 2003 domains. For more information about the Active Directory schema, see the Microsoft Windows 2000 Distributed Systems Guide in the Microsoft Windows 2000 Server Resource Kit. Also see Microsoft Knowledge Base article 216060, Registry Modification Required to Allow Write Operations to Schema, at http://support.microsoft.com/?kbid=216060.
Domain and Security Requirements

Computers must belong to a domain to become SMS 2003 clients. Client computers that are in workgroups are not supported by SMS.
Planning your SMS deployment includes a number of security considerations. Your SMS security strategy affects all of the following: u u u u u u Operating system configuration Support for software that works with SMS, such as IIS, SQL Server and Windows Management Instrumentation (WMI) Logical and physical placement of site systems Creation of user and computer accounts Communications to appropriate departments in the organization Policies and procedures for use of SMS
For more information, see Chapter 12, Planning Your SMS Security Strategy.
NetBIOS Requirements
This section describes NetBIOS requirements for browsing and WINS in SMS 2003. The Windows Computer Network Browser service (browsing) is required if any one of the following is true: u u u u u u SMS is running in standard security mode. Some SMS clients are running the Legacy Client. SMS is running in standard security mode. Some SMS clients are running the Legacy Client. The Active Directory schema has not been extended for SMS. Your SMS hierarchy is distributed across different Active Directory forests.
SMS 2003 requires WINS if any one of the following is true:
Also, if any SMS sites in your hierarchy span more than one Active Directory domain, you must configure the DNS-suffix search order of client systems to include the DNS suffixes of all domains with SMS clients or servers. This is configured in Windows Dynamic Host Configuration Protocol (DHCP) service. For information, see your Windows documentation. If Active Directory is not enabled, or if the Active Directory schema is not extended for the site, you must enable WINS. SMS management points and SMS server locator points require registration in the WINS database. Although stand-alone management points are automatically registered in WINS, you must manually register the following types of site systems in WINS: u u u u Server locator point Management point in a Network Load Balancing cluster Active Directory is implemented in your environment. The Active Directory schema is extended for SMS.
You can disable browsing and WINS if all of the following are true:
Site Configuration Planning 347
u u u u u
All SMS clients are running the Advanced Client. You have no secondary sites in Windows NT 4.0 domains. You have no secondary sites in a forest that is different from the forest of their parent site. You have no SMS 2.0 child sites. SMS is running in Advanced Security mode.
Site Naming
As described in Chapter 8, Designing Your SMS Sites and Hierarchy, 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. Remember the following: u u u u u u u SMS site codes cannot be changed after they are created. It is important to be consistent with your IT organizations existing naming conventions. Do not use the same site code name for more than one site in your enterprise. Avoid the use of extended characters in site code names. If you are using Active Directory, your Active Directory site names must use only valid characters, as described in Active Directory documentation. Do not use MS-DOS directory names that are not valid, such as AUX, PRN, NUL, or CON, for your SMS site codes. Symbols are not accepted in the database name during setup.
Site Configuration Planning

After you install SMS 2003, and before you deploy SMS client software, you must configure the new site. It is important to perform site configuration in a controlled manner. The information that you gather during planning, guides the settings that you enable when you configure individual SMS sites and build your SMS hierarchy. You begin the site configuration process by defining site characteristics and configuring site system roles at a single site. When you configure individual sites, you can build an SMS hierarchy by establishing intersite communications and attaching sites to form the site-reporting structure you designed earlier in the planning phase. Or, you can configure all of your sites and then build your hierarchy. This section, which helps you plan the configuration of your sites and hierarchy up to the point of installing clients, includes planning guidelines for configuring your SMS site servers, site systems, and senders. For configuration information that is relevant to each specific SMS feature, see the Microsoft Systems Management Server 2003 Operations Guide.
Modify your site-deployment plan document based on the configuration planning guidelines in this section. In addition to configuration details, include a copy of your hierarchy design in your document. Use this diagram to pinpoint the locations of site system roles, the discovery and installation methods used in each site, and the types of communication methods used between sites. If you have a large organization, consider how you can categorize your plans. For example, you might have one plan that you use to deploy and configure a group of sites, if you expect to have identical configurations in each. You might also have a plan that encompasses all of your secondary site deployments. This chapter includes the following two planning topics: u u Configuring an SMS Site Configuring an SMS Hierarchy
Configuring an SMS Site

Planning to configure a single SMS site involves planning for security rights, scheduling maintenance tasks, and assigning site system roles. Plan to configure your SMS site before you enable any discovery or client installation methods. This section describes how to plan for: u u u u u Configuring site security. Configuring tasks, alerts, and status system. Configuring site boundaries and roaming boundaries. Preparing site system computers. Assigning site system roles.
Configuring Site Security

After you install SMS 2003, use the SMS Administrator console to configure security for the new SMS site. This configuring prevents users from making unauthorized changes to the SMS system. After you configure security, you can set up alerts and maintenance tasks, configure the boundaries of the site, and assign the site systems that help run SMS on the site. Create your site security configuration plan by using the guidelines in Chapter 12, Planning your SMS Security Strategy.
Configuring Tasks, Alerts, and Status System

In your deployment and configuration plan, include information about how to configure the following items for monitoring and maintaining your SMS site.
Configuring the SMS status system

Plan to configure the three status summarizers with threshold periods, and choose a threshold period that is appropriate for how often you plan to check the status summarizer. u u u Advertisement Status Summarizer Component Status Summarizer Site System Status Summarizer
For more information, see Part 2 in the Microsoft Systems Management Server 2003 Operations Guide.
Scheduling SMS site database maintenance tasks

Plan to configure the site maintenance tasks in the SMS Administrator console. These tasks are critical to properly maintaining a site. They enable you to schedule key database activities such as backups and data deletion. Determine how you can schedule these tasks to maintain an appropriate database size, and be prepared to recover a site if a site fails. Plan to properly back up the SMS site server so that you can restore it if the site server or SMS site database server fails. You can automate site backups by enabling and configuring the integrated Backup SMS Site Server task. This is not enabled by default in your site settings. It is important that you become familiar with Chapter 13, Planning for Backup and Recovery, before you implement SMS in your production environment. You should also schedule regular maintenance tasks for SMS administrators to perform, such as: u u u u Reviewing site status messages and reports. Checking for unprocessed inventory files. Checking the size of database devices and logs. Verifying that site systems have ample disk space (this is done by default by the Backup SMS Site Server task and is tracked by the Site System Status Summarizer).
Configuring logging
To assist in troubleshooting problems within your SMS site, plan to enable logging. Use the SMS Service Manager tool in the SMS Administrator console to enable logging. You can specify which components are logged and set the log file size. For more information, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide.
Configuring Windows Event Viewer, System Monitor, and Performance Logs and Alerts
In evaluating system performance, setting up a monitoring configuration is the first step. By using Event Viewer and event logs, you can gather information about hardware, software, and system problems, and you can monitor Windows security events. With System Monitor, you can measure the performance of your SMS site server. With Performance Logs and Alerts you can collect performance data automatically from local or remote computers. You can view logged counter data by using System Monitor, or you can export the data to spreadsheet programs or databases for analysis and report generation.
Plan to configure your Windows event logs so that they do not fill up rapidly with SMS (or other application) events. For example, you might plan to set each log in the Windows Event Viewer (System, Security, and Application) to Overwrite Events as Needed or to Overwrite Events Older than <user-defined number> Days.
Note
Windows security auditing is a powerful method for monitoring security. Plan to set the appropriate audit policies in Domain Security Policy or Local Security Policy. Auditing failure events is sufficient for most purposes. Enabling success events provides many details on SMS activity, but it also consumes considerable computer resources. With Windows security auditing enabled, you can watch the security event log for events that are related to SMS. For information about configuring Security Policy see your Windows product documentation.
For more information, see Part 2, Maintaining SMS in Your Organization, in the Microsoft Systems Management Server 2003 Operations Guide.
Setting up SQL Server alerts

Determine whether you want to use SQL Server alerts. Plan to configure these in SQL Enterprise Manager on your SMS site database server. Define alerts for events, such as a database or transaction logs running out of disk space, or for fatal errors in database processes. For more information, see your SQL Server product documentation.
Configuring Site Boundaries and Roaming Boundaries

How you configure site boundaries and roaming boundaries affect: u u Whether discovered computers are assigned to SMS sites. How packages are distributed to Advanced Clients.
Remember that SMS clients can be assigned to only one SMS site, and Advanced Clients can only be assigned to primary sites. Avoid configuring site boundaries or roaming boundaries that overlap other boundaries. IP subnets or Active Directory sites should not be contained in more than one SMS site. This ensures that there is no confusion about which site a client is assigned to. You cannot predict the results in SMS if your sites have overlapping site boundaries or roaming boundaries. Using correctly defined subnet boundaries or Active Directory sites ensures that SMS 2003 sites have unique boundaries. However, it is fairly easy to have incorrectly defined subnet boundaries or Active Directory sites. To avoid this problem, watch for the following issues: u Ensure that a subnet is not used to define multiple Active Directory sites. Active Directory does not enforce such uniqueness in all cases. Keep a record of site definitions so that this problem is obvious if it does occur. If a subnet is used to define an Active Directory site, do not use it to also define an SMS site. Instead, define the SMS site by using the Active Directory site.
Check with network administrators to ensure that subnet masks are specific enough to ensure that the resulting subnets are unique. For example, use a subnet mask such as 255.255.255.0 if 255.255.0.0 would create subnets that would include clients at multiple locations. This can be a problem particularly if you use virtual LANs, where sufficiently specific subnets are not needed other than to define SMS and Active Directory sites.
Caution
If a client operating systems codepage is different 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. This can happen if your Active Directory site names contain a double-byte character set (DBCS) string.
Setting site boundaries

Legacy Clients cannot be assigned to an SMS site until you configure site boundaries in the SMS Administrator console. For large organizations, create a plan to add your site boundaries by using a controlled method. For example, if you are using a large number of individual IP subnets as your site boundaries, consider using a phased approach when you are adding site boundaries to an SMS site. Also, remember that the site boundaries of secondary sites automatically become the roaming boundaries of the parent primary site. As a best practice, use Active Directory site names to define site boundaries. For more information about planning guidelines for setting site boundaries, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Setting roaming boundaries

Advanced Clients cannot be assigned to an SMS site until you configure roaming boundaries. To provide Advanced Client access to management points and to software packages on distribution points, configure roaming boundaries in the SMS site. By default, each site boundary is also configured as a roaming boundary. As a best practice, use Active Directory site names for roaming boundaries. If your environment is not Active Directory-enabled, then use IP subnets. In the absence of Active Directory, or if you have the choice of using either IP subnets or IP address ranges to define your roaming boundaries, choose IP subnets. IP address ranges require a slightly longer look-up time and have a slightly greater effect on both SMS client and server performance. If you have dial-up or VPN clients, and if each IP address has a subnet mask of 255.255.255.255, use IP address ranges for roaming boundaries.
As a best practice, specify local roaming boundaries for the well-connected segments of an SMS site (such as over a LAN). Specify remote roaming boundaries for the slow or unreliable network links in your SMS site (such as RAS, a wireless network, or a 56 Kbps dial-up connection).
Note
Because the client is usually connected over a slow or unreliable network link when it is in a remote roaming boundary, you can preserve bandwidth by enabling Background Intelligent Transfer Service (BITS) on the distribution point and configuring the advertisement to download before it runs.
Preparing Site System Computers

Your hierarchy design identifies the site system roles you plan to implement in your SMS site and the locations of those site systems. When you review the placement of site systems, ensure that they are well connected to the site server. For more information, see Chapter 8, Designing Your SMS Sites and Hierarchy. In planning site systems, make sure that the computer you use in a site system role has the required disk space and other resources available. For a list of the basic requirements for site systems, see the Getting Started chapter. Ensure that users, services, and SMS client accounts have the necessary permissions on the server. For example, Legacy Clients must be able to access CAPs and distribution points. Site systems that use IIS require a minimum IIS configuration. When you are planning to deploy management points, server locator points, BITS-enabled distribution points, and reporting points, pay attention to configuring IIS for security. Ensure that only the necessary components and ports are enabled in IIS. For details about configuring IIS for SMS site systems, see Chapter 15, Deploying and Configuring SMS Sites. Site systems that are on a computer running Windows Server 2003 and have other requirements are reporting points, management points, and BITS-enabled distribution points. For more information, see the Special Windows Server 2003 Requirements section later in this chapter.
Caution
If you use the Microsoft IIS Lockdown tool (Iislockd.exe) to increase security protection, be sure to apply it to IIS-enabled SMS site system computers (by using the SMS 2003-specific template) before you enable the computer as an SMS site system. If you use the IIS Lockdown tool after you create the site system, your site IIS-dependent site system will not function properly. For more information about the IIS Lockdown tool, see your IIS documentation.
Be aware of the following prerequisites and other considerations in setting up management points, server locator points, CAPs, reporting points, and distribution points. For information about supported operating systems, see the Getting Started chapter.
Important
Do not install SMS site components on computers or shared folders whose names use DBCS.
Management point
You install management points in primary sites or install them as proxy management points at secondary sites. To be a management point, the computer must have IIS installed and enabled. Management points require access to the SMS site database. A primary site can have only one logical management point (the default management point). Typically, for Advanced Client policy requests and other communications, the Advanced Client uses the default management point of the SMS site to which it is assigned its assigned management point. However, with Network Load Balancing, multiple management points can be implemented in one primary site to meet the capacity needs of your organization. You combine multiple management points of one site into a Network Load Balancing cluster. Management points in a Network Load Balancing cluster do not register automatically with WINS because they share a virtual IP address. In the absence of Active Directory, you must manually register the Network Load Balancing servers virtual IP address in WINS. For more information about using SQL Server database replication with management points, see the Planning for SQL Server Database Replication section earlier in this chapter. For more information about using Network Load Balancing, see the Management points and Windows Network Load Balancing section. Stand-alone management points are automatically registered in the WINS database.
Note
When you enable a server as a management point, the WMI service is stopped and restarted on that server.
Management points and Windows Network Load Balancing

A primary site server can have multiple physical management points. However, it can have only one logical management point the default management point. Advanced Clients communicate only with the default management point. Other management points are unused, unless they are configured using the Windows Network Load Balancing service (also known as Network Load Balancing).
If you expect to have a large number of Advanced Clients in an SMS site, consider using Network Load Balancing to spread client communication activity over several management points. If you anticipate growth in your organization, Network Load Balancing can help you scale management point performance to keep up with the increasing demands of your Advanced Clients.
Note
Do not confuse Windows Network Load Balancing service with Windows Cluster service. Cluster service is one of two complementary Windows clustering technologies. The other clustering technology, Network Load Balancing, complements Cluster service by supporting highly available and scalable clusters for front-end applications and services.
If you have multiple management points in a Network Load Balancing cluster, SMS clients regard them as one unique management point, using one virtual IP address. SMS clients access the management point hosts by using the IP address, which then uses the Network Load Balancing cluster to optimize traffic by distributing client requests across management points. This allows for increased client connections and throughput, and it also allows the management points to be managed by their site server without interfering with client traffic. SMS sites continue to administer the management points as separate nodes. The following Network Load Balancing configurations are supported for SMS 2003 management point clusters: u u Unicast mode with a single network adapter Unicast mode with dual network adapters
Multicast modes are not supported. An important configuration option to consider when you are setting the parameters for Network Load Balancing is how clients choose a preferred host in the cluster. This is called affinity, and there are three affinity options: None, Single, and Class C affinity. SMS 2003 management points in a Network Load Balancing cluster are only supported if the affinity is set to Single or None. The default setting for affinity is Single.
Windows Network Load Balancing Affinity Settings

Network Load Balancing provides three affinity options: The None option specifies that Network Load Balancing does not have to direct multiple requests from the same client to the same cluster host (no client affinity). The Single option specifies that Network Load Balancing should direct multiple requests from the same client IP address to the same cluster host. Class C affinity specifies that Network Load Balancing should direct multiple requests from the same TCP/IP Class C address range to the same cluster host. For more information, see your Windows documentation.

The server locator point is installed only in a primary site, not in a secondary site. To be a server locator point, the computer must have IIS installed and enabled. Also, if Active Directory is not enabled, or if the Active Directory schema is not extended for SMS, you must manually register the SMS hierarchys server locator point in WINS for automatic site assignment of Advanced Clients. Plan to deploy a server locator point in your SMS hierarchy to provide any of the following: u u u u Automatic site assignment for the Advanced Client in the absence of Active Directory (in this scenario, you must manually register the server locator point in WINS) Site assignment and locating CAPs for Legacy Clients during Logon Script-initiated Client Installation Locating management points for Advanced Clients during their initial Logon Script-initiated Client Installation Site assignment and locating management points for Advanced Clients that have insufficient rights during their initial Logon Script-initiated Client Installation
Client access point

When you prepare a computer to be a CAP, ensure that at least one NTFS partition is available. SMS does not support CAPs on non-NTFS partitions such as FAT and FAT32. Every SMS site must have at least one CAP. When you install SMS, the site server is automatically configured as a CAP. The SMS administrator can move the CAP to another server if necessary. You can create additional CAPs to distribute the client workload.
Distribution point
If you plan to advertise many packages to the client computers in your SMS site, consider assigning the distribution point role to one or more computers other than the site server, to reduce server load.
Distribution point with BITS enabled

To protect distribution point users from excessive bandwidth consumption during download, plan to enable BITS on distribution points that serve Advanced Clients. This provides an efficient file transfer mechanism through client-sensitive bandwidth throttling. Like server message block, BITS also provides checkpoint restart download of packages, which allows downloads to continue from the point at which they were stopped when a lost connection is re-established, instead of starting the transmission from the beginning.
Distribution point and Windows Cluster Service

SMS supports the creation of a distribution point on a computer that is running Windows 2000 Advanced Server with the Windows Cluster service enabled. This applies only to distribution points that are not BITS-enabled. Distribution points are the only components of an SMS site that support the Windows Cluster service. You can install distribution points on any server node or virtual server in a cluster. This means that you can install a distribution point on a cluster disk. However, the shared folder must be created in advance as a cluster resource on a virtual server.
Distribution points that are installed on a server cluster are either cluster-aware or clusterunaware. A cluster-aware distribution point is available to SMS clients when the shared folders group or node fails. A cluster-unaware distribution point coexists with the cluster, but it does not support failover or otherwise participate in the cluster. For more information, see your Windows Cluster service documentation. If you want a sites distribution point to be protected from use by clients that are outside of a particular site boundary or roaming boundary, configure it to be a protected distribution point.
Reporting point
When you are planning your deployment, consider whether you want to use the reporting feature in SMS. If so, plan how many reporting points you anticipate using, who will be authorized to run SMS reports, and where you will deploy each reporting point. To be a reporting point, the computer must have IIS installed and enabled. For each site, determine whether you want the site server to serve as a reporting point, and whether you want to assign the reporting point role to one or more site systems. In some cases, consider using secured, dedicated computers as SMS reporting points. Also, consider whether you want to install a reporting point at only the central site, or install a reporting point at each SMS site in the hierarchy. This decision depends on how you plan to use SMS reporting. Your pilot project helps you determine the effect of having a reporting point on your SMS site server. Larger organizations might want to set up separate administrative sites that contain a reporting point. Also, consider whether you want to use supplemental reports, or just the predefined reports that are included with SMS. Supplemental reports can provide your organization with more reporting options. If you decide to use supplemental reports, be sure your staff has the appropriate programming skills to create supplemental reports, and that it is appropriately trained to build adequate security into those reports. The predefined reports that are included with SMS have built-in security. Plan to define the criteria for what will be included in supplemental reports. Also consider whether you want to allow users to run real-time reports, or just allow users to view reports that are generated at nonpeak times. Before you can begin using reports in SMS, you must enable one or more of your site systems as a reporting point.
Special Windows Server 2003 Requirements

Management points have a special requirement if they are installed on a computer that is running an operating system in the Windows Server 2003 family. Before you deploy a management point, you must enable IIS and enable BITS as a Windows component on the site system server. If you do not enable BITS in Windows first, enabling a server as a management point fails.
A reporting point also has a special requirement when it is installed on a computer that is running an operating system in the Windows Server 2003 family. Before you deploy the reporting point, you must enable Active Server Pages as a Windows component on the reporting point server. Otherwise, your reporting point will not function properly. For more information, see your Windows Server 2003 documentation.
Important
Upgrading a computer that is running IIS to Windows Server 2003 requires that IIS be locked down by using the IIS Lockdown tool. If you have an SMS reporting point on a computer running a Windows 2000 Server family operating system, and you do not run the IIS Lockdown tool before you upgrade that server to Windows Server 2003, your reporting point will not be operable after the operating system upgrade. To reinstate reporting functionality, you must enable IIS after the upgrade by invoking Internet Information Services (IIS) Manager in Administrative Tools. For more information, see your Windows Server 2003 documentation.
Assigning Site System Roles

You create a site system by specifying the server to be used as the site system and assigning the site system role to it. When you create a site system on a computer that is running an operating system in the Windows 2000 Server or Windows Server 2003 family, SMS installs the appropriate components on the computer, and the new site system begins performing its role in the SMS site.
Note
The process of assigning a site system role to a server is usually referred to as creating the <site system role>. For example, assigning the CAP role to a server is creating the CAP.
The SMS site server is automatically assigned the site server role. Similarly, the computer running SQL Server that contains the SMS site database is automatically assigned the SMS site database server role. By default, SMS assigns CAP and distribution point roles to the site server, but these roles can also be assigned to other computers. You can remove the CAP, distribution point, management point, server locator point, and reporting point role from an SMS site. To reassign a CAP, distribution point, server locator point, or reporting point role to a different site system, remove it from the first site system and assign it to the next. To reassign a management point, enable another computer as a management point, disable the default management point setting from the current management point, and then enable the new management point as the default management point. You cannot reassign the SMS Provider role. For information about modifying and deleting site system roles, see the Creating Site Systems section in Chapter 15, Deploying and Configuring SMS Sites.
Configuring an SMS Hierarchy

Configuring the SMS hierarchy consists of installing primary sites and setting up communication between them. Then you install and configure the senders and addresses between sites. Finally, you build the SMS hierarchy by attaching sites to other sites. Your deployment plan should include setting up the hierarchical structure between the sites in the SMS hierarchy. This reporting structure is based on your hierarchy design and determines how data flows between the sites. Because this data flow can significantly affect the efficiency of your SMS system, plan the hierarchy before you install SMS. Use the guidelines in Chapter 8, Designing Your SMS Sites and Hierarchy. To configure the SMS hierarchy, you perform the following tasks: u u Configure site communications Attach SMS sites
Configuring Site Communications

Plan your site settings so that each SMS site can communicate with its parent site and child sites. This involves installing and configuring senders on each site, and then creating addresses to the other sites that you want the site to communicate with. In your deployment plan, include validating each of the requirements for configuring site communications. For more information, see Chapter 15, Deploying and Configuring SMS Sites.
Choosing Senders
The choice of senders you install depends on the existing connectivity system between your sites. If you have reliable, high-speed network connections between sites, plan to use Standard Sender. If you have RAS connections between sites, select the appropriate type of RAS sender for your connection. If you want to send large amounts of package data for software distribution to sites using physical media instead of over the network, use Courier Sender. SMS sites are created with the following senders installed and configured by default: u u At primary sites, Standard Sender and Courier Sender At secondary sites, Courier Sender and either Standard Sender or Asynchronous RAS Sender
When you create a secondary site, you create an address from the new secondary site to the parent site. You can create either a Standard Sender address or one of the RAS Sender addresses. Depending on which type of address you create, the appropriate sender is installed at the new secondary site. Based on the types of links between SMS sites, choose from the senders in Table 10.4.
Table 10.4 Choosing SMS Senders

Existing connectivity system between sites LAN or WAN
Usage Use Standard Sender, the most commonly used sender, for sending to other sites on the same LAN, or on a WAN using routers, switches, or bridges. Use Asynchronous RAS Sender for RAS communications over an asynchronous line. Use ISDN RAS Sender for RAS communications over an ISDN line. Use X25 RAS Sender for RAS communications over an X.25 line. Use Systems Network Architecture (SNA) RAS Sender in RAS communications over an SNA link. Use Courier Sender to send packages between the sites by using removable media instead of network wiring and protocols if you have a slow or unreliable link between a site and its parent. Courier Sender is used only for package distribution, not site-to-site communications.
Sender type Standard Sender (automatically installed and configured when you set up an SMS site) Asynchronous RAS Sender ISDN RAS Sender X25 RAS Sender RAS over SNA Sender Courier Sender
Asynchronous line ISDN line X.25 line SNA None
Note
If you have physical locations that are not continuously connected to the rest of your network, RAS is usually the most cost-effective way to add a new site to your system. For example, if you have a virtual private network (VPN) server, you can substitute a VPN phone book entry for the Phone book entry in the RAS Sender Address Properties. This works with any of the RAS senders in SMS.
When you set up a primary site, Standard Sender is installed and configured by default. So if your site-to-site communications occur over a LAN that uses a supported protocol, you do not have to install another sender. You can edit Standard Sender settings if you want to change the maximum number of concurrent sendings or the retry settings for the sender. Increasing the maximum number of concurrent sendings can increase the throughput of data between sites, but it can also result in higher demand on network bandwidth. Edit the retry settings to specify the number of times the sender retries a sending if the first attempt fails, and to specify how long it waits between retries.
You can use Courier Sender in software distribution to send package data to other sites by using physical media instead of sending data over the network. When you have large packages that would require excessive time or bandwidth to send them over the network, this sender can be useful. You can use Courier Sender at the source SMS site to create a parcel (a collection of files transferred from one site to another using Courier Sender), write the parcel to a tape, CD, or other physical medium, and then ship the tape or CD to the destination site by mail or a courier service. At the destination site, you can then use Courier Sender to receive the parcel and import the package data into the site. For information about packages and software distribution, see the Microsoft Systems Management Server 2003 Operations Guide. You might want to create some sender connections from the central site to indirectly connected child sites if you have enough network bandwidth, and you want processes to take place quickly. See Figure 10.3 for an example. If you distribute a package from the central site to a secondary site three tiers beneath it in your hierarchy by using the standard connections, it is delivered from the central site to secondary site through sites A and B. Depending on how the direct connection is configured, creating a direct sender from the central site to the indirect secondary site can increase the speed of distribution because the intervening lower level sites are bypassed.
Figure 10.3 With Standard Sender, the package traverses through sites A and B when it is delivered to the secondary site for distribution. By using Courier Sender instead, the package is sent directly to the secondary site.
Central Site
Software package
Courier Sender
Standard Sender
Primary Site A
Primary Site B
Primary Site
Secondary Site
Secondary Site
Preparing Servers for Sender Installation

You can install senders on the site server or on other computers that run an SMS 2003-supported operating system. For the Standard Sender, you want to make sure the server that you install the sender on uses the same LAN protocols as the site servers for the destination sites.
For the RAS Sender, plan to install Microsoft RAS on the source and destination sites, and be prepared to create RAS phone book entries for the RAS servers on each destination site. When you install a sender on a server, the server becomes a site system for the SMS site if it is not already a site system. Make sure you know the name of the computer you plan to install the sender on. For information about installing, configuring, and deleting senders, see Chapter 15, Deploying and Configuring SMS Sites.
Creating and Configuring Addresses

You can create several different types of addresses, each of which corresponds to a different type of sender. Before you can use a particular sender to contact another site, you must create an address to that site for that sender type. For example, to contact another site through Standard Sender, you must create a Standard Sender address to that site. To contact the site through one of the RAS senders, you must create an appropriate RAS Sender address to the site. Before you create an address, make sure you know the site code of the SMS site that the address will connect to, the name of the site server for that site, and the type of sender you want to use for that site. To control network load, you can schedule when SMS can use an address and the amount of network bandwidth that SMS can use when it sends to the address. Also, to provide increased throughput or to act as a backup if some addresses are unavailable, you can define multiple addresses to each destination site. If you define more than one address to a site, you can specify the priority for SMS to attempt to use the addresses for that site. The details pane of the SMS Administrator console lists multiple addresses to a destination site in priority order. For information about creating and configuring addresses, see Chapter 15, Deploying and Configuring SMS Sites.
Attaching SMS Sites

You attach SMS sites to create a hierarchical structure in SMS. Plan the order in which you will attach sites, thereby creating data flow between sites in a hierarchy branch. If a primary site contains a large amount of client data, for example, and you attach the site to another site, be aware that such client data propagates up the hierarchy to the primary parent site. Be sure to plan for this, and configure the appropriate address schedule and rate limits based on the amount and type of data you expect to flow up to the parent primary site. For information about designing an SMS hierarchy that meets your business and technical objectives, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Client Deployment Planning 363
Client Deployment Planning

SMS client deployment consists of the following phases: u u u u Discovering resources Installing core SMS software components on potential clients Assigning clients to SMS sites Installing client agents (on the Legacy Client only)
Be familiar with the SMS discovery and installation methods that are described in Chapter 4, Understanding SMS Clients. This section includes: u u Determining Which Client Type to Deploy Developing Strategies for Discovery and Client Installation
Determining Which Client Type to Deploy

For each site in your hierarchy, you should carefully consider which SMS 2003 client to deploy. In general, plan to deploy the Advanced Client at each SMS site, especially on computers with slow or inconsistent connections to SMS site systems. The Advanced Client is easier to administer and is the future direction of the SMS client. It is strongly recommended that you install the Advanced Client as the preferred client on all your SMS client computers running Windows 2000 or later, to take advantage of the enhanced security and other benefits the Advanced Client provides on these platforms. There is an exception to this recommendation. Deploy the Legacy Client to computers that are running Windows 98 or Windows NT 4.0. See the Getting Started chapter for client system requirements. To assist you in determining which client to deploy, you should closely examine the differences between the two clients. Although the two clients are almost identical in features, they have subtle differences, which are described in Chapter 4, Understanding SMS Clients. For information about how SMS 2003 features are implemented on each client, see Chapter 3, Understanding SMS Features. Other considerations when choosing which client to deploy are: u u Your state of readiness for deploying and supporting two different clients in SMS, and whether it is important that you standardize to just one type of client. Your organizations need for mobile computer support. The need to have and support clients roaming from one SMS site to another can hasten your transition to the Advanced Client.
The state of your SMS client deployment readiness. If you have a reference image of client systems or a similar computer operating system deployment mechanism, plan to update the reference image to include the Advanced Client. Similarly, if you are deploying system images from Windows shared folders at various sites, then plan to update those shared folders with the appropriate SMS client software. Whether or not your Advanced Client requirements are met. You can transition to the Advanced Client only after clients are running a supported operating system, management points are set up, and the appropriate SMS security changes have been completed. For more information, see Chapter 4, Understanding SMS Clients.
Developing Strategies for Discovery and Client Installation

Because organizations are diverse, SMS provides a number of discovery and installation methods. Depending on your schedule and whether all prerequisites for the Advanced Client are in place, you might deploy the Advanced Client site-wide as soon as you deploy the SMS site. Or, you might deploy the Legacy Client and then migrate to the Advanced Client as soon as your plan allows.
Overview
You can choose different combinations of discovery methods to locate resources. The discovery method you use determines the type of resources discovered and which SMS services and agents are used in the discovery process. A computer does not automatically become an SMS client through discovery. Depending on how you plan to use SMS, you can choose to perform discovery without performing installation, or vice versa. There are advantages to initiating discovery but not client installation, or vice-versa. For example, if you run discovery while all client installation methods are disabled, SMS discovers resources on your network. Then, when you enable a client installation method in SMS, discovered Windows operating system computers are also installed as SMS clients.
Initiating Discovery Without Initiating Client Installation

The purpose of initiating discovery but not initiating client installation is to gather information about resources in your organization for planning purposes. For example, to refine your plan for SMS site boundaries, you can perform resource discovery to determine the number of computers on each subnet in your network. You can then use this information to determine the best way to install the clients. When you have configured the site boundaries, you can install SMS on client computers. The clients are assigned appropriately, and the client agents are installed.
You can accomplish this by using Network Discovery or Active Directory System Discovery to discover information about system resources on your entire network.
Important
You should notify network administrators if you plan to use Network Discovery. This method can contact devices that other administrators might not expect or want to be contacted. You should let the administrators know that those activities are planned and ask whether they are acceptable.
Initiating Client Installation Without Initiating Discovery

In other situations, the advantage is in initiating client installation but not discovery. You run an SMS client installation method without first running a client discovery method. This is advantageous to SMS administrators who do not want to discover resources that they do not want SMS to manage. This type of installation without discovery can be done by using Group Policy or by initiating client installation in the logon script. For the Advanced Client, you can install the SMS Advanced Client software on the computer without assigning the client to a site. In this scenario, discovery is not run at all. For more information, see Chapter 17, Discovering Resources and Installing Clients.
Monitoring Discovery and Client Deployment

When you enable discovery and client installation methods, you must monitor their progress to ensure that: u u u u u Discovery and client installation methods are proceeding successfully. Discovery and client installation methods are not proceeding too rapidly, possibly causing an excessive load on your network or servers. Clients are being assigned to the appropriate SMS sites. The correct client type is being installed on the appropriate computers. The correct client agents are being installed on Legacy Clients.
The easiest way to monitor the success of the discovery and client installation methods is to examine the collections in the SMS Administrator console. Over time, the collections should become populated with SMS clients. By checking the properties for individual clients, you can ensure that they have the correct site assignment, client type, and client agents. Collections are automatically updated on a routine schedule, but if you do not want to wait for the next automatic update, you should select a collection in the SMS Administrator console, click All Tasks in the Action menu, and then click Update Collection Membership. You should then click Refresh from the Action menu. You can obtain a count of the resources in a collection by clicking Show Count from the Action menu. You can also monitor the progress of discovery and client installation methods by examining the status messages for relevant components under the Site Status node in the SMS Administrator console.
Choosing a Discovery Method

When you are ready for SMS to locate potential SMS clients, you run discovery in SMS. The discovery method you choose depends on whether or not you have Active Directory, and which resource types you want to find based on the objectives you defined in the pre-planning phase. Table 10.5 lists the types of discovery methods that are found in the SMS Administrator console and whether or not the client computer must be turned on to be discovered by SMS, based on the discovery method running. Table 10.5 Planning for SMS Discovery Methods
Type of resources you want discovered Computers Discovery method Heartbeat Discovery Network Discovery Active Directory System Discovery Windows computer users and groups Active Directory computer users and groups Windows User Account Discovery Windows User Group Discovery Active Directory User Discovery Active Directory System Group Discovery No Client computer must be turned on to be discovered Yes No Yes No
For example, if you want to find users instead of computers, you would choose Windows User Account Discovery or Active Directory User Discovery. If you want to find computers to distribute software to, you might choose Active Directory System Discovery. When you choose the discovery method to be used at an SMS site, remember that, for most discovery methods, the client computer does not have to be turned on to be discovered. The exceptions to this are Heartbeat Discovery and Active Directory System Discovery. Do not use either of these methods if you want all computers to be discovered whether or not they are turned on at discovery time.
Important
When you install SMS by using Custom Setup, no discovery or installation methods are enabled (except for Heartbeat Discovery and automatic discovery of site systems, which you cannot configure). If you install SMS by using Express Setup (which should only be done in an isolated test lab for evaluation purposes), all discovery and installation methods are enabled except for Network Discovery. For more information, see the Setup Options section earlier in this chapter.
Unlike SMS 2.0, SMS 2003 does not have Windows Networking Logon Discovery. However, you can still discover computers when users log on to them. For more information, see Chapter 17, Discovering Resources and Deploying Clients. This section describes planning for the following discovery tasks: u u u u u Discovering resources automatically Discovering domain users and groups Discovering resources that have an IP address Discovering Active Directory objects Using scripts for discovery
Note
Manual Client Installation can discover computers without installing the SMS client software on them. For more information, see the Manual installation of the SMS client section later in this chapter.
Discovering Resources Automatically

Some discovery tasks happen automatically in SMS, so you cannot plan for them. These include: u u u Discovery of SMS site systems. Heartbeat Discovery. Discovery performed by SMS during hardware inventory.
SMS site systems and site servers are discovered automatically. Site system discovery provides discovery data about site systems and can trigger their installation as SMS clients if Client Push Installation is enabled and configured to install the SMS client on servers. Because this discovery method is fully automated, you cannot configure it, you cannot disable it, and you do not see it in the SMS Administrator console.
Note
SMS Recovery Web sites are not site systems and therefore are not discovered with Site System Discovery. SMS Recovery Web site computers must be discovered by using other discovery methods.
Heartbeat Discovery is a method that is used to refresh SMS client computer discovery data in the SMS site database. If you enable Heartbeat Discovery, the discovery data is refreshed on a schedule that you determine. If you disable Heartbeat Discovery, the discovery data is refreshed only when another discovery method is invoked or run on a schedule. Heartbeat Discovery is useful for maintaining current discovery data on clients that are not usually affected by one of the other discovery methods, such as a server that users seldom log on to. By default, this discovery method is enabled.
Important
You can set a full schedule on heartbeat discovery so that clients report their discovery data at a specific time on a regular basis. You should avoid doing this on large sites or on many sites at the same time. Otherwise, you could generate a backlog of DDRs waiting for processing, and your network and SMS servers could be subject to a considerable load when heartbeat discovery runs on all the clients concurrently.
Also, if SMS hardware or software inventory loads computer details into the SMS site database before a DDR is received for that computer, SMS automatically creates a DDR for the computer by using the details that are included in the inventory. Because this discovery method is fully automated, you cannot configure it, you cannot disable it, and you do not see it in the SMS Administrator console.
Discovering Domain Users and Groups

If you want to discover domain user accounts and user groups in particular domains, plan to enable Windows User Account Discovery and Windows User Group Discovery. With this information, you can organize domain users and user groups into SMS collections. You can use Windows User Account Discovery with Windows NT domains or mixed mode Active Directory domains. However, Active Directory User Discovery returns more information from Active Directory domains, and it continues to work with those domains when you switch them to native mode. You should only use Windows User Account Discovery with Windows NT 4.0 domains. SMS must be able to access the domains that you specify for Windows User Account Discovery or Windows User Group Discovery by using the SMS Service account or by using the SMS site servers computer account, depending on the security mode SMS is running in. Windows User Group Discovery is useful for creating group-based collections for software distribution. For example, if you want to distribute software based on groups of users, you can use this discovery method to determine which groups are in your domains. If your organization has an Accountants user group, you can discover that group and then advertise software to a collection containing that group.
Important
When discovering Windows user account or group resources within a domain, you must provide SMS with administrative rights and permissions to each specified domain. Do this by granting the SMS Service account (if the site is in standard security mode) or the site server computer account (if the site is in advanced security mode) administrative rights and permissions to the destination domains.
Different SMS sites can discover user accounts in the same domain or in different domains. If you require user resources from a domain at a site and its child site, you should enable Windows User Account Discovery only at the child site. The child site automatically forwards the discovery data to the parent site, so both sites do not have to discover the same users.
You can also schedule how often you want SMS to poll the domain controllers. The discovery data for the accounts is refreshed every time SMS polls the domain controllers. Consider how often you want these discovery methods to poll each domain and generate a new DDR for all user accounts in each domain. This list of user and user group accounts can gradually become inaccurate as accounts are added and deleted in the domain, so set a schedule to keep the list as current as possible.
Discovering Resources That Have an IP Address

Plan to use Network Discovery if you want to find any device on your network that has an IP address. Use Network Discovery to search specific subnets, domains, SNMP devices, and Windows NT or Windows 2000 Dynamic Host Configuration Protocol (DHCP) servers for resources. Network Discovery can also use SNMP to discover resources that are recognized by routers. You can specify a list of SNMP community names and a number of hop counts within which to find routers. The SMS site server must have user-level security access on the DHCP servers to retrieve database information from those servers. The SMS Service account must have domain user credentials in the same domain as the DHCP server. You can use Network Discovery to collect resource discovery data so that SMS can perform Client Push Installation. Plan how you will configure Network Discovery options, based on the amount of discovered resource information you want it to provide and when you want Network Discovery to run, before you enable Network Discovery. For discovery type, choose from the three levels of details: u u u Topology Topology and client Topology, client, and client operating system
Note
If you select the Topology, Client, and Client Operating System level of detail, and if the discovered resource runs the Windows 98 or Windows Millennium Edition operating systems, Network Discovery discovers the client operating system only if the computer is configured to share resources. Users at the clients can specify whether to share resources when they are setting up Windows during the installation process or by using Network in Control Panel.
Network Discovery runs according to the schedule you define in the SMS Administrator console. You must schedule and configure the scope of Network Discovery when you are ready to use it in your organization. Be very careful when you enable Network Discovery. Using Network Discovery increases the amount of traffic on your network. As a result, you should schedule Network Discovery so it does not interfere with other uses of your network. If you plan to run Network Discovery over any slow links, plan to make allowances for network speed and available bandwidth when you configure Network Discovery.
For more information, see the Controlling Discovery and Client Installation section later in this chapter.
Discovering Active Directory Objects

Active Directory discovery methods poll the nearest Active Directory domain controller to discover Active Directory computers, users, user groups, and containers. To use an Active Directory method of discovery, your Active Directory domain can be in either mixed mode or native mode. Plan to specify the containers you want polled, such as specific domains, sites, organizational units, or user groups. Also, plan to specify the polling schedule. SMS polls Active Directory when it is using one of the Active Directory discovery methods. The SMS resources that are obtained from Active Directory do not necessarily reflect the current Active Directory resources at all times; objects might have been added, removed, or changed in Active Directory since the most recent poll. SMS must have read access to the containers that you specify for Active Directory System Discovery, Active Directory User Discovery, or Active Directory System Group Discovery by using the SMS Service account or the site server computer account, depending on the security mode SMS is running in. When the SMS Service account or site server computer account is used by these discovery methods in domains other than the domain the site server is in, the account must have domain user credentials 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

Use Active Directory User Discovery to discover the following: u u u u u User name Unique user name (includes domain name) Active Directory domain Active Directory container name User groups (except empty groups)
You can run Active Directory User Discovery only on primary sites. If you must discover users or groups in domains that only a secondary site is in, configure the secondary sites parent primary site to discover those domains. Use Active Directory User Discovery to discover accounts that you want to categorize into SMS collections. For example, if you want to distribute software to collections of users, use this discovery method to determine which users are in your Active Directory domains. If your organization has users to whom you want to distribute a specific software package, you can discover those user accounts and create a collection containing them. You can then advertise the software package to only that collection, so only the appropriate users receive it. Polling performed by Active Directory User Discovery can generate significant network traffic, although it generates less traffic per resource than Active Directory System Discovery. Plan to schedule the discovery to occur at times when this network traffic does not adversely affect network use.
Also, because SMS polls Active Directory, the SMS resources that are obtained from Active Directory do not necessarily reflect the current Active Directory resources at all times. Users might have been added, removed, or changed in Active Directory since the most recent poll.
Active Directory System Discovery

Use Active Directory System Discovery to discover the following: u u u u Computer name Active Directory container name IP address Assigned Active Directory site
Do not plan to use Active Directory System Discovery to discover the client operating system. There are other discovery methods, such as Network Discovery, that can do this. Polling performed by Active Directory System Discovery can generate significant network traffic (approximately 5 KB per client computer). Plan to schedule the discovery to occur at times when this network traffic does not adversely affect network use and when the computers are turned on. Also, because SMS polls Active Directory, instead of being notified of Active Directory changes, the SMS resources that are obtained from Active Directory do not necessarily reflect the current Active Directory resources at all times. Computers might have been added, removed, or changed in Active Directory since the most recent poll.
Active Directory System Group Discovery

Active Directory System Group Discovery data is an enhancement of the discovery data of other discovery methods. Use Active Directory System Group Discovery to discover the following: u u u u u Organizational units Global groups Universal groups Nested groups Nonsecurity groups
You can run Active Directory System Group Discovery only on primary sites. It polls Active Directory for all system resources in its database, including those discovered at child sites, and including secondary sites. Because Active Directory System Group Discovery does not contact the computers directly, the computers do not have to be turned on to be discovered. Polling performed by Active Directory System Group Discovery can generate significant network traffic, so you should schedule the discovery to occur at times when this network traffic does not adversely affect network use.
Using Scripts for Discovery

You can employ scripts to discover clients during network logon. Scripted discovery is beneficial to SMS administrators who want to completely control the discovery process. It is useful if you are including a wide variety of computers in your SMS pilot project but you do not want to discover too many of those computers, and you do not want to take the time to manually discover them. Scripted discovery is also appropriate if you have special reporting needs. For example, you can create DDRs for computer lease agreements and then generate reports that provide lease details with the computer details that SMS usually collects. For more information about using these methods, see Chapter 17, Discovering Resources and Deploying Clients.
Controlling Discovery and Client Installation

When you install the SMS client core software automatically in a large SMS site, many computers attempt to install the client in a small period of time, such as an hour or two. The load on your network and SMS site systems might be excessive, causing adverse effects on network usage or client computers. For this reason, you should carefully control SMS client installation at large sites.
Note
When you enable SMS software or hardware inventory, the default simple schedule invokes inventory at midnight on the day of client installation. By default, SMS schedules these computers to conduct another inventory seven days later. By staggering client installation times over a longer period of time, you preserve network bandwidth because the number of clients taking and reporting inventory information about subsequent inventory days will also be staggered.
To predict whether the SMS client deployment will adversely affect your site, multiply the number of potential clients by the size of the SMS client software in megabits. Then divide this number by the time period in seconds during which the clients will be installed, presuming the client installation requests are at an evenly distributed rate. Compare the resulting number with the speed of the slowest point in your network. If the network use seems excessive for example, you might consider more than 25 percent as excessive then you must control the client installation. Controlling client deployment can be done by using a variety of techniques that enable the client discovery or installation technique in such a way that only a limited number of clients are installed at one time. For example, you might not want to use logon scripts to discover or install too many clients over a short period of time. This is especially important if you have many users running a common logon script.
Discovery methods are designed to automatically find SMS resources. If your organization has many resources, and you configure the discovery methods inappropriately, SMS might discover many resources simultaneously. This can impose a significant workload on your network and some SMS component servers. To avoid this, you must control discovery.
Network Discovery
You control the rate at which Network Discovery discovers resources by incrementally enabling and configuring Network Discovery options. For example, if you configure Network Discovery to search specific IP subnets to discover resources, you can control discovery by adding only one subnet to the configuration each time Network Discovery is run. Watch the impact of Network Discovery using that one subnet, and add subnets more rapidly if the load is not excessive. Add subnets one at a time, in a similarly controlled manner. You can specify several schedules if you want Network Discovery to run at specific times, including a recurrence pattern that causes Network Discovery to run at regular intervals. New schedules and schedule changes go into effect as soon as they are written to the SMS site control file. When you run Network Discovery on a primary site server, there is a brief delay of about one minute in writing to the site control file. The delay is longer if you are configuring Network Discovery for a child site from the parent site, because the update to the child site control file depends on the schedule for intersites communication to the child site address. If the scheduled time has passed when the data is written to the site control file, the first Network Discovery does not begin until the next scheduled time. For example, if you set Network Discovery to run every Monday at 5:00 P.M., but the schedule is not written to the site control file until Monday at 5:01 P.M., then Network Discovery does not run until the following Monday at 5:00 P.M. To initiate Network Discovery as soon as possible, allow sufficient time for the schedule to be written to the site control file before the scheduled start time.
Other Discovery Methods

You can control the follow discovery methods by configuring their schedules: u u u u u u Heartbeat Discovery Windows User Account Discovery Windows User Group Discovery Active Directory System Discovery Active Directory User Discovery Active Directory System Group Discovery
With Heartbeat Discoverys interaction with the client refresh cycle, you cannot precisely control the time of day that Heartbeat Discovery DDRs are created. However, you can control how frequently they are created over a specified period of time, such as a week or month.
For the rest of the discovery methods that are listed, you can control the time of day or the day of the week that they are run. By setting these methods to perform at nonpeak times when few people are using the network, you can ensure that these methods do not cause an adverse effect on your servers or on available network bandwidth.
Important
If you change a discovery method schedule to run more frequently, the discovery method might run immediately. For example, if the discovery method is originally set to run weekly, and you change it to run daily, it might run as soon as you make the change, even if it is configured to run at midnight. This is because it might have been more than one day since the discovery method last ran.
Deploying SMS Clients

You can deploy the SMS client by using methods that are built into SMS 2003, or you can use other means to distribute the core SMS client components. For example, some organizations might use a software distribution method. Others might install the SMS client on a master computer image that is applied to computers when they are prepared for use in the production environment. The technique you use depends on a number of factors that are specific to your environment. SMS client installation techniques include: u u Installing the SMS client by using a push installation method in the SMS Administrator console. Initiating a program file at the client with one of the following: u u u u u Logon script Manually running program file Windows Group Policy SMS software distribution or other software distribution mechanism
Installing the Advanced Client on a computer master image.
For more information about the SMS 2003 client installation methods, see Chapter 4, Understanding SMS Clients. Do not enable any features in your SMS site, such as discovery method, installation method, inventory, or software metering, until you have a thorough client deployment plan in place.
Overview
For each site in the SMS hierarchy, determine and document which technique you plan to use to deploy SMS client software components to client computers.
See Table 10.6 for the available methods for deploying the Advanced Client software by using the SMS Administrator console or by initiating a program file at the client computer. For more information about other techniques for deploying the Advanced Client software, including using Windows Group Policy, see the Software distribution of the Advanced Client section later in this chapter. If your IT department plans to install the Advanced Client on a computer master image, see the Installing the Advanced Client on a computer master image section later in this chapter. See Table 10.7 for the available methods for deploying the Legacy Client software by using the SMS Administrator console or by initiating a program file at the client computer.
Note
SMS does not support installing the Legacy Client over a slow network link. Such computers should be installed on a network that is well connected to a CAP.
Table 10.6 Planning for SMS 2003 Advanced Client Installation

Automated installation using SMS Administrator console Client Push Installation method Installation by initiating program file at client Logon script Logon Scriptinitiated Client Installation (Capinst.exe) Manual Advanced Client Installer (Ccmsetup.exe) Windows Group Policy Other software distribution mechanism
Client.msi
Ccmsetup.exe
Table 10.7 Planning for SMS 2003 Legacy Client Installation

Automated installation using SMS Administrator console Client Push Installation method Installation by initiating program file at client Logon script Logon Scriptinitiated Client Installation (Capinst.exe) Manual Windows Group Policy Other software distribution mechanism
Manual Client Installation (Smsman.exe)
N/A
N/A
If you want to install SMS clients automatically, use Client Push Installation. If you have run a discovery method and want to deploy the SMS client to the discovered resources, use the Client Push Installation Wizard. If you want to install clients without discovering them, you can run a program file on the client through logon scripts, Windows Group Policy, manually at the client workstation, or by using another software distribution mechanism.
Installing the SMS client by using the SMS Administrator console

SMS 2003 provides support for installing the SMS Advanced Client remotely from the SMS site server by using Client Push Installation. Client Push Installation (or the Client Push Installation Wizard) must be used with an SMS discovery method because it requires clients to be discovered before the SMS client software is installed. Client Push Installation Client Push Installation is useful for installing the Advanced Client or Legacy Client software on computers that: u u u u Have been discovered by SMS but do not have the SMS client software. Rarely log on to the network because the users lock their Windows sessions instead of logging out. Log on with a user account that does not run a logon script or does not have administrative permissions on the computer. Are servers that users might not log on to for a long period of time.
Important
If you enable site-wide Client Push Installation, any compatible resource that is discovered within the site boundaries or roaming boundaries of the site is installed as an SMS client.
Use Client Push Installation to install the SMS client on SMS site systems. Site systems are automatically discovered by using site system discovery. By default, when site systems are discovered, SMS does not trigger Client Push Installation, even if it is enabled. However, you can configure the Client Push Installation Properties to install the SMS client on site systems. If you want to install the SMS client automatically to specific groups of computers, or to computers that have been discovered but not yet installed as SMS 2003 clients, use the Client Push Installation Wizard. If you have many computers in one SMS site, you might choose to use Client Push Installation to install the SMS client automatically. If SMS installs many clients at the same time, your network or SMS site systems might become overloaded. To avoid this, plan to throttle the client installation using the resource-based or collection-based Client Push Installation Wizard. SMS site preparation for Client Push Installation Client Push Installation requires that you grant to all chosen client computers, administrator rights and permissions to either the SMS Service account (if the site is running in standard security mode) or Client Push Installation accounts that you create in the Client Push Installation Properties dialog box in the SMS Administrator console. For more information, see Chapter 5, Understanding SMS Security.
To prepare the SMS site to deploy the SMS client software by using Client Push Installation, you must do the following: u Depending on whether you are installing the Advanced Client or the Legacy Client, ensure that you do the following: u For Advanced Client installation, from Component Configuration, specify an Advanced Client Network Access Account on the General tab in the Software Distribution Properties dialog box. For Legacy Client installation, from Connection Accounts, specify a Windows User Account for the client connection.
u u
Specify a valid account on the Accounts tab of the Client Push Installation Properties dialog box, accessible from Client Installation Methods in the SMS Administrator console. This account must have administrative credentials on the client computers that you want to install the Advanced Client on. Configure an SMS site system as a management point, from Site Systems, and ensure that a default management point is specified for the site.
To troubleshoot Client Push Installation problems during Advanced Client installation, review the Ccm.log file on the SMS site server, which is located in the SMS\Logs folder. On the client, review the Ccmsetup.log and Client.msi.log file, which is located in %Windir%\System32\Ccmsetup. If you want to install the SMS client on specific resources or collections in SMS, you can do this through the SMS Administrator console by using the Client Push Installation Wizard. Client Push Installation must be configured for the Client Push Installation Wizard to work, but it does not have to be enabled.
Initiating a program file at the client

You can initiate a program file at the client through u u u Logon Script-initiated Client Installation. Manual installation of the SMS client. Software distribution of the Advanced Client.
Logon Script-initiated Client Installation If you choose to deploy the SMS client by using logon scripts, plan to use Logon Script-initiated Client Installation. If a logon script is run when your users log on to their computers, one of the easiest ways to discover their computers and install the SMS client is to set up the logon script to include SMS client installation. You do this by using Logon Script-initiated Client Installation (Capinst.exe) and copying the program file (Capinst.exe) to a shared folder from which you run the installation. If your logon scripts are shared across the organization or multiple business units, consider how you will organize the changes to the scripts. SMS administrators at multiple sites might require changes to the logon scripts to enable client installation, but to avoid confusion, you should plan and perform this task in a coordinated manner. For more information about modifying logon scripts to support client installation, see Chapter 17, Discovering Resources and Deploying Clients.
To use Logon Script-initiated Client Installation, you must have a server locator point available, and you must have access to the program file Capinst.exe. When using Logon Script-initiated Client Installation to install Advanced Clients, a management point is also required. When you use Logon Script-initiated Client Installation to install Legacy Clients, a CAP is also required. Capinst.exe is included with SMS 2003. By default, Capinst.exe does not install the SMS client software on domain controllers. For more information, see Chapter 17, Discovering Resources and Deploying Clients.
Important
As a best practice, avoid installing the Legacy Client on domain controllers, especially domain controllers on slow network links.
If your environment does not have Active Directory, or if it does not have multiple server locator points registered in Active Directory, you should always specify the server locator point when you run Capinst.exe. You should specify the server locator point every time you use Logon Script-initiated Client Installation, and you should avoid the excess network traffic that is required to find the server locator point. Similarly, if your clients cannot use Active Directory, you should specify the server locator point when you use Capinst.exe. Be aware of the requirements for Logon Script-initiated Client Installation on clients that are running Windows NT 4.0 and Windows 98. Also, if the SMS site has only Active Directory site boundaries, then computers that cannot use Active Directory cannot become SMS clients with this method. Manual installation of the SMS client There are two manual installation methods: u u Manual Client Installation (Smsman.exe) Advanced Client Installer (Ccmsetup.exe)
Manual Client Installation uses CAPs to install the Legacy Client. Plan for the user or administrator to initiate Manual Client Installation at the computer. Use this method when you do not want to use an automated client installation method, for example, when you are testing SMS in your test lab environment. You can run Smsman.exe from a hard disk, a shared folder, a Web page, an e-mail message, or a floppy disk. Manual Client Installation can be run silently, and you can use it only to discover, not to install, clients. Advanced Clients can be manually installed by using Advanced Client Installer (Ccmsetup.exe). Advanced Client Installer is useful on computers that might not have a network session connected long enough to download the Advanced Client files. If the computer can download the small program file (Ccmsetup.exe) in one session, then the computer can download the remainder of the required Advanced Client Installer files over several network sessions. The advantages of using Advanced Client Installer are: u If the network connection becomes unavailable while Advanced Client Installer is downloading the Advanced Client files to the client computer, the Advanced Client Installer resumes the file download where it was stopped before the network connection was restored.
When you apply an international client pack (ICP) to the SMS site server, the Advanced Client Installer applies the correct localization transform to Client.msi before the Advanced Client is installed. Because Client.msi is available on the destination computers hard disk, you can repair the SMS client installation or apply patches to the Advanced Client software efficiently and completely.
Note
Efficient completion of repair is not guaranteed for a mobile computer performing a repair while it is offline and unable to connect to the Netlogon folder, the management point, or the distribution point if Client.msi is not local.
Software distribution of the Advanced Client You can install the Advanced Client by using the same software distribution techniques that you use when you install any application software. You advertise Advanced Client components to collections that contain SMS Legacy Clients that you want to replace with the Advanced Client. Or, software distribution techniques other than SMS can be used, such as distribution of CDs containing the installation program, or Windows Group Policy using the Client.msi file that is installed on the site server during SMS Setup. For more information about using this technique, see Chapter 17, Discovering Resources and Deploying Clients.
Installing the Advanced Client on a computer master image

You can load Advanced Client software components on the computer when it is originally prepared for service in your organization. Typically, computer preparation work is done by an IT team in a staging area. The Advanced Client is installed on a client computer master image by installing core SMS client components without specifying an SMS site code for assignment. The computer is ready to be assigned to a site when it arrives at the location where it is used in production. The master image with the SMS Advanced Client is automatically configured with an SMS GUID when SMS is installed. The Advanced Client detects that the computer has been prepared from a master image and creates a new GUID. This prevents duplication of SMS GUIDs on client computers when the Advanced Client software is loaded on computers before the computers are put into service in your organization.
Important
Because a Legacy Client installation to a master image cannot detect that the computer was prepared from a master image, the SMS GUID must be removed from the Legacy Client before the computer is removed from the staging area and placed in service. This can be done manually, preferably in the master image, or it can be done by the Windows System Preparation tool (Sysprep.exe).
For information about computer imaging and Advanced Client installation, see Chapter 17, Discovering Resources and Deploying Clients.
Installing the SMS Client on International Clients

When you install an SMS site, the site software includes interface elements in the language that you have purchased. This includes the client components whose interface elements are in the same language. If you have some users at the site that use a different language, you can apply an ICP to the site. ICPs are usually available at http://www.microsoft.com/smserver/default.asp, through TechNet, and other channels.
Installing Legacy Clients on Computers Running Terminal Services

Computers that are running Terminal Services require an additional procedure to install the SMS Legacy Client software. Client Push Installation cannot be used with computers that are running Terminal Services because the installation method does not configure Terminal Services clients for Installation mode before it attempts to install the SMS client software. You must install the Legacy Client manually on computers that are running Terminal Services, or you must use a script that runs the procedure. For more information, see Chapter 17, Discovering Resources and Deploying Clients.
Installing Legacy Clients on Domain Controllers in Active Directory Domains

When installing the Legacy Client, the SMS Client Services and Client User Token accounts are created in the local account database. Domain controllers do not have local account databases. So, when you install the Legacy Client on domain controllers, these accounts must be created in the domains account database. In large Active Directory domains, the replication that is incurred when you create accounts can take an extended period time. Large replications can consume substantial network bandwidth. The Legacy Client installation might not wait long enough for the accounts to replicate, and then the installation can fail. Client Push Installation repeatedly retries the installation, potentially resulting in additional replication traffic. If you have these issues in your environment, here are some options to eliminate or minimize them: u Install the Advanced Client, not the Legacy Client, on domain controllers. This reduces the potential for problems, because the Advanced Client software does not use user accounts. By default, Logon Script-initiated Client Installation does not install an SMS client on domain controllers. Client Push Installation does not install an SMS client on domain controllers if you have cleared the Domain controllers option in the Client Push Installation Properties dialog box. If you install SMS site systems on domain controllers, Client Push Installation does not install the Legacy Client on domain controllers when you have not selected the Enable Client Push Installation to site systems option in the Client Push Installation Properties dialog box.
On the primary domain controller (or primary domain controller emulator), create a REG_DWORD registry value named Enable Domain User Group Membership under the subkey HKLM\SOFTWARE\Microsoft\SMS\Client\Configuration\Domain Controllers. Set it to a non-zero value. SMS does not attempt to remove the client accounts from the Domain Users group, which reduces network traffic. On the primary domain controller (or primary domain controller emulator), create a REG_DWORD registry value named Account Synchronization Max Wait (minutes) under HKLM\SOFTWARE\Microsoft\SMS\Client\Configuration\Domain Controller. Set it to a value larger than the default of 60. The SMS client installation waits this period of time for the account replication to complete.
Assigning Clients to SMS Sites

Each SMS client is assigned to only one SMS site. The Legacy Client site assignment process operates differently than the Advanced Client site assignment. Table 10.8 shows how you can assign clients to SMS sites based on the client installation technique or method that you use. For information about specific techniques used to assign clients to SMS sites, see Chapter 17, Discovering Resources and Deploying Clients.
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.
Table 10.8. Planning for Assignment Techniques or Methods

Client installation method or technique Logon Script-initiated Client Installation (Capinst.exe used without switches) Logon Script-initiated Client Installation (Capinst.exe used with the /SLP= switch) Manual Client Installation (SMSman.exe) How client is assigned The installation method attempts to find a server locator point, which attempts to locate an SMS site that is appropriate for the client. The specified server locator point attempts to locate an SMS site that is appropriate for the client. The Legacy Client is assigned to the site of the CAP that is specified by SMSman.exe (or the Systems Management Installation Wizard) if the client is within the site boundaries. The client is already assigned by the discovery method.
(continued)
Table 10.8. Planning for Assignment Techniques or Methods (continued)

Client installation method or technique Advanced Client Installer (Ccmsetup.exe) How client is assigned The Advanced Client uses Active Directory or server locator points to locate an SMS site that is appropriate for the client, or a site is specified on the Advanced Client Installer command line using SMSSITECODE. Use the Systems Management icon in Control Panel to set the site to a valid site code or automatically detect the site by clicking Discover. Use the SMSSITECODE property to specify the site code. Use the SMSSITECODE property to specify the site code as AUTO. The Advanced Client uses Active Directory or the server locator point to locate an SMS site that is appropriate for the client. Use the Systems Management icon in Control Panel to set the site to a valid site code or automatically detect the site by clicking Discover.
Software distribution
Software distribution (site specified for assignment) Software distribution (automatic assignment)
Advanced Client installation on a master computer image
Assigning Advanced Clients

The Advanced Client is assigned to an SMS site when the core SMS software components are installed, or it is assigned after installation. Its assignment is based on the roaming boundary that the client is in. You can install the SMS software components on the Advanced Client without assigning the client to an SMS site. After it is assigned to an SMS site, the Advanced Client does not change its site assignment. Advanced Client installation is controlled through different means. Advanced Clients can be assigned to an SMS site or they can automatically determine a site to be assigned to at installation time. You can also later manually assign an Advanced Clients site to a different site, set it to automatically determine a site to be assigned to, or assign it to no site. When an Advanced Client is assigned to a site, it maintains that site assignment unless an SMS administrator changes the assignment. For Advanced Clients, determine whether you want to assign the Advanced Client to an SMS site when the Advanced Client software is installed. If you want automatic assignment of Advanced Clients to occur, plan to configure the client to automatically determine a site. If you are not sure which SMS site the Advanced Client computer will eventually belong to, then plan to manually assign the client to an SMS site later. With manual site assignment, even if the Advanced Client does not currently reside within roaming boundaries, it is still assigned to the site you specify. If the Advanced Client is not configured to automatically determine a site, and it is not set to a specific site, it is not assigned to a site and remains dormant, but its installation continues.
Assigning Legacy Clients

Legacy Client site assignment is controlled by SMS site boundary configuration. The Legacy Client is automatically assigned to an SMS site based on the site boundary it is in when the core SMS software components are installed. To ensure proper site assignment when you are using Active Directory site boundaries, be sure that your clients can use Active Directory. For example, clients that are running Windows 98 cannot be assigned to an SMS site based on Active Directory site boundaries. Remember that if the site boundaries that a Legacy Client is in are removed, or if the Legacy Client moves out of the boundaries of its assigned site, the SMS client software is automatically removed from the computer. The exceptions to this are if Travel Mode is enabled on the Legacy Client or if the Forced Sites tool (Site4c.exe) has been used. If the Legacy Client is no longer assigned to an SMS site, it removes the SMS client software.
Important
Computers that are not running Windows XP or operating systems in the Windows 2000 and Windows Server 2003 families cannot belong to Active Directory sites. Those computers cannot be assigned to SMS sites based on membership in Active Directory sites. They can be assigned based only on IP address.
If an individual computer runs an SMS discovery or installation method and then installs the Legacy Client, then it cannot be specifically included or excluded in the assignment process; it is assigned just like all the computers in that subnet or Active Directory site. If you do not want a particular computer to be an SMS Legacy Client, you must ensure that all SMS discovery and installation methods are configured in such a way that they do not run on the computer. When the core Legacy Client software components are installed, you can specify a CAP or a list of CAPs. If the Legacy Client is in the site boundaries of one or more of those CAPs, it is assigned to the first site associated with those CAPs. If the client does not match the boundaries of any site, it is unassigned and its software is removed.
Forcing Client Assignment

If some of your Legacy Clients do not fall within SMS site boundaries, but you want to assign them to a site, you can force them to report to a site by using the Forced Sites tool (Site4c.exe). For information about using this tool, run the Forced Sites tool with the /? switch. The Forced Sites tool is available for download with the SMS 2.0 Support Tools at http://go.microsoft.com/smserver/downloads/20/default.asp.
Note
You can force Advanced Client assignment during client installation or by using the Systems Management icon in Control Panel. The Forced Sites tool is not applicable to Advanced Clients.
Evaluating Subnet Membership

SMS can use IP subnets as SMS site boundaries and roaming boundaries. If you use IP subnets as a means to determine SMS site assignment, you must add the appropriate IP subnets as boundaries to relevant SMS sites. Usually, each SMS site has a unique collection of subnets. Subnets should not be specified as boundaries in more than one SMS site. This allows each site to have a unique set of SMS clients. This section helps you evaluate which subnets your computers are in.
IP Subnets
Network equipment uses IP subnets to determine which logical network segment a computer is in on a TCP/IP network. Any computers with the same subnet ID are logically close to each other and can communicate directly. Computers on the same subnet do not need intermediate network equipment to assist with the communication. Computers on different subnets might be distant from each other. For example, they might be across slow network links, like a WAN link. Subnets are an effective way to map computers to physical locations. For many organizations, a single subnet is not large enough to serve all the computers in a single physical location. Therefore, multiple subnets are used for a single location, even though the computers are physically close to each other. In this situation, multiple subnets are used to map computers to a physical location.
In the pre-planning phase, you obtained a list of subnets for your SMS sites from the network administrators who set up your computer network. If you need to confirm this information, you can determine an IP subnet ID by applying the client computers IP subnet mask to its IP address. The subnet is the portion of the clients address that is masked off by the subnet mask. The remaining portion of the IP address is the computers IP address. To obtain the subnet ID, apply the subnet mask to the IP address by converting the IP address and subnet mask to binary numbers, and by keeping the bits in the IP address that have bits set in the subnet mask, and then converting the result back to decimal. The result is the subnet ID. Alternatively, you can use the script in Listing 10.1 to determine the subnet ID for a computers given IP address and subnet mask. You can use the resulting subnet as a site boundary or roaming boundary for the SMS site. If the computer has multiple network adapters, the script in Listing 10.1 displays the subnet IDs for each network adapter. Network adapters that have multiple addresses are called multihomed. The script in Listing 10.1 does not display the subnet IDs for multi-homed network adapters.
Listing 10.1 Script (Subnet.vbs), used to display the subnet ID for the computers given IP addresses and subnet mask
'subnet.vbs - displays the subnet for the computer's (or given) IP ' addresses and subnet masks Set Arguments = Wscript.Arguments If Wscript.Arguments.Count=2 Then SubNetIT Arguments(0), Arguments(1) Wscript.Echo "" Else Set loc = CreateObject( "WbemScripting.SWbemLocator" ) Set WbemServices = loc.ConnectServer( ,"root\cimv2" ) Set Adapters=WbemServices.ExecQuery( "Select * FROM" & _ " Win32_NetworkAdapterConfiguration" ) For Each Adapter in Adapters If NOT IsNull( Adapter.IPAddress) Then WScript.Echo "Description: ", Adapter.Description SubNetIt Adapter.IPAddress(0), Adapter.IPSubnet(0) WScript.Echo "" End If Next WScript.Echo "You can also specify an address and subnet mask as " & _ "parameters to this script." WScript.Echo "" End If WScript.Echo "At least one subnet must be a site's boundary for this computer" WScript.Echo "to be assigned as a client." Sub SubNetIt( Address, Subnet ) WScript.Echo "IP address: ", Address WScript.Echo "subnet mask: ", Subnet dim addressbytes(4) dim subnetmaskbytes(4)
(continued)
Listing 10.1 Script (Subnet.vbs), used to display the subnet ID for the computers given IP addresses and subnet mask (continued)
i=0 period = 1 while period<>len( address ) + 2 prevperiod=period period = instr( period+1, address, "." ) + 1 if period = 1 then period = len( address ) + 2 addressbyte = mid( address, prevperiod, period-prevperiod-1 ) addressbytes(i)=addressbyte i=i+1 wend i=0 period = 1 while period<>len( subnet ) + 2 prevperiod=period period = instr( period+1, subnet, "." ) + 1 if period = 1 then period = len( subnet ) + 2 subnetmaskbyte = mid( subnet, prevperiod, period-prevperiod-1 ) subnetmaskbytes(i)=subnetmaskbyte i=i+1 wend subnet="" for i=0 to 3 subnet = subnet & (addressbytes(i) AND subnetmaskbytes(i)) & "." next subnet = left( subnet, len(subnet)-1 ) WScript.Echo "subnet: ", subnet End Sub
Evaluating Active Directory Site Membership

SMS can use Active Directory site names as SMS site boundaries and roaming boundaries. One advantage to using Active Directory sites as SMS site boundaries or roaming boundaries is that when subnets are added to an Active Directory site that is contained in SMS boundaries, you do not have to add the subnets to your SMS site configuration. If the Active Directory site is added as a boundary, no further configuration in SMS is required. SMS clients in the newly added subnet are assigned to the Active Directory site, which is already equated to the SMS site, and the clients are assigned to the SMS site. If you use Active Directory site names to determine SMS site assignment, you must add the appropriate Active Directory site names as boundaries to relevant SMS sites. You use IP subnets to evaluate Active Directory site assignment. This assignment is evaluated during logon by the operating system, not by the SMS client software.
The Pilot Project 387
Active Directory sites and site assignment are described in Chapter 3, Name Resolution in Active Directory, in the Microsoft Windows 2000 Server Distributed Systems Guide in the Microsoft Windows 2000 Server Resource Kit. You can determine which Active Directory site a client is assigned to by examining the following registry key: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSite The site assignment process can be overridden by using the following registry key: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\SiteName Listing 10.2 is a script that displays which Active Directory site is assigned to the computer that you run the script on. Listing 10.2 Script (Site.vbs), used to display which Active Directory the computer belongs to
Set WshShell = Wscript.CreateObject("Wscript.Shell") On Error Resume Next Site = "Not Assigned" Site = WshShell.RegRead( "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\" & _ "Services\Netlogon\Parameters\SiteName" ) If Err.Number=-2147024894 Then Site = WshShell.RegRead( "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\" & _ "Services\Netlogon\Parameters\DynamicSiteName" ) End If If Site = "Not Assigned" Then WScript.Echo "This computer is not assigned to an Active Directory site." Else WScript.Echo "This computer is assigned to Active Directory site: " & site End If
The Pilot Project

A pilot project is a series of in-house performance tests of your client and server hardware with standard production software installed. The pilot project is performed on a small group of computers in your production environment before you deploy SMS to the organization. It essentially tests and validates all of the plans you have created during the planning phase described in this book. Running the pilot project allows you to draw conclusions and refine your SMS hierarchy design and deployment plan.
Important
Continue to review the hierarchy design as you create the pilot project and refine the deployment plan. Test it in the lab. If you have a multitiered hierarchy, test the depth of it. For example, distribute software to the lowest tier to see if it gets there fast enough. Or, run hardware inventory at the lowest tier and measure the bandwidth cost of sending the inventory back up to the central site. Make changes and test them before you deploy your SMS hierarchy in your production environment.
Understanding the Pilot Project

Your pilot project does not have to be a complete test of all system functionality. However, it allows you to analyze and confirm whether your chosen design will work well in your production environment. The object of the pilot project is to create a small-scale version of your full production deployment, not to watch SMS function in a clean environment with few obstacles. The closer your pilot project installation is to your actual network design and hardware, the more valuable the results are as you plan the deployment of SMS throughout your enterprise.
What the Pilot Project Accomplishes

Running the pilot project enables you to accomplish the following tasks:
Calculating load signature

To create an accurate deployment picture, you must understand the load signature for each site server in the SMS hierarchy design you have created. Load signature is the set of performance metrics of SMS components on a specific computer hardware configuration. Load signature is unique on each SMS site server. It is affected by a variety of factors, including hierarchy design, site design, feature options enabled, feature configuration, task frequency, and numbers of clients. Running a pilot project provides the information you need to measure and manipulate the load signature of your systems before deployment. For more information about load signature, see Chapter 9, Capacity Planning for SMS Component Servers.
Evaluating the effect of using various SMS features

The pilot project will help you determine how the SMS features that you plan to enable in your SMS hierarchy and the order in which you implement them will affect site systems, SMS clients, and the network. Ensuring that your pilot project resembles the production environment as much as possible will result in more accurate results.
Testing your SMS project plan

In the pilot project, you actually implement the plans you created and documented for training IT staff and end users, deploying SMS sites, configuring SMS, deploying SMS clients, performing a backup and recovery of an SMS site, and all of the other tasks documented in your project plan. The pilot project is a test of all the project documentation you have created. It helps determine if your deployment and configuration plan will work in your final production deployment.
How the Pilot Project Works

To meet the objectives of the pilot project, include a variety of users and computers in the pilot program. Also, focus on the functions that you believe might cause problems in the production environment or that have caused problems in your test lab. However, remember that the pilot project is still a test phase. Try to include users who are accustomed to working with new software and with diverse configurations. The pilot project uses a small subset of the production computers, but you conduct the deployment to these computers in a careful and controlled manner. You should carry out the pilot project in stages. For example, first test inventory functionality in your pilot project, then test software distribution functionality, and so on. However, treat the pilot project as a complete but very limited deployment. It can be tempting to let the pilot project expand until it includes all production computers, but this might create risks. Ensure that all implications and risks are understood in advance. Based on the success of your pilot project, you must decide whether to expand the pilot project into a production deployment, or dismantle the pilot project before deploying SMS in production environment. Complete your pilot project before you proceed to full-scale production deployment. When you complete each phase of your pilot project, document your results, verify that you met your project requirements, and rework your plan if necessary. Resolve any major issues before you proceed to the full-scale deployment phase.
Creating the Pilot Project

You must determine server sizing for the pilot project to create a representative pilot environment that closely resembles your production environment, but is on a smaller scale. After reading this section, you will be prepared to run your pilot project, collect data, and determine your individual hardware system load signatures.
Sizing Site System Hardware

When you are running a pilot project, you should use hardware that is sized similarly to what you will use in your production environment. It is a good idea to use the same servers in your pilot project that you have procured for your production deployment of SMS. To determine hardware sizing for your pilot project and for your actual deployment, use the guidelines for hardware sizing in Chapter 9, Capacity Planning for SMS Component Servers.
Creating a Representative Pilot Environment

For the pilot project results to be useful, it is important that your pilot environment truly reflects your intended SMS hierarchy, with representative network connections intact and available for testing. Your pilot project hierarchy should include a representative of each type of site system role, server, and client that will exist in your full SMS hierarchy. The central site and several of its child primary sites are important choices. However, several secondary sites and clients are also important. Your pilot project data might be distorted if you create a pilot environment that contains only computers with fast processors and a large amount of memory and does not include the less powerful, smaller computers in the hierarchy. You can gain valuable information by watching how your SMS hierarchy functions in your network as it exists today, including outdated computers and obsolete applications.
Caution
Do not use the same site code name for more than one site in your enterprise. If you are sharing or replicating WINS between two Active Directory forests, and you use the same site code in your production SMS site as the site code of a pilot SMS site in a different forest, the WINS registrations for the sites might overwrite one another. This can cause the Advanced Client to use the wrong WINS database and therefore the wrong management point, causing the Advanced Client policy to be reset in the wrong SMS site. The Advanced Client is no longer a member of the pilot site and cannot participate in the pilot project. For more information, see Chapter 17, Discovering Resources and Installing Clients.
Running the Pilot Project

Allocate as much time as you have available for running the pilot project. This might be a week, a month, or longer, depending on the size and complexity of your SMS hierarchy, the variety of platforms running, and the number of SMS features enabled. Involve as many members of your SMS team in the pilot project as possible, including SMS administrators, programmers, database administrators, and help desk support personnel. During the pilot project, perform as many critical work functions as possible. These include training the SMS staff members, deploying SMS sites and clients, configuring sites, practicing your software distribution process, practicing a backup and recovery scenario, and other functions, listed in Table 7.10 in Chapter 7, The Pre-Planning Phase. Prioritize which work functions to perform based on your overall SMS objectives, listed in Table 7.9 in Chapter 7. For example, if you plan to use SMS for hardware inventory, software inventory, and software distribution only, then test those functions to the fullest in your pilot project.
Assuming you have already determined hardware sizing, the following steps summarize the process to run your pilot project: Synchronize date and time Be sure to synchronize the date and time on all the pilot computers. Synchronized system clocks enable you to identify issues occurring across several computers by matching events that are recorded in log files with the same time stamps. Install SMS 2003 Install SMS exactly as you will during the actual deployment, based on the deployment plan you have created. This includes the sequence of primary and secondary site installations, hierarchy design, and setup options, and it includes using the data that you gathered in the previous sections to determine how to install your SMS site database server. For example, you might deploy SMS sites in this order: u u u Install SMS on the designated central site server, and be careful to install all the components you want to run in your production environment. Install all child primary sites, and connect them to the central site. Install secondary sites.
Install tools and enable logging and reports As you install each SMS site, configure tasks, alerts, and the SMS status system. Install SMS and Windows performance tools to test your pilot SMS hierarchy. Most of these tools have logging capabilities that you must enable. You should also enable logging for the site by using SMS Service Manager. For more information, see Chapter 9, Capacity Planning for SMS Component Servers. For information about which logs and SMS reports to analyze during the pilot project, see Chapter 1, Scenarios and Procedures for Deploying SMS 2003, in the Microsoft Systems Management Server 2003 Operations Guide. Configure SMS sites and site systems Configure security settings, site boundaries, and roaming boundaries. Prepare and assign SMS site systems for each site in your hierarchy. Configure site communications. Attach SMS sites to one another to create the site hierarchy. Deploy SMS clients Discover and install clients that are participating in the pilot project, based on the client deployment plan that you developed. Enable features Enable the same SMS features that you will use in your production site. Collect data Use logging to collect data about server load signature. Analyze data Watch for bursts and other problems that affect performance. After you identify and resolve these problems, rerun the appropriate tests. For more information about bursts, see the Burst and Recovery Effects on Design section later in this chapter. As part of your formal change management process and tracking system, ensure that you keep a complete record of your activities during the pilot project. This information will be of considerable use after the pilot project is complete and you are ready to refine your final site design. Diagram the Pilot Project After you work through the pilot project, ensure that you have a diagram of the design that you are using. Keep records of all activities associated with your pilot project. Your final documentation should include a record of all the changes you make during the project, in addition to any cost-benefit analyses.
The hierarchy that you developed during the initial SMS hierarchy planning stages and a diagram of the pilot project hierarchy will enable you to refine your final SMS hierarchy design. The first diagram that you created is based heavily on your organizations business and operational issues. Your final site design will probably closely resemble this diagram. The diagram that you create while you are running the pilot project enables you to identify the hardware you require to make SMS function smoothly in your SMS hierarchy.
Using Performance Tools

A primary objective of the pilot project is to analyze your SMS hierarchy design. As you conduct the pilot project, use SMS and Windows performance tools to test performance throughout your SMS hierarchy. To complete this analysis, you must use several different tools that are either provided with SMS 2003 or are available for download from the Microsoft Web site. There are two types of tools in your pilot project: production tools and test tools. Production tools run in your production environment. They must be part of your load signature and should not be run remotely. SMS status messages and Network Monitor are designed for use in a production environment. Test tools are not optimized for your production environment, and must be moved to a remote computer or disabled on the pilot project after preliminary testing. Logging is a test tool that is frequently used by SMS administrators in production. System Monitor is both a test and production tool. However, it has only a slight effect on system resources and does not significantly affect your load signature calculations, unless the frequency and number of counters that are enabled is excessive. For more information about using these tools to analyze performance, see Chapter 9, Capacity Planning for SMS Component Servers.
Using Remote Monitoring

To calculate a true load signature, you must ensure that the computers and environment that you are using for testing simulate your production environment as closely as possible. Ensure that the only processes running on your pilot computers are processes that will be running in a production environment. This means that you must run some of your tools remotely or from a computer for which you are attempting to obtain a load signature.
Analyzing the Design and Making Changes

As you run the pilot project and monitor performance, keep track of anticipated design changes based on the following considerations: u u u SMS hierarchy design optimization Burst and recovery effects on design Total processing time and design
u u
Hardware tuning Software tuning
SMS Hierarchy Design Optimization

While you conduct your pilot project, identify any hierarchy or hardware problems that require troubleshooting. After you identify and correct any such problems, you are ready to retest for the problems. Testing and troubleshooting are iterative processes that can be repeated for as long as an SMS component or site does not meet the performance goals set during the initial planning stages. The load on an SMS site or client frequently varies between idle and busy. A constantly busy computer is as uncommon as a constantly idle site. Therefore, to interpret how your system is functioning, do not wait for just hardware or system failures. You must also carefully investigate how your computers are working. Understanding where problems are likely to arise requires practice. When you are familiar with the log files, all the SMS and Windows performance tools, and performance issues, you can more quickly identify and resolve many of the issues described in the following sections.
Burst and Recovery Effects on Design

Many SMS processes generate bursts of information and load up SMS inboxes with information that is processed in a timely manner. However, if your computer cannot process this information, or if it cannot process the total amount of files that are generated at one time during bursts, you might have a serious performance issue. Ensure that you watch for burst and recovery situations that might overload your hardware resources. Bursts might occur whenever you have a scheduled item that occurs at a specific time. u u If you schedule an advertisement to run at a specific time for all clients in the site, a burst of status messages is likely. If you schedule hardware or software inventory to run at the same time on all clients in the site, a burst of Management Information Format (MIF) files and software inventory files is possible. If you schedule a particular discovery method to run at a particular time, a burst of DDRs is possible. If the site must perform a resynchronization operation, a burst of full MIFs from clients in the site is likely. During operations that tend to occur during certain times of the day, bursts are likely to occur. For example, when employees log on to their computers in the morning, a burst of advertisement status messages, DDRs resulting from network discovery, and hardware and software inventory files is likely.
u u u
Total Processing Time and Design

The total time it takes for your computer to process files is an important performance metric. For example, the time it takes for a client to take hardware inventory, plus the time it takes for the hardware inventory file to reach the SMS site database, is the total processing time for inventory. When you are running your pilot project, you should regularly take total time measurements for every type of process. One basic operation to monitor on the site server is the total time that it takes the server to process objects, such as DDRs and MIF files. To do so, locate the server component that processes the object that you are interested in, and review the time stamps in the corresponding log file to determine the length of time it took to process individual objects. For accurate results, use System Monitor. It is important to consider that using this method to monitor processing time can be somewhat misleading, because it is not obvious what other processing tasks the server might be performing during that interval. The processing of many SMS objects simultaneously by the server will affect the time required to process individual objects. After you identify the problems in your SMS hierarchy design, you should analyze the cost in time and money that will be required to resolve each problem against the benefits of improved performance. You might have to perform this analysis several times to create a system with outstanding performance. It is often true that a computer system could have better performance, regardless of the amount of performance tuning that has already been conducted. However, there is a point at which the time gained by increased performance is outweighed by the money and effort required to create a better system. Identifying the cost, in both additional hardware expenditure and additional hours to troubleshoot and resolve a performance issue, can be difficult. After your pilot project has been running for some time, you will have a better idea of how to conduct your performance testing and troubleshooting. You can assume at the start, however, that disk I/O problems will be the hardest to diagnose and will require the most hours to resolve, while CPU problems will be the easiest to diagnose and resolve. However, disk I/O improvements are likely to give a very large return on the time invested in diagnosing them, so they are likely worth your time and effort.
Hardware Tuning
You can solve some problems, such as disk I/O and memory issues, without hardware tuning. For example, if you receive Out of Virtual Memory error messages on your site server, you might have to adjust your virtual memory sizes. See your Windows documentation for more information about adjusting virtual memory. Some hardware issues can be solved quickly and easily by adding a physical disk or more memory. These are easy, relatively inexpensive options that will tax neither your hardware budget nor your time or staffing resources. For this reason, it is a good idea to identify these problems first and resolve them as you proceed through each iteration of your system analysis.
Testing and optimizing your disk I/O is vital to a successful SMS deployment. Although you can take several different approaches after deployment to reduce disk I/O problems, it is best to address those issues when you test your site system hardware. Both hardware and software RAID solutions can be very effective in addressing disk I/O issues. When trying to avoid problems caused by disk I/O bottlenecks, consider the following actions. These actions provide progressively better performance (at increasing levels of expense): 1. 2. Add more physical disks. Installing the data device, log device, and SMS directories on separate disks will result in moderate improvement. Implement hardware RAID arrays. If you have a large number of disks in multiple volumes, successfully implementing hardware RAID will result in excellent reliability and speed improvements.
Disk I/O issues can be difficult to diagnose. For information about individual disks and software RAID, see the Microsoft Windows 2000 Resource Kit and your hard disk specifications. Diagnosing the disk I/O activities of your hardware RAID is more difficult because the built-in Windows 2000 system counters for disks do not recognize disks that are masked by a hardware RAID layer. You might consider using third-party software to identify disk I/O problems and consulting hardware RAID manufacturers to optimize systems that use hardware RAID. For more information about hardware tuning, see Chapter 9, Capacity Planning for SMS Component Servers.
Software Tuning
Configure both SMS and SQL Server for optimal performance.
SMS Tuning
The intervals of all the operations that run in your site greatly affect the load that your site sustains while running every day. For example, hardware and software inventory are the most processor-intensive operations on clients and servers. Reducing the frequency of inventory collection by as much as your requirements allow frees up computing resources and enables you to maximize your hardware investment. Carefully select the low network traffic times to schedule hardware and software inventory to run on clients. The number of SQL Server connections that are required by SMS is determined primarily by the number of remote SMS Administrator consoles that are running and connecting to it at any given time. If more than 40 simultaneous remote SMS Administrator consoles access an SMS site, you should monitor the connection status in SQL Server. For more information about setting SQL Server connections, see Chapter 15, Deploying and Configuring SMS Sites.
SQL Server Tuning

You can use the following settings to manually tune SQL Server for the SMS site database in your SMS hierarchy: u u TempDB data size TempDB data space available
u u u u u u
TempDB log size TempDB log space available SMS data size SMS data space available SMS log size SMS log space available
For more information about SQL Server tuning, see Chapter 9, Capacity Planning for SMS Component Servers.
Dismantling the Pilot Project

For security reasons, you might choose to not to let your production environment grow from your pilot project. After you assemble a complete record of your final design considerations, and you are ready to proceed to final site design, you can remove SMS. The best way to prevent potential security problems is to completely reformat and prepare each computer for production from a clean state. Remove and reinstall SMS, SQL Server, and Windows 2000 to ensure that your production databases, security settings, and SMS hierarchy can be created without any configurations or data left over from your pilot project. After you develop a final SMS hierarchy design and dismantle your pilot project, you are ready to implement your actual SMS hierarchy and deploy SMS throughout your organization. When you do so, ensure that your network is ready to grow as your organization grows. Be prepared for upgrades and basic system maintenance tasks. Understanding how upgrades will affect you and your network is critical to the continued smooth functioning of SMS. For information about deploying and configuring SMS sites, see Chapter 15, Deploying and Configuring SMS Sites. For information about deploying SMS clients, see Chapter 17, Discovering Resources and Deploying Clients.
C H A P T E R
1 1
Planning an Upgrade
Before upgrading to Microsoft Systems Management Server (SMS) 2003, you must create a plan that addresses the strategies you want to use to upgrade your SMS hierarchy, sites, and clients. You must also consider how to address features that are not supported in SMS 2003, and how to plan for new features that are in SMS 2003. This chapter is intended to supplement the information in Chapter 8, Designing your SMS Sites and Hierarchy, and Chapter 10, Planning Your SMS Deployment and Configuration.
Note
For a step-by-step description of SMS site deployment procedures and common SMS site deployment scenarios, see Chapter 1, Scenarios and Procedures for Deploying SMS, in the Microsoft Systems Management Server 2003 Operations Guide.
The steps you take to upgrade to SMS 2003 depend on the configuration of your existing SMS sites and the system management goals you have. Some goals you have might include: u u Adopting the Advanced Client to reduce the overall number of sites that you administer. Managing an increased number of mobile devices in your enterprise.
This chapter describes strategies to help ensure a successful upgrade from SMS 2.0 SP4 or later to SMS 2003.
In This Chapter
u u u u u Overview. Preparing to Upgrade. Upgrade Strategies. Finalizing Your Upgrade Plan. Post-upgrade Migration Planning.
398 Chapter 11 Planning an Upgrade
Overview
Before you can create an upgrade plan, you must determine what goals and results you want to achieve by upgrading to SMS 2003. u Determine whether you to upgrade all or some of your SMS 2.0 sites to SMS 2003. If you have mission-critical applications that run on Microsoft Windows 95 only, you cannot upgrade those clients to SMS 2003. However, you might want to migrate those clients to a holding site. For more information about holding sites, see the Upgrade Strategies section later in this chapter. You might have secondary sites on Windows NT 4.0 backup domain controllers (BDCs). If any BDC is the first domain controller upgraded to Windows 2000, to support upgrading to SMS 2003, then that BDC becomes a primary domain controller emulator. u Determine whether to deploy the Legacy Client, Advanced Client, or both to each SMS site. You might decide that one of your sites must support the Advanced Client only, and that you want all your other sites to support the Legacy Client. Phasing your transition to the Advanced Client allows the opportunity for you to sufficiently test the Advanced Client and prepare your help desk staff to support it. Regardless of which client you deploy to a given site, each client has its own requirements for your organization. For example, the Advanced Client requires server infrastructure that the Legacy Client does not. Some other issues to consider include: u u u u u u Operating system requirements Training requirements Management requirements Support requirements Network bandwidth constraints
Determine which SMS 2003 features you want to use. SMS 2003 has many useful features. Some features have requirements that must be met before you can use those features. Keep your goals in mind as you determine which upgrade strategy helps you achieve the desired results, because feature requirements might conflict with your desired results.
Preparing to Upgrade 399
Preparing to Upgrade
To prepare for your migration, do the following: 1. 2. Replace hardware and operating systems before upgrading to SMS 2003, if possible. Resolve issues found by the Deployment Readiness Wizard.
Replace Hardware and Operating Systems Before Upgrading to SMS

Before you upgrade your SMS sites or clients, review the Getting Started chapter at the beginning of this book. It details system requirements and platforms supported by SMS 2003. This review helps you determine if you must plan for hardware or operating system upgrades and replacements. It is important to make these changes to your hardware and operating systems before upgrading to SMS 2003. However, you might consider replacing hardware during a side-by-side upgrade if you want to establish new SMS sites on new hardware. For more information about side-by-side upgrades, see the Side-by-Side Hierarchy Upgrades section later in this chapter.
Resolve Issues Found by the Deployment Readiness Wizard

The SMS 2003 Deployment Readiness Wizard (DRW.exe) helps you determine what needs to be done to prepare your site hierarchy for an upgrade. The wizard normally runs during the upgrade process. If the wizard finds errors, you must correct them and then run the wizard again before the upgrade can continue. You can run the wizard manually from the SMSSETUP\BIN\I386 folder on your SMS 2003 product CD. After you correct all identified problems, upgrade proceeds.
Note
Depending on the complexity of your site hierarchy, it might take several hours to run the Deployment Readiness Wizard.
The wizard runs the following types of tests: u u u u u u u Platforms and operating system tests SMS version tests Database tests SMS 2.0 features tests Passed Passed with warning Error
The wizard returns the following types of test results:
When the wizard completes its tests, detailed results are displayed in the Deployment Readiness Tests Report in SMS\Logs\<sitecode>_Report.xml. Summary test result data is stored in %systemroot% in a log file named SMSDRW.log. SMS 2003 does not support all the operating systems, network operating systems, or processor types that SMS 2.0 did. You must run the Deployment Readiness Wizard on SMS 2.0 SP4 or higher site servers. The following tables list tests run by the Deployment Readiness Wizard. Table 11.1 SMS 2003 Deployment Readiness Wizard Platforms and Operating System Tests
Test name Alpha processor clients Information SMS 2003 does not support alpha-based systems. For more information about SMS site system requirements, see the Getting Started chapter in this book. Verifies that a FAT drive does not exist on the site server. SMS 2003 does not support compressed packages stored on a FAT drive. For this test to pass, you must convert the FAT drive to an NTFS drive. A FAT drive on the site server might exist to store compressed copies of SMS packages. If you convert the FAT drive to NTFS, then, after you upgrade to SMS 2003, you must upgrade all packages and move them to an NTFS drive. Clients that use IPX as their site boundary do not fall into any of the supported site boundaries. SMS 2003 clients require TCP/IP. NetWare is an unsupported operating system for SMS 2003 site servers and site server roles. You must remove NetWare from existing computer hardware so that the hardware can support SMS 2003. Failure type Warning
FAT drive on site server
Warning
IPX site boundaries Non-TCP/IP clients Novell NetWare server site systems
Warning Warning Error
Pre-Windows 2000 SP2 site systems
SMS 2003 site systems require Error Windows 2000 SP2 or later. For this test to succeed, you must either upgrade your SMS 2.0 site systems or remove them. For more information about SMS site system requirements, see the Getting Started chapter in this book.
(continued)
Table 11.1 SMS 2003 Deployment Readiness Wizard Platforms and Operating System Tests (continued)
Test name Secure client configuration Information Failure type Identifies those computers in the SMS site running Warning Windows 2000 or later that have the SMS 2.0 client installed. When you upgrade the site, SMS 2003 installs the Legacy Client on these computers. However, the recommended client for computers running Windows 2000 or later is the Advanced Client. The Legacy Client will run and is supported on Windows 2000 or later, but is intended solely to assist with the migration to the preferred Advanced Client on these platforms. For more information about the Legacy and Advanced Clients, see Chapter 4. Verifies that none of the clients assigned to the site are running an unsupported operating system. Unsupported client operating systems include: Windows 3.1, Windows for Workgroups 3.11, Windows NT 3.51, Windows NT 4 without SP6, Windows 95, Windows Millennium Edition, Windows XP Home Edition, or any operating system with Internet Explorer 4 or earlier. Warning
Unsupported client operating systems
Windows 98 FE without Internet Explorer 5
Verifies that all of the clients running Windows 98, Warning First Edition that are assigned to the site have Internet Explorer 5 or later installed. For this test to succeed, you must enable and collect software inventory.
Table 11.2 SMS 2003 Deployment Readiness Wizard SMS Version Tests
Test name Indirect child sites earlier than SMS 2.0 SP4 Information Failure type Verifies that all sites below the direct child sites of Warning the site being tested are running SMS 2.0 SP4 or later. For more information about SMS site system requirements, see the Getting Started chapter in this book. Verifies that the site server being tested and all its direct child sites are running a version of SMS 2.0 SP4 or later. For more information about SMS site system requirements, see the Getting Started chapter if this book. SMS 2003 supports an upgrade path from SMS 2.0 SP4 or later. For this test to succeed, you must not have any SMS 1.2 clients in the site. Error
Pre-SMS 2.0 SP4 sites
SMS 1.2 Clients
Warning
Table 11.3 SMS 2003 Deployment Readiness Wizard Database Tests

Test name Collation of temp database and SMS database should be the same Information Verifies the collation of the temporary database and the SMS database are the same. Microsoft SQL Server 2000 supports objects having different collations. If you receive an error, you must change the collation for the SMS database for the test to succeed. Review the test results and SQL Server documentation for more information. Failure type Error
Site database SQL Server version SMS 2003 supports SQL Server 7.0 SP3 or later. Error less than 7.0 SP3 Additionally, SMS 2003 requires SQL Server 2000 with SP3 for Advanced Security. For more information about SMS site system requirements, see the Getting Started chapter in this book.
Table 11.4 SMS 2003 Deployment Readiness Wizard SMS 2.0 Features Tests
Test name Backlogged inboxes Information Verifies that the site server is processing critical inboxes in a timely fashion, and does not have any files older than one day. Review the tests results for more information. Verifies that all distribution points in the site have the latest version of software distribution packages. Review the test results for more information. Verifies that the site does not have any duplicate client IDs in its database. The scope of this test is all clients assigned to the site or any site under it in the hierarchy. Duplicate client IDs can cause various problems including client inventories that are not valid and problems with software distribution. Review the test results for additional information. Verifies that the SNMP Event to Trap Translator agent is not enabled on the site. You must disable this agent for the test to succeed. Note that this feature is natively supported in Windows 2000 and later operating systems. Failure type Warning
DP has latest versions of packages
Warning
Duplicate client IDs
Warning
Event to trap translator
Error
(continued)
Table 11.4 SMS 2003 Deployment Readiness Wizard SMS 2.0 Features Tests (continued)
Test name Hardware Inventory Group Map Information Failure type Verifies that the inventory definitions for the Warning SMS 2.0 site have not been extended in a way that conflicts with the updated inventory definitions for SMS 2003. Review the test results for more information. Verifies that all the clients assigned to the site recently communicated successfully with the site client access points (CAPs). If clients are not communicating with the site server, they might not upgrade successfully. SMS 2003 does not support logon points. This is because SMS 2003 does not support Windows Networking Logon Discovery or Windows Networking Logon Installation. You must disable Logon Client Installation for the test to succeed. Because SMS 2003 does not support logon points, logon discovery is not included as a discovery method in SMS 2003. You must disable Logon Discovery for the test to succeed. Warning
Inactive Clients
Logon Client Installation Disabled
Error
Logon Discovery Disabled
Error
Logon points installed in Hierarchy
Verifies that no logon points are currently installed Error in the hierarchy. For the test to succeed, you must disable all logon points. Ensure that your logon scripts no longer call SMSls.bat. Instead, invoke capinst.exe with optional command-line switches in your logon scripts. Warning Multi-site assignment is unsupported in SMS 2003. During upgrade, a new Legacy Client removes all sites except the one that initiated client upgrade from its membership list if the client is within the boundaries of multiple sites. A Legacy Client automatically uninstalls if all site boundaries are removed, or if it moves out of the boundaries of its assigned site, unless travel mode is enabled. Verifies that there are no duplicate package IDs. Verifies that SMSExec is running on site systems such as the SMS site server and CAPs. Error Error
Multi-site assigned clients
Packages SQL constraint SMSExec is running
(continued)
Table 11.4 SMS 2003 Deployment Readiness Wizard SMS 2.0 Features Tests (continued)
Test name SMSExec Service crashes Information Verifies that no SMSExec service crashes have happened on the site server within the last 30 days. SMSExec service crashes are indicative of problems with site systems. Review the test results for more information. Failure type Warning
Site control file processing backlog
Verifies that site control file changes are being Error processed in a timely fashion. For the test to succeed, the site control file must not have more than four pending changes. Review the test results for additional information. SMS 2.0 programs using the Remove software when it is no longer advertised option, which uses the Uninstall registry key, do not work on the Advanced Client. Review the test results for additional information. Previous versions of software metering are not supported. For the test to succeed, you must remove SMS 2.0 software metering. For more information about removing legacy software metering, see Chapter 14,Upgrading to SMS 2003. Warning
Software Distribution: Uninstall registry key usage
Software metering site systems
Error
Upgrade Strategies
The upgrade strategies you choose directly affect how long an upgrade takes to complete, the effect on your network, and the fundamental structure of your SMS site hierarchy. Upgrade strategies are divided into two major categories described in this chapter: u u In-place hierarchy upgrades Side-by-side hierarchy upgrades
Because of the complex nature of SMS, most administrators plan to employ a mixture of upgrade strategies and other upgrade scenarios that best fit their needs. For example, some upgrade strategies are better suited for use when you do not want to modify any computer hardware used in your SMS sites. Other strategies are better suited to accommodate computer hardware changes during the upgrade process. As a part of your upgrade plan, reconsider your SMS objectives and determine the effect of the upgrade.
Upgrade Strategies 405
You are not limited to use a single upgrade strategy. Depending on the complexity of your SMS site hierarchy, you can decide to use elements of both in-place and side-by-side upgrade strategies. As the SMS administrator, you are in the best position to determine which upgrade strategy or combinations of strategies are best for your organization. After reading this chapter you will understand the requirements, options, advantages, and disadvantages for each upgrade strategy.
Reconsider SMS Objectives During Upgrade Planning

Carefully examine whether there were significant business changes affecting SMS since your last deployment. For example, the geographical profile of your organization might have changed. Perhaps changes to your site boundaries are required. When planning for your upgrade, determine if other changes to your SMS hierarchy are required. For more information about planning for business objectives, see Chapter 7, The Pre-Planning Phase, and Chapter 10, Planning Your SMS Deployment and Configuration.
Determine the Effect of the Upgrade

Is your existing SMS site hierarchy too large to upgrade overnight? One way to determine if your site is too large to upgrade directly to SMS 2003 is to recall how well the SMS 2.0 SP4 upgrade was achieved. If you had insufficient network bandwidth for upgrade, or if you had numerous difficulties, then use a phased-site upgrade strategy. A phased-site upgrade pertains to a single site only and it prevents all clients in the site from upgrading at the same time. Other sites within the SMS hierarchy are not affected by the phased-site upgrade. Alternatively, if there were few or no problems with your network when you upgraded your clients to SMS 2.0 SP4, or if network performance degradation was within acceptable limits, then you can perform an overnight upgrade. You must consider whether computers are shut down at night. If all the computers in your organization are shut down, the computers begin upgrading when they start up. A large number of clients upgrading simultaneously might overload your network. Performing a phased-site upgrade over a weekend prevents users from being negatively affected by the upgrade. Consider the amount of time needed to upgrade. For example, upgrading a site might take a long time if you have a large SMS site database. To help ensure your upgrade is completed as quickly as possible, fully plan the upgrade and consider the amount of time required for the upgrade to complete as a factor to weigh. In a test lab, you can use Network Monitor to help determine your expected available network bandwidth. The amount of available network bandwidth is an important factor used to help determine how many clients you can upgrade over a given period of time. You should test the SMS site database upgrade on a copy of the SMS site database with the /testdbupgrade Setup switch. For example:
Setup.exe /testdbupgrade SMS_<sitecode>
When you successfully run the database upgrade test, then you are assured the database portion of the upgrade process will be successful. You can review the results of the test in SMSsetup.log, which is in the root of the system drive.
Caution
Because the /testdbupgrade Setup switch destroys data, ensure that you use this setup option only on a copy of your SMS site database.
In-Place Hierarchy Upgrades

Most of the upgrade strategies described in this section use a holding site. A holding site is an SMS 2.0 site that holds clients that are not supported by SMS 2003. Clients running Windows 95, that are from other sites in your hierarchy, migrate to the holding site. A holding site is only effective when it manages clients in one geographical location. To establish a holding site, you can continue using an existing SMS 2.0 site, or you can create a new SMS 2.0 site server. The alternative to establishing a holding site is to not manage unsupported clients. If computers running unsupported operating systems, such as Windows 95, make up the fewest number of client computers, it might be best to conduct an in-place upgrade. An in-place upgrade refers to a site being upgraded with relatively little change to existing hardware. If you have a deep SMS hierarchy, you can create an SMS 2.0 holding site and migrate the clients running Windows 95 to the holding site. Then upgrade your other sites to SMS 2003 and their clients to your preferred client type. For additional information about deep hierarchies, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Overnight Upgrade
This in-place hierarchy upgrade strategy helps you upgrade your entire SMS hierarchy overnight. By performing an overnight upgrade, your organization can quickly benefit from SMS 2003. With this strategy, you upgrade all of your existing SMS 2.0 clients to the Legacy Client. This requires that you have ample available network bandwidth for the upgrade to complete in 23 hours. To start the overnight upgrade, choose a site to upgrade in the hierarchy to SMS 2003. Within 23 hours, your entire SMS 2.0 site is upgraded. Alternatively, you might choose to upgrade your site over a weekend if client computers are left on and are connected to the network. In this case you can schedule the site upgrades for a Friday evening. This can prevent heavy network usage from affecting your users and allow ample time for each Client Configuration Installation Manager (CCIM) cycle to fully complete. After all of your clients have upgraded to the Legacy Client, you can determine which clients should be replaced with the Advanced Client.
When an Advanced Client replaces an SMS 2.0 client, the first site the SMS 2.0 client was assigned to is used as the Advanced Clients assigned site, unless the site code is specified during client installation. When an Advanced Client replaces a Legacy Client, the Legacy Clients assigned site is used as the Advanced Clients assigned site, unless the site code is specified during client installation.
Note
If you have SMS 2.0 clients that cannot upgrade to the SMS 2003 client, you must establish a holding site. Otherwise, you are not able to manage the clients that cannot upgrade.
Performing an overnight upgrade has the following benefits: u u u u u An overnight upgrade is the fastest and easiest way to upgrade to SMS 2003. This strategy simplifies the upgrade process because you can address replacing Legacy Clients with the Advanced Client after the overnight upgrade is completed. Your organization can start using SMS 2003 without having to first establish Advanced Client infrastructure, such as management points. You do not have to spend a lot of time performing exhaustive planning before you take action. This strategy is attractive to you if you have not decided which SMS 2003 client to install on a given computer type.
Phased-site Upgrade
A phased-site upgrade is an in-place site upgrade strategy that uses the Client Upgrade Control tool to temporarily stop all clients within a site from being upgraded. During this process, batches of clients are upgraded in a controlled manner. As described in other examples, other upgrade mechanisms can be used in conjunction with a phased-site upgrade. Deciding to conduct a phased-site upgrade should be based on results you find in your lab test or a pilot project. If you are certain that your site infrastructure cannot adequately process all client requests to upgrade in a 23-hour period, then you can perform a phased-site upgrade. This allows you to upgrade your clients in smaller, isolated groups. Each client upgrade requires approximately 12 MB of network bandwidth. After your site server is upgraded to SMS 2003, the sites clients start upgrading. Client upgrade is triggered by either a Client Configuration Manager (CCM) cycle, which occurs every 23 hours on each client, or when a client computer logs on to a domain. If your site is small enough, and you estimate that a 12 MB download for each client cannot not overload the site CAPs, then an overnight upgrade might be the best upgrade strategy for you. Otherwise, a phased-site upgrade might be appropriate. This section provides general information about how to perform a phased-site upgrade. More detailed information about site and client upgrades is provided in Chapter 14, Upgrading to SMS 2003, and Chapter 4, Understanding SMS Clients.
You can perform a phased-site upgrade using one of the following methods: u u u Use the Client Upgrade Control tool with the /Enable switch. Use Client Push Installation with collections on clients running Windows 2000 or later to deploy the Advanced Client. Use software distribution to deploy the Advanced Client.
Using the Client Upgrade Control Tool

The Client Upgrade Control tool (Cliupgrade.exe) is used to conduct a phased-site upgrade of SMS 2.0 sites. The Client Upgrade Control tool is included on the SMS 2003 product CD and is found in \SMSSETUP\BIN\I386. Using the Client Upgrade Control tool with this strategy slows the upgrade process, which ensures that you have sufficient time to upgrade your clients. You can use the Client Upgrade Control tool to help upgrade some or all of your SMS 2.0 clients to the SMS 2003 Advanced Client. If you have a smaller site, you might send the tool through software distribution to disable only the clients that can support the Advanced Client. In this case, you can send the Client Upgrade Control tool with the /Disable switch to client computers running Windows 2000 and later, and then upgrade the SMS site server. If you take no further action, only computers running Windows 98 and Windows NT 4.0 upgrade automatically to the SMS 2003 Legacy Client. Later, by using either software distribution or Client Push Installation, you target computers running Windows 2000 and later to install the Advanced Client.
Note
Using the Client Upgrade Control tool might not be suitable for use with SMS 2.0 dial-up clients in support of suppressing automatic client upgrade, because many dial-up clients might not run the advertisement before your planned upgrade begins. If you use the Client Upgrade Control tool to prevent clients from automatically upgrading, ensure that you allow ample time for all dial-up clients to receive and run the advertisement.
The Client Upgrade Control tool prevents many normal client functions, so timing their upgrade is critical. The tool stops the CCIM cycle from occurring. After you upgrade a site server, you should upgrade its clients as soon as possible. After you run the tool, you cannot upgrade the SMS 2.0 clients to a newer version of SMS 2.0, such as a service pack or a security patch. You cannot change client settings, or change the hardware inventory schedule. Clients affected by the Client Upgrade Control tool that report to an SMS 2003 site do not run software inventory or retrieve collected files. For example, if you realize that a critical security patch must be applied to your SMS 2.0 clients, you cannot deploy the patch until the SMS 2.0 clients receive the /Enable switch. SMS 2.0 clients that are prevented from upgrading with the tool do not automatically upgrade to the SMS 2003 Legacy Client. To minimize this disadvantage, plan your upgrade strategy thoroughly before you distribute the Client Upgrade Control tool. Use the following basic procedure as a guideline only. It demonstrates the hierarchy-upgrade process using a phased-site upgrade strategy in the context of a single site. Upgrade your site hierarchy in a top-down manner. You upgrade a site only after its parent site has already been upgraded, starting with the central site.
To upgrade a site, you must use an account that is a member of the local Administrators group on the site server. By default, members of the Domain Admins group are members of the local Administrators group.
To perform a phased-site upgrade

1. Upgrade the central site server to SMS 2003. It is unlikely that the central site has enough clients, if any, to warrant a phased-site upgrade. Your site might differ.
Note
The Deployment Readiness tool runs during the upgrade. Logon points must be removed from all the sites in your hierarchy before the upgrade proceeds. For more information, see Chapter 14, Upgrading to SMS 2003.
2.
Send the Client Upgrade Control tool to every client in each site to be upgraded using SMS 2.0 software distribution with the /Disable command-line switch to disable clients from upgrading. Upgrade the first site server to SMS 2003. Determine the collection that you want to target clients to upgrade. Choosing the collection to advertise to determines how large the set of clients to upgrade is. Send your chosen collection the Client Upgrade Control tool with the /Enable switch through software distribution. This allows clients to upgrade. After members of the collection receive the tool with the /Enable switch, they upgrade to the SMS 2003 Legacy Client during their new CCM cycle, or when a user logs on, whichever occurs first. Verify that an acceptable number of clients have been upgraded, and then send the enabling switch to the next collection. Repeat this step until all the clients in the site have been upgraded. Repeat this process to upgrade each site in your hierarchy.
3. 4. 5. 6.
7.
8.
Overlapping Site Boundaries

Overlapping your site boundaries is necessary to ensure that clients running Windows 95 migrate from their original site to a holding site. However, if you overlap the boundaries of too many sites to your holding site, the holding site might not support all the clients. This results in serious site performance degradation.
Note
The process of overlapping site boundaries is used to facilitate client migration only. After all the SMS 2.0 clients finish migrating, you should remove any overlapping site boundaries.
Additionally, if a management point determines that an Advanced Client falls into the boundaries of multiple sites, the management point returns the distribution points of the multiple sites, and the Advanced Client selects one randomly. This might cause the Advanced Client to use a remote distribution point even though a local distribution point is available.
Example Scenario 1
Before beginning a phased-site upgrade, the SMS administrator should determine approximately how many clients the holding site might contain. In this example scenario, there are a variety of client operating systems, including Windows 95, in the SMS site hierarchy. The administrator has decided to upgrade as many sites as he can to SMS 2003. This scenario only works well in a deep hierarchy where all sites are in the same geographical location and they are not connected by wide area networks (WANs). After reviewing his current hierarchy, the administrator has decided to create a new site, D, to act as the SMS 2.0 holding site. The administrators goal is for all clients, running Windows 95 and Windows NT 4.0, to move to the holding site, and then upgrade sites B and C to SMS 2003.
Figure 11.1 First example of a phased-site upgrade

Primary Site A Central Site Upgrades to SMS 2003
Primary Site B SMS 2.0
Primary Site C SMS 2.0
Primary Site D New SMS 2.0 Holding Site
The administrator wants to upgrade sites B and C while all client computers remain managed. A fast, reliable network connects all sites. One client is running Windows 95 and is a member of site B. The other client runs Windows 2000 and is a member of site C. To upgrade the computers supported by SMS 2003 and move the others to a holding site, the administrator: 1. 2. Upgrades central site A to SMS 2003. Creates the SMS 2.0 holding site D.
3.
Adds the site boundaries for sites B and C to site D. This overlaps the site boundaries and ensures that SMS 2.0 clients that are unsupported by SMS 2003 remain managed during the upgrade process. Upgrades site servers B and C to SMS 2003. Clients temporarily remain members of their original sites and become members of site D. a. The upgrade begins when a client, that is running Windows 95, runs its CCIM cycle, or when a client, that is running Windows 95, runs Logon Script-initiated Client Installation (capinst.exe) from site B during logon. The upgrade process detects that the client operating system is not supported by SMS 2003. The client removes the SMS 2003 site codes from its site code list. The SMS 2.0 holding sites site code remains in the client site code list. The client is now a member of site D only. The upgrade begins when the Windows 2000 client runs its CCIM cycle, or when the client runs Logon Script-initiated Client Installation during logon from site C. SMS notifies the client that a newer version of SMS is available and client upgrade begins. Because site C initiated the client upgrade, the client becomes a member of site C. However, the client is a member of more than one site and SMS 2003 supports membership to one site only. Site D is removed from the clients site membership list automatically. Both clients are now members of only one site each. The administrator waits until all clients have either upgraded or changed site membership before proceeding.
4.
b.
5. 6.
Repeats steps 3 and 4 to upgrade clients for each site in the hierarchy, until all sites have been upgraded. Maintain the overlapping boundaries until there are no more clients running Windows 95, or until you no longer need to support clients running Windows 95.
Example Scenario 2
The hierarchy is in one geographic location. A fast, reliable network connects all sites. After reviewing his current hierarchy, the administrator has determined that: u u One-quarter of his client computers are running Windows 95. These clients reside in various sites within the hierarchy. The remaining client computers are running Windows NT 4.0 SP6a and Windows 2000. The administrator wants to continue using his existing SMS hardware to manage these clients. He wants to upgrade these clients to the Legacy Client. They reside in various sites within the hierarchy. Site B is an SMS 2.0 site. The administrator does not plan to upgrade this site, because it will become a holding site. Site C will be upgraded in-place to SMS 2003.
u u
Figure 11.2 Second example of a phased- site upgrade

Primary Site A Central Site Upgrades to SMS 2003
Primary Site B SMS 2.0 Holding Site
Primary Site C Upgrades to SMS 2003
Primary Site D New SMS 2.0 Transition Site
The administrator: 1. 2. 3. 4. 5. Upgrades central site A in-place to SMS 2003. Creates a server locator point at central site A. Creates site D, a new SMS 2003 transition site. Creates a management point at site D. Adds the site boundaries for site C to site B. Site B is not upgradedit is the SMS 2.0 holding site. This overlaps the site boundaries and ensures that SMS 2.0 clients that are not supported by SMS 2003 remain managed during the upgrade process. Upgrades site server C to SMS 2003. Clients temporarily remain members of their original site C, and become members of site B. a. The upgrade begins when a client, that is running Windows 95, runs its CCIM cycle, or when a client, that is running Windows 95, runs Logon Script-initiated Client Installation from site A during logon. The upgrade process detects that the client operating system is not supported by SMS 2003. The client removes the SMS 2003 site code from its site code list. The upgrade process ends without the client being upgraded. The SMS 2.0 holding sites site code remains in the client site code list. The client is now a member of site B only.
6.
b.
The upgrade begins when any client, that is running Windows NT 4.0 SP6a or Windows 2000, runs its CCIM cycle, or when the client runs Logon Script-initiated Client Installation from site A during logon. SMS notifies the client to communicate with the CAP at site C. The CAP at site C notifies the client that a newer version of SMS is available. SMS 2.0 clients upgrade to the Legacy Client. Because site C initiated the client upgrade, the client becomes a member of site C. However, the client is a member of more than one site and SMS 2003 supports membership to only one site. Site B is removed from the clients site membership list automatically.
7.
At each site, use a collection to target and send the Advanced Client Windows Installer package to computers running Windows 2000. SMS 2.0 client software is replaced by the Advanced Client on computers running Windows 2000 and become members of site D. Removes the site boundaries of sites C from site B when there are no more clients running Windows 95 to manage.
8.
Interoperability During Upgrade

You might plan to upgrade only some of your SMS 2.0 sites, to continue to support clients that SMS 2003 does not support. For example, to continue to support clients running Windows 95, you must maintain SMS 2.0 sites within your SMS 2003 site hierarchy until those clients are upgraded. You must follow these guidelines when planning the upgraded hierarchy: u A parent site must be either the same version as, or one version later than, the child site. For example, an SMS 2003 site can be a parent site of another SMS 2003 site, or of an SMS 2.0 site. You must organize the site hierarchy so that SMS 2003 sites report to other SMS 2003 sites only. SMS 2.0 sites can report to other SMS 2.0 sites or to SMS 2003 sites. Before starting any site upgrade, apply SP4 or later to SMS 2.0 sites that will share a hierarchy, even temporarily, with SMS 2003 sites.
The order of the upgrade is the same whether you plan to upgrade all the sites or not. To maintain the reporting structure during a phased deployment of SMS 2003, you must upgrade the central site first. Then, upgrade the central sites immediate child sites. Continue down the hierarchy until you reach the SMS 2.0 sites that you do not want to upgrade.
Side-By-Side Hierarchy Upgrades

A side-by-side migration occurs when new hardware is used, or when you reconfigure existing computer hardware in conjunction with changes to your SMS site hierarchy or the upgrade process. A side-by-side migration typically requires much more planning to ensure that all clients remain managed during the migration than an in-place upgrade does. Ensure that you and your organization are fully prepared before beginning the migration.
A side-by-side migration offers significant benefits that other upgrade strategies cannot. For example, with a side-by-side migration, you can: u u u u Use new hardware and revise your existing hierarchy. Continue using existing hardware, if desired. Limit the number of client types in your sites. Rearrange sites and clients within the SMS site hierarchy.
Note
Clients do not have to remain members of their original SMS 2.0 sites after they upgrade. For example, if you have two SMS 2.0 sites, one of which is not being fully used, you can migrate its clients to another site then remove the unused site.
Using a Transition Site

If you are considering a side-by-side migration, determine what the client composition of your hierarchy is. If your most demanding SMS users are those who have the most up-to-date computers, but they only consist of 20 percent of your hierarchy, then you probably do not want upgrade your entire hierarchy to SMS 2003 to accommodate only those computers. In this case, you might want to establish a transition site in your existing hierarchy, and then migrate the client computers to the transition site. A transition site is an SMS 2003 site that manages clients that cannot be members of SMS 2.0 sites. In other words, a transition site is an SMS 2003 site that holds only SMS 2003 clients. To establish a transition site, you can upgrade an existing SMS 2.0 site to SMS 2003, or you can create a new SMS 2003 site server. Using a transition site might ensure that your most demanding users receive the benefits of SMS 2003 quickly. For example, you can deploy Advanced Clients and still keep old SMS 2.0 sites and clients. Because the Advanced Client is more scalable than the Legacy Client, you can have many more Advanced Clients at a single site than Legacy Clients, and you can use multiple management points instead of multiple CAPs to handle the clients. Later, you can use other strategies to upgrade other sites and upgrade or migrate their clients.
Restricting Client Installation

Any site upgrade within an SMS hierarchy might temporarily result in having three different clients: u u u The SMS 2.0 client The SMS 2003 Legacy Client The SMS 2003 Advanced Client
Based on the business needs of your organization, you might decide that you do not want to manage three different client types. In this case, you might purposely avoid migrating your SMS 2.0 clients to one of the SMS 2003 client types. For example, you might decide that all clients running Windows 2000 or later must run the SMS 2003 Advanced Client. All other client computers must continue to use the SMS 2.0 client. In this case, you avoid upgrading any clients to the Legacy Client and you keep your holding site at SMS 2.0 indefinitely. This scenario is acceptable if it meets your organizations business goals. In this example, you continue managing your SMS 2.0 hierarchy and upgrade the central site and one primary site, which becomes a transition site. All other sites remain SMS 2.0 holding sites, temporarily. Then you identify clients from the hierarchy that can run the Advanced Client. You migrate those clients to the SMS 2003 transition site. When the transition site reaches its capacity in terms of adequately supporting all assigned clients, you can create or upgrade another holding site. This allows you to continue migrating more clients, which slowly offloads work from your SMS 2.0 sites while the SMS 2003 sites grow. This strategy ensures that all clients are managed during the upgrade. You can also use the new features of SMS 2003 during your site migration, until the process is complete. When your SMS 2.0 sites are no longer required, you can remove them from your hierarchy.
Deciding When to Upgrade a Flat Hierarchy

If you have a relatively flat SMS hierarchy that contains clients that cannot run SMS 2003, such as computers running Windows 95, you should accelerate plans to upgrade those computers to newer hardware and operating systems that SMS 2003 supports. Because the SMS clients are separated from the primary site by WAN links, you cannot centrally manage the clients using a holding site. After you upgrade or replace the client computer operating systems at a secondary site, you can upgrade the secondary site server to SMS 2003.
Note
A flat hierarchy contains fewer tiers than deep hierarchies and makes the hierarchy easier to configure, administer, and support. SMS needs less time to deploy software to lower level sites and report status back to the top of the hierarchy.
This might or might not be acceptable in your organization. Consider the following: u u u Proportion of the overall client base to the non-supported clients Functions within your enterprise of the non-supported clients Length of time before retiring the non-supported clients
The alternative to upgrading clients to operating systems supported by SMS 2003 is to create a new holding site at every separate geographical location. This avoids having sites with clients on the other side of WAN links. For additional information about flat hierarchies, see Chapter 8, Designing Your SMS Sites and Hierarchy.
However, if you are required to maintain some client computers running Windows 95 indefinitely, you cannot upgrade those clients right away. Instead, you should wait to upgrade your SMS client software until you have upgraded your operating system to one supported by SMS 2003. A phased-site upgrade is not practical. Additionally, creating a holding site at each secondary site location can be very expensive. You should to wait to upgrade your hierarchy until you have planned for and received new computers that can run SMS 2003. The limiting factor is that WAN links are typically slow or unreliable, and you cannot schedule network traffic to distribution points with senders.
Upgrading Secondary Sites

When you upgrade a primary site that has secondary sites, the primary sites roaming boundaries are populated with the site boundaries of its secondary sites. This is because Advanced Clients cannot be members of secondary sites. Later, if you replace the SMS 2.0 client with the Advanced Client at secondary sites, the clients do not become orphaned. Although Advanced Clients cannot be members of secondary sites, they can use proxy management points at secondary sites for most purposes. For more information about roaming boundaries, see Chapter 2, Understanding SMS Sites.
Replacing Secondary Sites with Protected Distribution Points

If you have an SMS site hierarchy with few primary and secondary sites, you might consider migrating the hierarchy to a few large primary sites, and eliminating secondary sites. You can do this by replacing secondary sites with protected distribution points. By removing secondary sites, you lose the ability to control network traffic across a WAN connection between the parent site and secondary sites. If the primary purpose of establishing secondary sites was to control network traffic across a WAN, then you should not remove your secondary sites. Conversely, your original purpose of establishing secondary sites might be to comply with service level agreements (SLAs) requiring different site settings for SMS components. If you are confident that you can adequately meet SLAs and other SMS objectives without secondary sites to share the workload of the parent primary site, then consider replacing the clients at a secondary site with Advanced Clients assigned to the parent site. Establishing protected distribution points minimizes network traffic from clients outside of the boundaries configured for the protected distribution points. Advanced Clients within the boundaries configured for a protected distribution point use it to receive software distribution packages.
By removing secondary sites, you remove the burden of managing them, and your primary sites become larger and more complex. For more information about protected distribution points, see Chapter 2, Understanding SMS Sites.
Note
If a protected distribution point becomes unavailable, Advanced Clients retrieve software distribution packages from other distribution points in the site.
Before removing a secondary site, determine whether it is small enough to warrant removal. You should conduct a network traffic comparison of how much network traffic it generates as a secondary site vs. how much network traffic proposed Advanced Clients might generate. Client network traffic is primarily generated by: u u u u The number and size of software distribution packages. The frequency of Advanced Client policy updates. How much inventory is reported. How much software metering information is sent by the clients.
For more information about capacity planning, see Chapter 9, Capacity Planning for SMS Servers in the Microsoft Systems Management Server 2003 Operations Guide. In this case you plan to: 1. 2. Upgrade the parent primary site to SMS 2003. Replace the SMS 2.0 client with the Advanced Client through software distribution, or with the Client Push Installation Wizard. Through this process, you migrate the secondary site SMS 2.0 clients to the primary site. Remove the SMS 2.0 secondary sites after all clients have migrated to the parent site. Establish protected distribution points where the secondary sites used to be.
3. 4.
Replacing Multisite Clients

SMS 2003 clients cannot be assigned to multiple sites. Plan to install the Advanced Client on computers that roam to other SMS sites and when roaming clients require SMS services while visiting sites away from their assigned site. You can use a number of migration strategies detailed later in this chapter to help migrate your SMS 2.0 multisite clients to the Advanced Client. The Advanced Client uses efficient methods to communicate with the site it is assigned to. The client can also use locally available distribution points to access packages. When distribution points are not local, the Advanced Clients use of Background Intelligent Transfer Service ensures that package downloads do not adversely affect the users use of the computers network link.
The SMS 2003 clients lack of multisite assignment is beneficial in the following ways: u u u u Consistency with the operating systems assignment of computers to a single Active Directory site. Simplified client configuration troubleshooting. Individual client data is not stored in multiple branches of your SMS hierarchy. Clients contacting multiple sites do not consume network capacity.
Note
If a multisite SMS 2.0 client upgrades to the SMS 2003 Legacy Client, the client automatically removes all sites from its assigned sites list except for the site that initiates the client upgrade.
If you use multisite assignment for your SMS 2.0 clients, reconsider your procedures in the following circumstances:
Site coexistence
Two sites cannot exist at one location and manage the same clients. You must merge the two sites into one. You can use collection-level security to separate responsibilities, or the SMS administrators at one of the sites must stop managing clients.
Loss of redundancy
If you have clients assigned to multiple sites to ensure that the clients remain managed when one site is not available, you must consider alternative approaches. For example, you can use a parent site to manage clients at a child site. Or, you can refine your backup and recovery procedures to help ensure that if a site fails, it is recovered quickly.
User support from multiple help desks

Personnel at the help desks must revise their procedures when clients are assigned to multiple sites to allow the help desks to use the SMS database of their local site to find clients and remotely control them or to view client inventory details. The help desks must also revise their procedures when each local site distributes advertisements to the clients. Some alternatives include: u u Have each help desk use a remote SMS Administrator console to connect to home site of the users, or to the central site to administer a client. Change the client site assignment whenever the clients change sites.
Upgrading Clients by Attrition

If you have a small number of client computers running Windows 95, you can replace these clients through a process of attrition. Attrition does not directly upgrade clients. It purposely orphans them. If you consider this approach, you should determine whether the percentage of unsupported clients in your organization is small enough to leave unmanaged by SMS. This strategy is appropriate if the cost of maintaining a mixed-version hierarchy is too great for the small number of unsupported clients.
You should consider this strategy if you decide to replace or upgrade the computers running Windows 95 in a short period of time. The benefit of this approach is that you can upgrade your site and its clients directly to SMS 2003, without maintaining an SMS 2.0 site to manage the clients that are not supported by SMS 2003. When problems occur one of these older computers, you should then replace the computer. This plan also works well if you have already procured replacement client computers. Over time, you replace all your legacy computers with computers that run an SMS 2003 client.
Finalizing Your Upgrade Plan

After you determine which upgrade strategies to employ, you should finalize your upgrade plan. Many of the activities you must consider are similar to those described in Chapter 10, Planning Your SMS Deployment and Configuration. At a minimum, you should: u u u u u Document your upgrade plan. Create and schedule a backup and recovery plan. Schedule your upgrade resources. Schedule the upgrade to occur after hours. Prepare your users for the upgrade.
Post-upgrade Migration Planning

After planning the strategy for upgrading your SMS hierarchy, you must plan for features you want to use in SMS 2003. You must determine if your SMS 2.0 clients use features that are not supported SMS 2003. You also must determine if there are any requirements you must meet for new SMS 2003 features.
Unsupported SMS Features and Platforms

The following features are not supported in SMS 2003. For more information, see Chapter 6, Understanding Interoperability with SMS 2.0.
Novell NetWare
SMS site systems running on Novell NetWare must be removed manually. Novell NetWare clients are orphaned during upgrade. If you use IPX site boundaries at SMS 2.0 child sites of SMS 2003 parent sites, you cannot use server-locator-based client installation to install clients at the SMS 2.0 sites. You must continue using SMS 2.0 client installation methods at SMS 2.0 sites, such as Manual Client Installation.
Post-upgrade Migration Planning 421
IPX site boundaries

Clients that are x86-based computers, use IPX as their site boundary, and do not fall into any supported site boundary methods, will be uninstalled. Novell NetWare clients that use IPX as their site boundary and do not fall into any of the supported site boundary methods are orphaned during upgrade.
Alpha-based systems
Alpha-based clients are orphaned during upgrade. Remaining files used to support Alpha clients can be manually removed from the site server after upgrade.
Crystal Reports
Crystal Reports can be uninstalled prior to upgrading to SMS 2003. Use Add or Remove Programs in Control Panel to complete this task. See Chapter 14, Upgrading to SMS 2003, for more information.
Logon discovery
Windows Networking Logon Discovery is not included as a discovery method in SMS 2003.
Logon installation
In SMS 2003, computers can still be installed when users log on. This can be accomplished with Logon Script-initiated Client Installation. For more information about client installation see Chapter 17, Discovering Resources and Deploying Clients.
Logon points
SMS 2003 does not support logon points on the domain controller.
Legacy software metering

Software metering is now fully integrated with SMS 2003. Previous versions of software metering are not supported. For more information about removing legacy software metering, see Chapter 14, Upgrading to SMS 2003.
SNMP Event to Trap Translator

This feature is natively supported in Windows 2000 and later operating systems.
SMS 2003 Features

While you are planning your upgrade, you should consider the new features that SMS 2003 provides, and features that have changed from SMS 2.0. New features might require decisions that influence how you perform your upgrade. Changes to SMS 2.0 features in SMS 2003 might also require consideration.
Active Directory schema extension

During an SMS 2003 upgrade, you do not have the option to extend the Active Directory schema. However, you must extend the Active Directory schema if you plan to implement automatic site assignment using Active Directory or roaming boundaries for Advanced Clients. You must also extend the schema to use public key exchange available with SMS advanced security. You can extend the Active Directory schema after an upgrade using the ExtADSch.exe tool, provided you have the proper rights. For information about using ExtADSch.exe to extend the schema after upgrading to SMS 2003, see Chapter 15, Deploying and Configuring SMS Sites.
Active Directory site boundaries

Active Directory site boundaries are configured after upgrading to SMS 2003. After upgrading, consider migrating to Active Directory site boundaries. Although you can use Active Directory site boundaries to define boundaries for your site, careful planning is required. For more information about planning, utilizing, and migrating to Active Directory site boundaries, see Chapter 2, Understanding SMS Sites, and Chapter 8, Designing Your SMS Sites and Hierarchy.
Advanced security
For SMS to use Advanced Security, SQL Server 2000 must already be present on the site server to upgrade. To use Advanced Security, you must first complete your upgrade, be a part of an Active Directory forest on a computer running Windows 2000 SP2, or later, and then implement Advanced Security. For more information about Advanced Security, see Chapter 5, Understanding SMS Security.
SMS Reporting
If you have previously used the SMS 2.0 Web Reporting tool, all custom reports you have created are removed when you upgrade to SMS 2003. However, you can export your report object definitions to MOF files for use in SMS 2003. For more information about using reports, see Chapter 11, Creating Reports, in the Microsoft Systems Management Server 2003 Operations Guide.
SMS 2.0 hardware inventory customization

SMS 2.0 hardware inventory customizations are not migrated when you upgrade to SMS 2003. You must manually include those customizations in the SMS_def.mof file that is created during the upgrade process. For example, in SMS 2.0, classes that were registered in the cimv2\sms namespace are registered in the cimv2 namespace in SMS 2003. You can avoid losing the data from your hardware inventory customizations by disabling the hardware inventory client agent before beginning the site upgrade. For more information about how SMS_def.mof is preserved during upgrades, see Chapter 2, Collecting Hardware and Software Inventory, in the Microsoft Systems Management Server 2003 Operations Guide.
Post-upgrade Migration Planning 423
If you plan to maintain a mixed-version hierarchy, consider using a standard SMS_def.mof throughout your hierarchy. Differences between the SMS_def.mof files at different sites in the hierarchy can lead to conflicting hardware inventory data. To prevent conflicts, ensure that each site in the hierarchy uses the same hardware inventory definitions. For more information about how to standardize the SMS_def.mof files in your hierarchy, see Chapter 6, Understanding Interoperability with SMS 2.0.
Note
If you implemented your SMS 2.0 hardware inventory extensions without changing the SMS_def.mof, then adjust those extensions so that the reporting classes are included in the SMS_def.mof. The data class definition and population can still be done in your customization.
Software inventory customization

When you upgrade a site, customized inventory names are migrated to SMS 2003 and default inventory collection names are installed. If you have previously removed any default inventory collection names, the collection names reappear in Software Inventory Client Agent Properties after the upgrade.
C H A P T E R
1 2
Planning Your SMS Security Strategy

Security issues affect all aspects of computer operations and affect the design and implementation of your Microsoft Systems Management Server (SMS) hierarchy. It is essential that you develop a security strategy before you install SMS to minimize the risk to the integrity and security of the information in your site. This chapter builds on the security concepts that were introduced in Chapter 5, Understanding SMS Security, and provides a framework to develop an SMS security strategy.
In This Chapter
u u u u u u SMS Security Planning Task List Planning SMS Accounts Planning SMS Object Security Planning SMS Feature Security Planning to Use SMS Security Testing SMS Security
426 Chapter 12 Planning Your SMS Security Strategy
SMS Security Planning Task List

Security planning is the next step after planning your hierarchy, sites, and deployment strategies. With the information from those stages in hand, you can focus on issues that are relevant to your needs and make decisions based on relevant facts. If you are upgrading from a previous version of SMS, you might already have an SMS security plan. The particular issues and order can vary, but generally, planning SMS security involves the following steps: 1. Become well educated on security issues and details, including general security, security for systems that SMS relies on, and SMS security in particular. Reading Chapter 5, Understanding SMS Security, is central to this task, but reading other security documentation is also recommended. For more information, see www.microsoft.com/security. 2. 3. Review the issues outlined in the General SMS Security Planning Considerations section later in this chapter. Review the security in your organization for the technologies that SMS relies on. Document the current state and review whether improvements are necessary in order to ensure SMS security. Consider the security-related issues that affect your SMS site and hierarchy design. For example, when you plan your SMS site and hierarchy design, you should decide on the initial security mode for each SMS site. The number of SMS sites, SMS site systems, SMS clients and client types can influence security choices that you make. Later sections in this chapter address many design issues that also affect SMS security. Plan account creation and maintenance, and consider account minimization. See the Planning SMS Accounts section later in this chapter. 6. 7. Plan client management rights, and possibly plan initial collections and assignment of rights. See the Planning SMS Object Security section later in this chapter. Plan other object rights, such as site security, so that SMS is managed and administered securely. See the Planning SMS Object Security section later in this chapter. 8. 9. Plan SMS feature security, so that SMS data is secure. See the Planning SMS Feature Security section later in this chapter. Develop your security policies and procedures for ongoing security maintenance and monitoring.
4.
5.
SMS Security Planning Task List 427
10. Develop contingency plans. If someone found a hole in your security plan and gained limited or full control of SMS, how could they use it adversely? How would you stop those kinds of problems to minimize the damage? Effective monitoring can allow you to detect the problem early, and good contingency plans can allow you to stop the problem quickly. 11. In detail, review the security options and best practices described in Chapter 5, Understanding SMS Security, and decide which options are appropriate for your organization. 12. Document all of the above. 13. Test your SMS design with your security plan in place. Ensure that SMS continues to work properly with the changes required by your security strategy. If SMS does not work properly, use alternative changes that achieve the same security affects. 14. Test your SMS security to ensure that it defends SMS from the risks your organization is subject to. See the Testing SMS Security section later in this chapter. 15. Review your SMS security documentation with interested parties, such as other SMS administrators, security specialists, management, consultants, or domain administrators. 16. Adjust your plan if testing or discussions reveal that adjustments are necessary and then go back to step 13 (the documentation step). 17. Adjust your SMS deployment plan to include the steps to implement the security changes required by your security strategy. This should include: u u u u u u When to create the accounts or adjust groups. When to join sites to the hierarchy (when to enable unsigned site connections, if necessary). When to stop joining sites to the hierarchy (disable unsigned site connections). When to implement SMS object security. Or if you are upgrading from SMS 2.0, when to implement the changes for new SMS object security rights. When to implement SMS feature security details. When to secure the System Management Active Directory container when you create it.
SMS Security Checklist

At any time you can review the following checklist to ensure that you are considering the common security issues related to SMS. Use this checklist before planning your SMS deployment, during deployment, and on a routine schedule after deployment to ensure that you do not overlook key SMS security issues. Each implementation of SMS has different security issues and you must consider whether any additional issues apply to your environment that are not included in this checklist. To use this checklist effectively, you must have a full understanding of SMS security issues and techniques.
SMS Security Checklist 12.1

Task Review overall computer security, including sources of risk, physical security, your organizations security policies and procedures, and your network security. Review your implementation of security for technologies that SMS uses, including Microsoft SQL Server, operating systems (including domains), and other technologies outlined Chapter 5, Understanding SMS Security. Review your use of standard security and Legacy Clients to see if either can be removed from any sites. Benefit Helps you to better understand the environment your SMS implementation will exist in, and to understand the issues that SMS security must address. Helps you to further understand the environment your SMS implementation will exist in, but also allows you to adjust the security of specific technologies when it could benefit SMS security. Minimizes security considerations and administrative efforts.
Review your use of SMS connection, service, and Minimizes opportunities for future problems. special purpose accounts, where SMS does not Take advantage of the modular security model automatically manage them. of SMS, but do not make SMS administration too complex. Review who has access to your primary site at the Windows Management Instrumentation level (by using the SMS Admins group or similar accounts or groups). Review who has access to SMS objects at all primary sites, by using SMS class and instance security rights, as administered in the SMS Administrator console. Review access to software distribution shares. Review Remote Tools security. Review the security issues of your reporting solution. Review security issues related to your SMS Installer scripts. Also review the scripts and their availability. Review Network Monitor security. Assess the risk that unauthorized network monitor use might pose. Review your SMS security policies and procedures documentation. Ensures that only authorized individuals have appropriate levels of access to the SMS systems. Further restricts access to the SMS systems.
Ensures that users have access only to the software that they are authorized to access. Ensures that only authorized staff can remotely control appropriate client computers. Restricts access to sensitive system details. Ensures that there is no opportunity to expose security details that you do not want to expose. Restricting usage of this powerful tool ensures that it is not abused. Ensures that your documentation is current and complete.
(continued)
SMS Security Checklist 12.1 (continued)

Task Update your documentation of security settings and details, and review with relevant or interested parties. Test your SMS security, the monitoring and auditing processes, and contingency plans you have in place. Benefit Ensures that multiple people agree that the current security settings and details are appropriate for your organization. Helps to verify that your security plan works as intended and that security breaches would be caught and corrected quickly.
General SMS Security Planning Considerations

The following issues set some of the context for your SMS security planning. Analyze your environment in relation to each of these issues, and document the results for discussion and future reference.
Client lockdown level

Do you lock down client computers so that end-users cannot change the computer configuration or access files in specific directories? What are the specific details of your organizations lock down policy for clients? You must verify that SMS client security is sufficient to install and run the SMS client with your locked down clients. Testing is the best way to verify this.
Account policies
When and under what parameters do you lockout user accounts? Must the passwords be changed on a regular basis? There are several account policy options available, and many can be relevant to SMS security.
Simplicity
How important is simplicity to your organization? It is preferable to keep computer operation and support costs low, and to minimize the challenges presented to your technical staff. Strong security can add complexity and additional work. You must define a satisfactory compromise between simplicity and strong security for your organization.
Sensitivity to risk
How important to your organization is it that security not be compromised? A variety of factors can influence your sensitivity to risk, including your dependence on having computers running, the nature of the data being stored, and the general corporate culture. If your organization is very sensitive to security risks, then you must make significant effort to ensure SMS security is properly implemented and maintained. For example, a financial institution might have greater sensitivity to risk than a nongovernmental organization.
Nature of risks
You must become familiar with the nature of potential risks to your organization and their possible source. By knowing how SMS might be attacked, and in what general ways, you can work to ensure that appropriate safeguards are in place.
Control of accounts
Do the SMS administrators have control of the SMS accounts, or must they coordinate with security administrators? Do the SMS administrators have the passwords for the SMS accounts?
Administrator organization
How do you organize computer administrators? Are they centrally organized, with a common reporting structure, or are there groups of administrators located throughout the organization who might have different work methods? These factors can affect where you place SMS site servers and accounts and whether you have to secure SMS against other administrators.
Security Considerations for Site and Hierarchy Design

Security considerations might influence your need for and placement of SMS sites or site systems in the design of your hierarchy. Security considerations can be important when deploying clients. Security efforts should also be incorporated as early as possible in your deployment plan so that your SMS implementation is functional and secure. Security considerations for your site and hierarchy design include: u u u Issues across-forest trusts and issues across domains that might affect site or site system placement The SMS security mode for each site Client issues on domain controllers or other security-sensitive servers that might affect your plans for SMS clients on those servers.
Forest and Domain Issues

When designing the SMS hierarchy you might consider placing one SMS site in each domain or forest so that you can isolate all SMS accounts to that domain or forest. SMS activities between forests must be done from site to site, so you must have at least one SMS site in each forest. SMS must also have rights and permissions to the domains in order to perform discovery (if the relevant discovery methods are used) and to write configuration details to the SMS Active Directory objects, if used. To access Active Directory or domains, the site server computer account or SMS Service Account has to have only domain user credentials The most significant domain-related security issues are when SMS 2003 manages clients in multiple domains. In that case, additional accounts must be created so that the clients or site systems in the domains can communicate with the site systems or site server in other domains, respectively.
Selecting a Security Mode for Each Site

Whenever possible, you should use advanced security mode. Advanced security mode gives you the highest level of SMS security and the least amount of security maintenance work. However, your sites must meet the prerequisites for advanced security mode, as described in Chapter 5, Understanding SMS Security.
Your hierarchy can have a mix of advanced security mode and standard security mode sites. However, advanced security sites can report only to advanced security sites, so the first site that can run in advanced security mode is the central site. At each site, determine whether the site can be an advanced security site. If it cannot, then its direct and indirect child sites must be standard security sites. You can change standard security sites to advanced security sites in the future when the sites meet the advanced security prerequisites. To maximize the benefits of advanced security, consider using the following practices: u If possible, do not use Legacy Clients. Legacy Clients require a greater number of clientrelated accounts than Advanced Clients. You can also eliminate your client access points (CAPs), which removes one possible set of security attack targets. Use advanced security at all sites to take advantage of the use of computer accounts for network connections among SMS servers and SMS sites. Do not remotely install or uninstall secondary sites from the SMS Administrator console by using the Create Secondary Site Wizard so that the primary sites computer account or Site Address Account does not have to be a member of the local Administrators group of the secondary site server. Minimize the use of the local system account on the site servers and site systems by not installing other services that use the local system account. This ensures that other processes cannot take advantage of the enhanced privileges of the systems computer account, accessing SMS files and data through those other systems.
u u
SMS on Domain Controllers

Installing SMS servers or clients on domain controllers can affect your SMS security strategy by introducing additional risks or account replication dependencies. The best way to avoid this issue is to only use Advanced Clients on domain controllers. Advanced Clients run by using the local system account, so they have a unique security context from all other computers even on domain controllers, and there are no accounts or account changes that have to be replicated.
Security Considerations for Planning Setup

You might not have to consider SMS security issues as you set up SMS sites, site systems, and even clients. You might already have sufficient privileges to start the setup, and SMS might be able to use your privileges to complete the setup and start functioning. However, in some cases there might be additional security considerations for setup, and you might want to plan for those when you are developing your SMS deployment plan. Those considerations include the following: u You might not have domain administrator or comparable privileges, and you might not be able to get them.
Accounts might be needed for SMS to be functional with your site design. SMS automatically creates or uses accounts for most purposes as it is set up, so you might not have to create accounts as you initially set up SMS. For details about account planning, see the Planning SMS Accounts section later in this paper. The users or SMS might not have sufficient privileges to install the SMS clients using the client installation methods you plan to use.
Site Setup
If you have domain administrative credentials, or equivalent, then you will probably have full rights on the computer on which you are setting SMS, on the domain that the SMS site might try to use, and on computers that could serve as site systems or be managed as SMS clients. However, you might not have such comprehensive credentials, or you might want to ensure that SMS does not use accounts that have domain administrative credentials. You can still set up SMS 2003 in such circumstances.
Site System Setup

For SMS to create site systems on computers other than the site server, it must have administrative credentials on those computers. If the site server computer account (for advanced security) or the SMS Service Account (for standard security) is in the Domain Admins group, or a comparable group, then SMS might already have those privileges. If not, then those credentials must be granted. Making the site servers computer account or the SMS Service Account a member of the local administrators group of the SMS site system computer is recommended because the privileges are limited to a specific purpose.
Client Installation
Installing either the Advanced Client or the Legacy Client requires administrative credentials on the computers. Those credentials can be made available in several possible ways, each of which is appropriate for different client installation methods: u The users themselves might have administrative credentials on the computers they use. In this case those credentials can be used during logon if the client is installed as part of the logon script. Alternatively, the users can install the software from a share, a Web site, or similar source. You might have a domain or local account that has administrative credentials on all computers. That account can be used by Client Push Installation to install the clients. If such an account is not available, you can attempt to get an account that is a Domain User but is added to the local administrators group on all the client computers. You might have a software distribution method in place that has the ability to install software with administrative credentials. For example, you might want to change SMS 2.0 clients to Advanced Clients. In that case you can deploy the Advanced Client to those computers using software distribution.
Planning SMS Accounts 433
Planning SMS Accounts

The SMS Accounts and Groups section of Chapter 5, Understanding SMS Security, provides an overview of SMS accounts. SMS (or SQL Server) automatically creates almost all of the accounts required for basic site functionality when you perform the following tasks: u u u u Run SMS Setup. Assign specific site system roles. Enable specific SMS features. Install the SMS client software.
The number and type of accounts that SMS creates, depends on whether you are running standard security or advanced security, and whether you are supporting Legacy Clients or Advanced Clients. For more control over account management, you should consider using optional accounts wherever appropriate. And you must create accounts in the following circumstances: u u When you first set up a CAP for an advanced security site, you must create at least one Client Connection Account. If you set up additional CAPs at an advanced security site, and the original Client Connection Accounts are local to the original CAP, as recommended, then you must create additional Client Connection Accounts. If you use Client Push Installation to install the Advanced Client software, you must create an Advanced Client Network Access Account.
Using Optional Accounts

To enhance your SMS security and give you more control over the accounts that SMS uses, you can create the optional accounts that SMS allows. By creating these optional accounts and configuring SMS to use them, you keep the use of the SMS Service Account at a minimum when using standard security. The SMS Service Account is a highly privileged account that you might not want to propagate throughout your environment. Creating optional, less-privileged accounts helps to minimize the risk to all SMS processes when a single account is breached. The optional accounts are: u u u u u u u Site Address (for parent-child sites). SQL Server (so that sa is used only for system administration). Site System Connection. Legacy Client Software Installation. Client Push Installation. Additional Client Connection Accounts. Advanced Client Network Access.
SMS creates one Client Connection Account for each CAP by default, but to enhance security, site integrity, and fault tolerance, you must create additional Client Connection Accounts. Before you begin creating additional SMS accounts and implementing account management policies for them, ensure that you understand where to configure these accounts and which accounts can and cannot be changed. As mentioned in the SMS Accounts and Groups section in Chapter 5, Understanding SMS Security, SMS accounts that can be manually created and modified by an administrator must be created and modified in two locations not just the SMS Administrator console. Do not modify other accounts. In general, SMS accounts that are used by SMS server services provide more flexibility in administrator control than client accounts do, but there are exceptions. For information about SMS accounts that can be managed by an administrator, see the Creating or Modifying SMS Accounts section later in this chapter.
SMS Security Account Principles

The following principles are general guidelines about how SMS implements security. Each principle includes information that the SMS administrator should consider and a recommended best practice. Principle 1: All required SMS accounts can be automatically created. Automatically created accounts have automatically generated passwords that are encrypted, either by the operating system or by SMS. Implications for the administrator: The encryption of all automatically set SMS passwords and the random generation of SMS-created passwords maximizes security because it results in very strong passwords that are not exposed. If you modify the account password, you compromise SMS security, and can cause the account to become locked out. Best Practice: For this reason, and to minimize the potential for account lockouts, leave the account Password never expires option enabled for SMS accounts, and do not change the passwords on automatically created SMS-managed accounts. Principle 2: You can manually create SMS accounts for most SMS account roles. Implications for the administrator: You can set the passwords or account names for manually created accounts. Best Practice: If you need control over the accounts or their passwords, manually create the SMS accounts. Principle 3: SMS can use many accounts. For some site and client functions, you can use optional accounts. Implications for administrator: You can use these optional accounts to increase security by granting privileges on a more granular basis, which minimizes the risk to all SMS processes if the security of a single account is breached. However, these additional accounts also increase the administrative workload required to plan for and manage security-related tasks. Best Practice: Create and specify accounts in addition to those created by SMS Setup to minimize the use of the SMS Service Account.
Principle 4: The higher the privileges of an SMS account and the greater the number of processes accessed by the account, the more important it is to limit physical access to the computer that the account runs on or is used from. Implications for administrator: When you plan the physical location of SMS component servers, consider the accounts running on each computer and the privileges granted to those accounts. For example, if you have site servers located in smaller branch offices with minimal security, take additional steps to restrict physical access to those computers. Best Practice: Restrict physical access to SMS servers. Also, limit access to privileged accounts to as few administrators as possible. It is important to follow these precautions because the SMS Service Account and the SQL Server account have site-wide access. By restricting access to these accounts, you minimize the number of times you must change SMS passwords to provide the appropriate level of security. Principle 5: Manual changes made to accounts through the SMS Administrator console are not automatically made in the security systems for the operating system or SQL Server. The same principle applies to accounts that are manually specified in SQL Server. Implications for administrator: If you manage an account manually in the SMS Administrator console, you must also manage it in Windows NT User Manager for Domains or Active Directory Users and Computers, or in SQL Server Enterprise Manager. Best Practice: Document a procedure for managing SMS accounts in your SMS site that includes all the steps and tools that are required. Principle 6: SMS account management involves trade-offs. Standard security uses many accounts to manage SMS tasks and requires careful management of those accounts. Advanced security minimizes account management. However, several prerequisites must be met before you can implement advanced security. Implications for administrator: To effectively balance security with administration and deployment issues, it is important to understand key security decision points and how to implement those decisions in SMS. For example, which accounts are required and which can you specify on an optional basis for greater security? Which directory permissions can you change without disrupting SMS functionality? Best Practice: Use optional accounts as appropriate and migrate to advanced security when it is practical.
Planning for SMS Account Lifecycles

Because many organizations have security policies that require frequent account password changes, it is especially important to understand how to change SMS passwords without disrupting SMS functionality in your site. Developing an effective password management strategy is critical to maintaining strong security in your site. With an effective password management strategy, you can minimize the risk of account lockouts. Use password change techniques that minimize administrative effort and are appropriate for the account (if the account is one that can be managed by an administrator).
General Guidelines for Managing SMS Accounts

Following are general guidelines to help you manage SMS accounts.
Do not manually change accounts that are automatically maintained by SMS processes
Unless otherwise noted, do not change the passwords, account names, or permissions for accounts that SMS automatically creates and maintains. For enhanced security, SMS randomly generates and encrypts the passwords for these accounts. If you change the following accounts manually, the related processes do not run successfully, and you run the risk of causing account lockouts by forcing the accounts out of synchronization: u u u u u u u u u The default Client Connection (SMSClient_sitecode) The default Server Connection (SMSServer_sitecode) Remote Service (SMSSvc_sitecode_xxxx) Client Services (Non-DC) (SMSCliSvcAcct&) Client Services (DC) (SMS&_domain_controller_name) Client User Token (Non-DC) (SMSCliToknLocalAcct&) Client User Token (DC) (SMSCliToknAcct&) CCM Boot Loader (Non-DC) (SMSCCMBootAcct&) CCM Boot Loader (DC) (SMS#_domain_controller_name)
To change passwords on accounts that cannot be manually changed, use the relevant SMS tool to change the password. For example, to change the Remote Service Account password, do a site reset.
In general, change passwords, instead of accounts, to maintain security

Your organizations security policy might require changing accounts or passwords on a regular basis. When working with SMS accounts, change the password of an existing SMS account that you have created instead of adding new accounts or deleting old ones, with the following exceptions: u u u Client Connection Account Remote Service Account, if this account is shared by more than one site Database accounts, if these accounts are shared by more than one site
For these accounts you must create new accounts for these roles and cycle the accounts when the clients have servers that have all been configured with the new accounts. Never modify any account properties for accounts generated and maintained by SMS. For a complete list of accounts created by SMS and accounts that you can create and maintain, see Chapter 5, Understanding SMS Security.
If only one administrator knows an account password, seal and store it centrally
To maintain SMS security, make the passwords of the most powerful SMS accounts (or possibly all accounts) known to only one administrator. This is usually possible in smaller organizations. In such cases, the administrator can store the written passwords in a sealed envelope in a secure location, such as a company safe, that can be accessed only by authorized staff. With this provision in place, if the SMS administrator is unavailable when important SMS changes must be made, a manager or other authorized staff member can provide the necessary passwords to a sufficiently knowledgeable SMS expert. The sealed envelope shows that no one has obtained the passwords since they were set. It is important to remember to update the record of the passwords in the envelope whenever the passwords are changed.
Changing SMS Account Passwords

Different SMS accounts are managed in different ways. Table 12.2 lists the SMS accounts and the password change method to use for accounts whose passwords you can change. Table 12.2 Overview of Password Change Methods for SMS Accounts
Account name SMS Service How is password created? Administrator must specify. Is it acceptable to change the password manually? Yes. However, if this account is being shared by more than one site or if you are changing the password for this account on secondary sites, see the Account-Specific Guidelines for Managing SMS Account Passwords section later in this chapter. Yes. If yes, use this password change method Operating system, then site reset. -orOperating system, then SMS Administrator console.
Database accounts (sa) (SQL Server)
Administrator must specify
SQL Server, then site reset. -orSQL Server, then SMS Administrator console. Operating system, then SMS.
Site Address
Administrator must specify.
Yes.
(continued)
Table 12.1 Overview of Password Change Methods for SMS Accounts (continued)
Account name Server Connection (SMSServer_site code) How is password created? Randomly generated by SMS Is it acceptable to change the password manually? Manual change not recommended. Site reset automatically generates new password. However, if you are using the SMSAccountSetup.ini file, see the Account-Specific Guidelines for Managing SMS Account Passwords later in this chapter. Yes. If yes, use this password change method N/A
Site System Connection Remote Service (SMSSvc_siteco
Administrator must specify.
Operating system, then SMS Administrator console. N/A
de _xxxx)
Randomly Manual change not generated by SMS. recommended. Site reset automatically generates new password. Randomly generated by SMS Manual change not recommended. Client removal and reinstallation automatically generates new password. Manual change not recommended. Client removal and reinstallation automatically generates new password. Manual change not recommended. Client removal and reinstallation automatically generates new password. Manual change not recommended. Client removal and reinstallation automatically generates new password.
Client Services (Non-DC) (SMSCliSvcAcct &)
N/A
Client Services Randomly (DC) generated by SMS (SMS&_domain_ controller_name) Client User Token Randomly (Non-DC) generated by SMS. (SMSCliToknLoc alAcct&) Client User Token Randomly (DC) generated by SMS. (SMSCliToknAcct &)
N/A
N/A
N/A
(continued)
Table 12.1 Overview of Password Change Methods for SMS Accounts (continued)
Account name Client Connection (SMSClient_sitec ode) How is password created? Password for default account randomly generated by SMS. If administrator creates additional accounts, a password must be specified for each account. Administrator must specify. Administrator must specify. Administrator must specify. Is it acceptable to change the password manually? Manual change not recommended. For more information, see the Account-Specific Guidelines for Managing SMS Account Passwords section later in this chapter. If yes, use this password change method N/A
Advanced Client Network Access Legacy Client Software Installation Client Push Installation
Yes. Yes.
Operating system, then SMS Administrator console. Operating system, then SMS Administrator console. Operating system, then SMS Administrator console.
Yes.
Site reset is the process of running the SMS Setup Wizard and selecting the Modify or reset the current installation option to initiate configuration changes in an SMS site. During site reset, changes specified while running the SMS Setup Wizard are written to the master site control file. SMS components and threads are removed from site servers and site systems, and then reinstalled. Accounts are also deleted and recreated. Unless noted otherwise, site reset automatically changes the passwords for the following accounts: u SMS Client Connection (If you specify additional SMS Client Connection Accounts, SMS site reset does not automatically change the password for those accounts site reset automatically changes the password only for the default account created by SMS.) SMS Server Connection (If you are using the SMSAccountSetup.ini file, see the AccountSpecific Guidelines for Managing SMS Account Passwords section later in this chapter.) SMS Remote Service
u u
You can change passwords for the following SMS accounts by using either site reset or the SMS Administrator console (with Active Directory Users and Computers administrative tool or SQL Server Enterprise Manager): u u SMS Service Database (SQL Server)
For ease of administration, especially in organizations with geographically widespread sites, use the SMS Administrator console to change passwords for these accounts. By using this approach, you can enable administrators to use remote SMS Administrator consoles to change account passwords. But keep in mind that for this approach to work, all SMS services must be running. If these services are not running, or if they stop before the password change cycle is completed, you must run site reset or you will not have access to the SMS Administrator console. If your organization has geographically dispersed sites, you do not have to be physically present at each site server to perform this change. To use site reset to change SMS account passwords without traveling to the site server, do either of the following: u Use the software distribution feature of SMS to send a setup package with an appropriate script to the site server at the remote site. or u Use SMS Remote Tools to run the Setup.exe file from the following folder: SMS\Bin\i386\.
Specific Guidelines
Some SMS accounts must be managed in specific ways to avoid problems. Use the following guidelines to avoid account lockouts and orphaned clients in your SMS site.
Managing the SMS Service Account

Multiple sites and domains can share the SMS Service Account if you configure appropriate trust relationships and group inclusion, and if you specify the same domain name and account name for this account on the appropriate site servers. If the SMS Service Account is shared by multiple sites, or if you plan to change account passwords on secondary sites, create a second SMS Service Account before you change the first. The same SMS processes that use the changed account information also use the SMS Service account to start up and authenticate sessions. By creating a second account and leaving both accounts active until the transition to the new account is completed, you ensure that no matter which account a process attempts to use to start up or to authenticate a session, that process can gain the access it requires.
Managing the Server Connection Account

You should not change the default Server Connection Account created by SMS unless you created the account by using the setup command-line option, or by using the SMSAccountSetup.ini file. For information about using these methods to create the Server Connection Account, see Chapter 5, Understanding SMS Security. If you have to run site reset, you must use the same command-line context or SMSAccountSetup.ini file to specify the same account that you specified during site setup. Otherwise, when you run site reset, SMS creates the default SMS Server Connection Account it usually creates and changes the password to a randomly generated password. As a result, remote site systems cannot access the site server because they attempt to use the SMS Server Connection Account that you manually specified during site setup.
If you delete the Server Connection Account and then run site reset to recreate it, site reset does not recreate all of the NTFS permissions for this account. For example, you lose permissions to the inboxes that client files on a CAP must be transferred to (such as DDM.box, Inventry.box, and Sinv.box). This occurs because the security identifiers associated with the permissions on those inboxes apply to the old account, not the new one. If the Server Connection Account is deleted, you must do a site reset and then run the ACLreset.exe tool available for download at www.microsoft.com/sms.
Managing the Client Connection Account

SMS client components on clients that are running Microsoft Windows NT 4.0, Microsoft Windows 2000, Microsoft Windows XP, or Windows Server 2003 use Client Connection Accounts to connect to CAPs and distribution points, to transfer data and retrieve configuration settings. For example, a client component that is updating its configuration to match the configuration settings defined at the site level uses this account to retrieve the new settings from the CAP. To prevent your clients from being orphaned, it is important to ensure that at least one valid Client Connection Account is always available to clients. Careful planning is essential if you are removing and reinstalling an SMS site server. Client computers that are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 use the Client Connection Account to connect to the CAP. If account lockout is enabled in your site, a single client with an password that is not valid can cause the Client Connection Account to become locked out for all clients. For example, an SMS client that has been offline for a long time can cause a lockout because its Client Connection Account password might have expired. When it attempts to connect to a CAP using a Client Connection Account with an old account password, it causes that Client Connection Account to be locked out. Because Windows account information typically propagates down the domain more quickly than SMS account information in an SMS hierarchy, when a Client Connection Account password is changed, the SMS client with the old password fails. If the SMS client software is installed on the client through Client Push Installation, it is difficult for that client to recover from the account lockout because the client receives updated account information from the CAP by using the account that just failed. However, if you have set up your logon scripts to install (or reinstall) the SMS clients during logon, the client receives the updated account and password information during the next logon (if logon scripts are used). If you have not enabled some method to install clients during logon, the only way for such a client to recover from account lockout is for you to use SMSman.exe to reinstall. You could also remove the client and then reinstall the client using Client Push Installation. Do not remove and reinstall an SMS site server without enabling a logon client installation method. The password for the default SMS Client Connection Account (SMSClient_sitecode) is randomly generated and resynchronized with the domain account during each SMS client logon (if SMSls.bat is run). However, if you remove and reinstall an SMS site server without either enabling a logon or other client installation method, the clients are orphaned.
Minimizing the Number of Accounts SMS Uses

Standard security requires and maintains more accounts than advanced security. Using advanced security and Advanced Clients are the easiest ways to minimize the number of accounts that SMS uses. However, if you cannot use them, there are other techniques that can be used to minimize the number of SMS accounts. Note that in some cases, although minimizing the number of accounts makes it harder to tighten SMS security, doing so might be appropriate if you have to reduce administrative overhead and your security risk is minimal.
Important
Reducing the number of accounts increases the security risk because if any of the remaining accounts are compromised, all the computers that they can be used on could be compromised.
Mandatory multiple instance accounts

SMS automatically creates the following accounts to accommodate the requirements of multiple sites or domain controllers. u Client Services (DC) Account (SMS&_dc) SMS creates one of these accounts for each domain controller in the domain, regardless of the number of sites within that domain. u u Server Connection Account (SMSServer_sc) SMS setup creates one of these accounts for each site. Remote Service Account (SMSSvc_sc_xxxx) SMS creates this account on each CAP that is defined, if the CAP is not on the site server to support the SMS Executive service. If a server is not the SMS site server, then SMS creates this account on a computer that is running SQL Server in order to support the SQL Monitor service. Client Connection Account (SMSClient_sc) SMS Setup creates this account in the domain that SMS is installed in to support Legacy Client connections to a CAP. Although SMS creates one Client Connection Account for each site, the administrator can create as many additional accounts as required to address specific security issues. CCM Boot Loader (DC) Account (SMS#_dc) When installing Legacy Clients with Client Push Installation, Client Configuration Manager (CCM) creates this domain account to run the CCM boot loader service on client computers that are domain controllers. This account is made unique by including the domain controller name in the account name. This account is automatically deleted after the client is set up.
Optional multiple instance accounts

An SMS administrator can choose to create the following accounts to provide additional security or stability. For some accounts, you might want to create multiple instances. u SMS Service Account Either the administrator or SMS Setup can create this account. Only one SMS Service Account can be used in each site, but multiple SMS Service Accounts can be created and used if multiple sites exist. If the sites share a domain, then that domain includes all these accounts. u Client Connection Account (SMSClient_sc) Setup creates this domain account. Although SMS creates one Client Connection Account for each site; the administrator can create as many additional accounts as required to address specific security issues. u Site Address Account The administrator creates this account to allow SMS sites to communicate with each other. The number of accounts created is determined by the administrator there might be only one account used for this purpose throughout the organization, or there could be one for every SMS address. u Site System Connection Account One account can be shared among multiple sites, or the administrator can create one account for each site. u Client Push Installation Account Accounts can be shared among multiple sites, or the administrator can create accounts specific to each site or domain.
Mandatory local multiple instance accounts

There are accounts that are unique to each SAM database. Because you have multiple SAM databases (one for all domain controllers in each domain and one for each member server or workstation), you have multiple copies of these accounts. The accounts that fall in this category are: u u u Client User Token (Non-DC) (SMSCliToknLocalAcct&). Client Services (Non-DC). CCM Boot Loader (Non-DC) (SMSCCMBootAcct&) this is a temporary account.
The multiple instances of these accounts should not cause any problems because they are in separate databases. However, it might help you, when you are troubleshooting, to remember that each instance of these accounts is unique.
Strategies for reducing the number of multiple accounts

You can reduce the number of multiple accounts by using any of the following strategies: u u Minimize the use of optional accounts. Use setup options to force the use of common SMS Server Connection Accounts and SMS Client Connection Accounts with a known password. For more information, see the Site Setup section in Chapter 5, Understanding SMS Security. Resolve problems that prevent temporary accounts from being deleted. This especially applies to the CCM Boot Loader (DC) Account. Minimize the number of SMS sites in each domain. This action does not actually reduce the number of accounts, but it does reduce the number of accounts that occur in any single domain. This solution might be especially appropriate if you have resource domains.
u u
Creating or Modifying SMS Accounts and Groups

Following are procedures for creating and changing the SMS accounts that can be managed by an administrator. SMS 2003 accounts are always created at the nearest domain controller, and then replicated to the other domain controllers using the replication process of Windows NT 4.0, Windows 2000, or Windows Server 2003 family operating systems.
Creating or Modifying the Client Push Installation Account

The Client Push Installation Account does not have to be a member of the Domain Admins group, but it must have local administrative credentials on the computers where the SMS client software are installed.
To create or modify the Client Push Installation Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new Client Push Installation Account or If you have already created a Client Push Installation Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to the site where you want to specify the Client Push Installation Account, or whose account you want to change.
Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Client Installation Methods
3.
Right-click Client Push Installation in the results pane, and then click Properties.
4. 5.
In the Site Properties dialog box, click the Accounts tab, and then click the new account icon. You can repeat this step and step 5. In the Windows User Account dialog box: Specify the name and password of the new Client Push Installation Account that you created. or If you have already created a Client Push Installation Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
Creating or Modifying the Site Address Account

The Site Address Account is used to establish communications and transfer data between parent and child sites. Parent sites use this account to transfer administrative data (such as package or collection data) to the child. Child sites use this account to transfer data (such as inventory data, discovery records, or status messages) to the parent site. For standard security sites, you must specify a Site Address Account for each sender address when you create addresses for other sites. This account must have Read, Write, Execute, and Delete rights on the SMS\Inboxes\Despoolr.box\Receive folder on the destination site server. Advanced security sites use the site servers computer account if a Site Address Account is not set.
Important
If you specify a Site Address Account for an address and then later decide you want to use the computer account as the Site Address Account, you must delete the address and recreate it. You cannot only change the address to use the computer account as the Site Address Account.
You create each Site Address Account in both Windows NT User Manager for Domains or Active Directory Users and Computers and in the SMS Administrator console. If you modify this account, you must modify it in both locations, as well.
To create or modify the Site Address Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new Site Address Account. or If you have already created a Site Address Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to Addresses.
Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Addresses
3. 4. 5. 6.
Click Addresses. Right-click the address whose site address account you want to change, and then click Properties. In the Address Properties dialog box, click the General tab, and then click Set. In the Windows Account dialog box: Specify the name and password of the new Site Address account you created. or If you have already created a Site Address Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
Note
This account must be known to the destination site server that you specified on the General tab in the Address Properties dialog box. For SMS 2003 destination sites, the account should be added to the SMS_SiteToSiteConnection_sitecode group on the destination site server.
Creating or Modifying the SQL Server Account

For ease of administration, if you have to change the password or the user account for the SQL Server Account, you can use the SMS Administrator console or site reset.
To create or modify the user account for the SQL Server account using the SMS Administrator console
1. In SQL Server Enterprise Manager: Create a new user account for the SQL Server account. or If you have already created a user account that you want to modify, then modify the name or password (or both) of the existing account. 2. In the SMS Administrator console, navigate to the SMS site whose user account you want to specify or change.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name
3. 4.
Right-click the site, and then click Properties. In the Site Properties dialog box, click the Accounts tab, and then click Set.
5. 6.
In the SQL Server Account dialog box, specify an existing SQL Server account and password. Specify the name and password of the new user account that you created in SQL Server Enterprise Manager. or If you have already created a user account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
For higher reliability, use site reset to change the password for the SQL Server account. If your organization has geographically dispersed sites, you can perform this change without traveling to each site server by using SMS software distribution or Remote Tools.
To modify the user account for the SQL Server account using site reset
1. 2. 3. 4. In SQL Server Enterprise Manager, modify the name or password, or both, of the existing user account for the SQL Server account. Start the SMS Setup Wizard. In the Setup Options page, click Modify or reset the current installation. In the Integrated Security for SMS Site Database page, modify the user account to use the same password and name that you specified in step 1.
Creating or Modifying the Management Point or Server Locator Point Database Accounts
Creating or modifying the SQL Server management point or server locator point database accounts is much the same as creating or modifying the SQL Server account.
Note
Some time might elapse between setting a new SQL Server account in the SMS Administrator console and all relevant site systems starting to use that account. Typically, this would be in the range of minutes, about 2 to 15 minutes. If you want the site system functionality to be available while the accounts are changed, keep the old account valid until all site systems have had a chance to receive the new account details.
Creating or Modifying the SMS Service Account

Multiple sites and domains can share the SMS Service Account if you configure appropriate trust relationships and group inclusion, and if you specify the same domain name and account name for this account on the appropriate site servers. However, if more than one site shares the SMS Service Account, and you plan to change the account password, create a second account to avoid lockouts.
SMS 2.0 creates the SMS Service Account during site setup, using the account name and password that you specify in the SMS Setup Wizard. To modify the SMS Service Account, you can use Windows NT User Manager for Domains or Active Directory Users and Computers and site reset or Windows NT User Manager for Domains or Active Directory Users and Computers and the SMS Administrator console. If you must change the password for the SMS Service Account, you can use the operating system tools to change the password and use the SMS Administrator console to make it effective, rather than doing a site reset. The SMS Service Account must have administrative credentials on the site server and the Log on as a service right. If the account you specify does not have sufficient credentials, the previous SMS Service Account is used by the site, but the SMS Administrator console displays the account you specified.
To create or modify the SMS Service Account using the SMS Administrator console
1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new SMS Service Account. or If you have already created an SMS Service Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to the site whose SMS Service Account you want to specify or change.
3. 4. 5.
Right-click the site, and then click Properties. In the Site Properties dialog box, click the Accounts tab, and then click Set. In the Windows Account dialog box: Specify the name and password of the new SMS Service Account that you created in the operating system. or If you have already created an SMS Service Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
For higher reliability, use site reset to change the password for the SMS Service Account.
To modify the SMS Service Account using site reset

1. 2. In Windows NT User Manager for Domains or Active Directory Users and Computers, modify the name or password, or both, of the existing account. Start the SMS Setup Wizard.
3. 4.
On the Setup Options page, click Modify or reset the current installation. In the SMS Service Account Information page, modify the account to use the same password and name that you specified in step 1.
Creating or Modifying the Site System Connection Account

To enhance security, specify that the Site System Connection Account be used by services that run on the site server to connect to site systems. If you do not create this account, the SMS Service Account is used instead.
To create or modify the Site System Connection Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new Site System Connection Account. or If you have already created a Site System Connection Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to Site System.
Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Connection Accounts Site System
3. 4. 5. 6.
Right-click Site System, point to New, and then click Windows User Account. In the Connection Account Properties dialog box, click Set. In the Windows User Account dialog box: Specify the name and password of the new Site System Connection Account that you created using the operating system tool. or If you have already created a Site System Connection Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
Creating or Modifying the Advanced Client Network Access Account

Advanced Clients can use the Advanced Client Network Access Account to access network shares on servers that are not SMS. To avoid account lockouts, do not change the password on an existing Advanced Client Network Access Account. You should create a new account and set SMS to use that account. When sufficient time has passed for all clients to have received the new accounts details, the old account can be removed from the network shares and deleted.
To create or modify an Advanced Client Network Access Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new Advanced Client Network Access Account. or If you have already created Advanced Client Network Access Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to Component Configuration.
Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Component Configuration
3. 4. 5. 6.
Click Component Configuration. In the details pane, right-click Software Distribution, and then click Properties. In the Software Distribution Properties dialog box, click the General tab, and then click Set in the Advanced Client Network Access Account box. In the Windows User Account dialog box: Specify the name and password of the new Advanced Client Network Access Account that you created in the operating system. or If you have already created an Advanced Client Network Access Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
Creating or Modifying the Client Connection Account

SMS creates and maintains a local SMS Client Connection Account (SMSClient_sitecode) for each CAP, but for enhanced security, site integrity, and fault tolerance, it is recommended that you create additional accounts. If clients must access CAPs in multiple domains, this account must be granted adequate permissions to the CAP residing in the other domains or additional accounts must be created. It is recommended that you create additional accounts.
To create or modify the SMS Client Connection Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new SMS Client Connection Account. or If you have already created an SMS Client Connection Account that you want to modify, then modify the name or password, or both, of the existing account.
2.
In the SMS Administrator console, navigate to Client.

Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Connection Accounts Client
3. 4. 5.
Right-click Client, point to New, and then click Windows. In the Connection Account Properties dialog box, click Set. In the Windows Account dialog box: Specify the name and password of the new SMS Client Connection Account that you created. or If you have already created an SMS Client Connection Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
When creating additional SMS Client Connection Accounts, ensure that multiple accounts are valid for each domain that clients are in. You do not realize the benefits of having multiple accounts until every client has multiple valid accounts available. For example, if you create four SMS Client Connection Accounts, but each account is valid for clients in only one domain, then the clients in other domains can still become locked out. You can use the following procedure to ensure that two valid client connection accounts are maintained at all times. Implement this procedure in every domain that has a client connection account used by clients in the site. The following procedure describes how to create three new client connection accounts, and then cycle the creation of additional new accounts and the deletion of old accounts. By creating three new accounts, adding a new account and then deleting an old account, you ensure that two valid accounts remain available during account maintenance the newer account and the older account. The older account helps ensure that clients who have been offline for a longer time and then return online have a valid account and password.
Note
The time between a cycle of adding and deleting accounts in a three account cycle should be one-third of the maximum password age set in the operating system. In this procedure, the time between cycles of adding and deleting accounts is two weeks (one-third of the default 42-day maximum password age).
To cycle SMS Client Connection Accounts

1. Start User Manager for Domains or Active Directory Users and Computers and create the following three accounts: u u u SMSClient_00001 SMSClient_00002 SMSClient_00003
(Use the format SMSClient_XXXXX when you name your accounts to ensure sufficient account capacity.) 2. In the SMS Administrator console, create the same three accounts. For information about creating SMS Client Connection Accounts in the SMS Administrator console, see the Systems Management Server Administrator Help. 3. Two weeks after you create the first three accounts, create a fourth account (SMSClient_00004) in User Manager for Domains or Active Directory Users and Computers and in the SMS Administrator console. Delete the oldest account (SMSClient_00001) from User Manager for Domains or Active Directory Users and Computers and from the SMS Administrator console. Two weeks after you delete the oldest account, add a new account (SMSClient_00005) to User Manager for Domains or Active Directory Users and Computers and the SMS Administrator console. Delete the oldest account (SMSClient_00002) from User Manager for Domains or Active Directory Users and Computers and from the SMS Administrator console.
4. 5.
6.
Continue this cycle every two weeks by adding a new account with an incremented number in the account name (SMSClient_0001, SMSClient_0002, and so on) and by deleting the oldest account in the series. Remember to add and delete the account in both User Manager for Domains or Active Directory Users and Computers and the SMS Administrator console.
Creating or Modifying the Legacy Client Software Installation Account

All mentions of the word client in this section refer to the Legacy Client. You can create the Legacy Client Software Installation Account to provide a security context that might be required by certain advertised programs when they run on Legacy Client computers. When you configure the software distribution component, you can specify an account for programs to use on clients that are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems when no user is logged on. This account is only required when an advertised program must have access to a network resource that is not managed by SMS and is not accessible to the account that the program is running under (either the currently logged on user or the Client User Token Account). The account can be created anywhere, but the client must be able to find the domain where the account resides. The account does not work if the client cannot find it, and if the client fails to find the correct account, account lockouts could result.
Planning SMS Object Security 453
There is no requirement to make this account an administrative account. It must have sufficient network privileges to complete the program requirements. If the account is not an administrative account, either directly or indirectly through group membership, the Advertise Programs Manager temporarily adds it directly to the local Administrators group before running the program. You create the Client Software Installation Account in both Windows NT User Manager for Domains or Active Directory Users and Computers and in the SMS Administrator console. If you change the password for this account, you must also change it in both locations.
To create or modify a Legacy Client Software Installation Account

1. In Windows NT User Manager for Domains or Active Directory Users and Computers: Create a new Client Software Installation Account. or If you have already created a Legacy Client Software Installation Account that you want to modify, then modify the name or password, or both, of the existing account. 2. In the SMS Administrator console, navigate to Component Configuration.
Systems Management Server Site Database (site code - site name) Site Hierarchy site code - site name Site Settings Component Configuration
3. 4. 5. 6.
Click Component Configuration. In the details pane, right-click Software Distribution, and then click Properties. In the Software Distribution Properties dialog box, click the General tab, and then click Set in the Legacy Client Software Installation Account box. In the Windows User Account dialog box: Specify the name and password of the new Client Software Installation Account that you created in the operating system. or If you have already created a Client Software Installation Account that you want to modify, then modify the account to use the same password and name that you specified in step 1.
Planning SMS Object Security

When planning SMS object security, you should separately consider the issues of collection security from all other object security. Collection security allows you to ensure that SMS security reflects the organizational responsibilities of your SMS administrators. Give each administrator or group of administrators the rights and permissions they need to support the computers and other kinds of resources that they are responsible for.
SMS object security, other than collection security, allows you to determine who can manage individual sites, create packages or reports, and perform similar SMS functions. If you are upgrading to SMS 2003 from SMS 2.0, you should review the new SMS object security rights and decide which SMS administrators should be granted those rights. For a list of SMS object security rights, see Table 5.10 in Chapter 5, Understanding SMS Security.
Planning Collection Security

Generally speaking, the security you set for collections in your SMS site depends on the role of the administrator to whom you are delegating access to the collections. For example, collection security might vary for junior SMS administrators, help desk staff, or other people that use the SMS Administrator console but are not senior SMS administrators. Designing the collections and assigning appropriate rights and permissions could take some time. When designing collection security, start by identifying the people who must use the SMS Administrator console but are not senior SMS administrators. Then identify which resources they are responsible for supporting. Try to find groupings of users that can be given rights as groups. Look for users that have overlapping responsibilities. The next step in designing collection security is to create master collections that the administrators or groups can be given rights to. Administrators within groups should usually be given the Delegate right, so that when they create subcollections of their resources, they can give rights to other administrators to also use those subcollections. An example of a collection right scenario is a situation where you have three primary sites, two of which report directly to the central site. Each site has local computer support people who use SMS to support their local users, but who should not be able to support users at the other sites. The central site also has a group that is responsible for server support at all sites but is not responsible for workstation computers. The other SMS users should not be able to support the servers. To ensure continuity of service, the administrators at the child sites can use the central site to support their users, if necessary. In this case, four collections would be defined at the central site one for each of the sites that the workstations can be assigned to but excluding servers, and a collection for the servers, regardless of the site they are assigned to. Each of the administrators is assigned to the collection they are responsible for. If any administrators have dual functions, they are given rights to two collections. For the collections, each user group is given instance Read, Delete, Modify Resource, Use Remote Tools, Create, Modify, and Delegate rights. Also, each user is given the class-level collection rights of Create and Delegate.
Planning Object Security for Objects Other Than Collections

Object security for objects other than collections can be complex if you subdivide site or SMS object responsibilities in many ways or among many people, but otherwise it is relatively direct.
Planning SMS Feature Security 455
When you design object security for objects other than collections, consider the functions of your SMS administrators. Do some administrators exclusively create packages? Do all administrators need to manage site properties? You should consider what object security is required for the following SMS roles: u u u u u u u u Help desk staff (adding resources to collections, remote tools, etc. Package creators Package distributors Software distribution testers Software distribution coordinators (distributing to the whole organization, monitoring status, etc.) Site administrators Report creators Report users
Planning SMS Feature Security

You should review the SMS feature security options, as described in Chapter 5, Understanding SMS Security, in order to select security practices that are appropriate for your organization. Examples of features that require additional planning, beyond general SMS security and SMS object security, are: u u u u Reporting who can view the reports, and should some users be restricted to certain views. Remote tools which accounts should be added to the Remote Tools Permitted Viewers list. Package access consider whether any packages must be restricted to certain user groups. Packages downloaded to clients consider whether unauthorized users can access any packages that are downloaded to client computers. If this is a threat, then set those packages to always run from a distribution point. Inventory extensions consider whether you need to use MIF files for inventory extensions. If you currently use MIF files, consider whether you can move to alternative solutions that use SMS_def.mof extensions instead.
Planning to Use SMS Security

When you implement and use SMS, it is best to follow practices that have been shown to minimize risks and maximize the benefits of SMS. These best practices can help you avoid security-related problems and allow you to maximize SMS security while minimizing administrative overhead.
Although there are many ways to make an SMS deployment more secure, in general, a greater level of security requires a greater level of effort to develop and maintain security policies. In some environments, this effort is necessary and the cost-to-benefit ratio is justifiable. However, there is always a point at which costs outweigh benefits, and this point varies from company to company. Choose those best practices that optimize implementation for your particular organization. There are many SMS deployment practices available to make the installation more secure than the default settings provide, without making the administration overly complex. Consider the following categories: u u u u u SMS configuration settings that enhance security. Ideally, these are established during deployment, but you can set these at any time. Tightening SMS security. Operating system appropriate configuration of the operating system that helps SMS in various ways. Monitoring and auditing SMS Security. Advanced technologies and techniques that can increase your SMS security.
SMS Security Configuration

Use the following configuration settings to improve SMS security: u For simplicity, set up SQL Server to use Windows authentication, as described in the SQL Server documentation. It is important to maintain SQL Server security. Direct access to SQL Server allows SMS objects to be created or modified in a way that the SMS enforced security might otherwise prevent. Controlling direct access to other parts of SMS (such as the SMS files) is also important, but it is especially true for SQL Server because SQL Server is central to SMS. Also, creating records in the database is easier than creating files elsewhere in SMS. u Install SMS on member servers of a domain instead of on domain controllers. This allows you to maintain SMS accounts in the local SAM database, instead of the domain SAM database. Domain controllers do not have a local SAM database other than the domain SAM database. Do not allow users who are not administrators to use the SMS Administrator console on the site server. The default SMS directory-level permissions allow administrators to use the console only on the site server, and it is recommended that this level of security be maintained. Create Site System Connection Accounts to access site systems only in the domains in which those site systems exist, and restrict the account to be a local Administrator on site systems only.
Planning to Use SMS Security 457
u u
Create a Client Push Installation Account and Legacy Client Software Installation Account for the domain, with administrator privileges only on the clients. Set up multiple Client Connection Accounts to prevent account lockout from orphaning clients.
Tightening SMS Security

The following practices can make SMS security tighter by restricting access to SMS resources and restricting the exposure of SMS accounts. Carefully consider any changes you make to tighten SMS security to avoid causing operating problems for SMS. For example, enforcing too strong a password filter rule can cause SMS to fail when you are trying to create or modify an account password. In addition, the changes you implement might increase the amount of administrative effort necessary to maintain the SMS site. u Use advanced security wherever possible. If you were previously using standard security, or SMS 2.0 security, then remove any security accounts that are no longer being used by SMS clients, servers, or sites after you change to advanced security. Use Advanced Clients exclusively. When you no longer have Legacy Clients at a site, you can remove the accounts used to support Legacy Clients, such as Client Connection Accounts, and relevant SMS components, such as CAPs or Legacy Client installation methods. Use the optional accounts, because they have more limited privileges than the default SMS accounts, such as the SMS Service Account. Conversely, do not use the SMS Service or other accounts for account roles that you can assign to optional accounts. Restrict access to the more powerful accounts, such as the SMS Service Accounts and the database accounts. Only a small number of core SMS administrators need to know the main account passwords. Use unique accounts at each site or in each domain, as appropriate. In this way, if an account is compromised at one location, it cannot be used at any other location. To avoid confusion, give the unique accounts unique user names (instead of just being in unique SAM databases). Use local accounts, instead of domain accounts, wherever possible. Particularly avoid using accounts with domain administrator privileges. This limits the scope of authority for the accounts, so that if they are compromised, the damage that can be done with them is limited.
Limit account privileges. Grant access only to necessary classes or instances in SMS object security. Do not put accounts in groups that can have access to more resources than required. In some cases, this might mean switching SMS accounts from their default groups to more restricted groups. Grant each site system only local administrator rights and permissions for SMS services and functions. For instance, if a site is using standard security, add the SMS Service Account to the local Administrators group on the following site systems: u u u Site server SQL Server CAPs
Reduce the number of accounts that can access SMS resources. This might involve limiting access to SMS shares strictly to the accounts that require access. For instance, grant Read and Write rights on the SMS_SITE share only to the SMS Site Address Account, and ensure that no accounts are members of the Domain Admins group. Use strong passwords for accounts in which you can specify the password. Never leave the password blank. Use feature-level security aggressively, as described in Chapter 5, Understanding SMS Security. Install the site server on a server that is not a domain controller, so that accounts can be put in a local SAM database (domain controllers have only the domain SAM database)
u u u
Operating System Security Best Practices

To maintain effective security in your SMS site, and to prevent problems, it is important to understand which account policy settings are appropriate for SMS accounts.
Enable Account Lockout Carefully

The Account lockout option helps maximize security by preventing potential intruders from guessing passwords through trial and error. SMS supports the use of account lockout. However, keep in mind that if you enable account lockout, you risk locking out any processes that share an account. Multiple components in SMS can share the same account. If even one component uses the wrong password for the account, that process can lock out the account for other components that share that account. For example, all Legacy Clients use the same domain-level Client Connection Account to connect to a CAP. If one Legacy Client locks out the Client Connection Account, for example by using an incorrect password, that Client Connection Account is locked out for all other Legacy Clients that use the same account.
Planning to Use SMS Security 459
If you enable the Account lockout option, the following settings are recommended for SMS accounts: u u u Lockout after five attempts. This is the default setting. Reset count after 30 minutes. This is the default setting. Lockout duration: forever. This is not the default setting, but it is recommended for enhanced security. By using this setting, you can monitor lockouts when they occur and take appropriate measures.
Use Account Policies Carefully

It is recommended that you use the default account property option of Password Never Expires for default SMS accounts, and that when you create a new SMS account, you enable the account property option Password Never Expires. If you must allow SMS account passwords to expire, you must have an account cycling procedure in place for them. The Password Never Expires setting prevents problems that can occur (such as account lockout) when a critical SMS password expires. Leave the Account Expires option set to Never for SMS accounts that you are not cycling. For SMS accounts to function properly, the account itself, in addition to the password, must not expire. By leaving this option set to Never, you avoid the disruption to SMS processes that would occur if an SMS account expired.
Monitoring and Auditing SMS Security

Putting SMS security in place is critical for maximizing the integrity of your computer infrastructure, and putting SMS security in place properly is crucial to the successful operation of SMS. In order to maintain SMS security and react to security issues when they arise, you must be vigilant. Use monitoring tools to watch for security events and to troubleshoot security-related problems. You can use monitor operating system security using the auditing facility of the operating system. After you have enabled security auditing, watch the security event log for SMS-related events. Check closely any failures that involve SMS accounts or resources. You can watch connections to SMS servers by using the Computer Management administrative tool on servers running Windows 2000 or Windows Server 2003. SMS communicates primarily through shares, so watching this kind of activity is quite useful for SMS monitoring. You should also watch SMS operational activities to ensure that only authorized activities are occurring. For example, watch for the creation of large or suspicious collections, the creation of advertisements, the addition of links from large collections to collections that are being advertised to, or package updates. The SMS status subsystem provides audit events to watch for such activities.
Advanced Technologies
Over time, computers have historically become less expensive and more powerful. In addition, new software and techniques are developed. This benefits everyone, including computer attackers and others that might try to break through your security system. Therefore, you must routinely review your security (and enhance it where appropriate), and take advantage of new security options when they become available. For these reasons, consider upgrading all clients and servers to the latest operating systems, or to the latest service packs for the operating systems you use. Consider using new security-related tools. Remain aware of industry best practices in the security area to ensure that you are using the most effective techniques.
Testing SMS Security

Test SMS security when you are putting it in place. Try to access all types of SMS resources using accounts you have created and delegated tasks to in order to verify that SMS objects and data are protected. Similarly, attempt to access SMS resources with the appropriate accounts and tools to verify that they work as intended and that SMS security is not overly restrictive. Examples of recommended tests: u u u u Verify that SMS Legacy Clients can connect to CAPs and distribution points for software distribution. Verify that SMS Advanced Clients can connect to management points and distribution points for software distribution. Review the SMS logs on sample clients to verify that routine SMS client tasks are completed as expected. Review the SMS logs on a sample site server to verify that the routine SMS server tasks are completed as expected. For example, verify that sites are able to send SMS data to each other. Use a typical administrator account to install an SMS Administrator console, and then access appropriate SMS objects, such as collections and advertisements. Use an unauthorized administrator account to ensure that it cannot use the SMS Administrator console to access SMS objects. Use a typical user account to try to install SMS on a client computer. Use a typical SMS administrator account to remote control different kinds of clients. Use unauthorized administrative accounts and user accounts to attempt remote control of some clients.
u u u u u
Testing SMS Security 461
u u u u
Use the remote control command-line interface (Remote.exe) to repeat the previous remotecontrol related tests. Use a typical SMS administrator account to generate and view reports. Try to use unauthorized SMS administrator accounts and user accounts to view reports. Try to access the SQL Server database using unauthorized administrator and user accounts.
Repeat each of these tests from the different domains that users and administrators work in at your company.
C H A P T E R
1 3
Planning for Backup and Recovery

Although it might seem unnecessary to plan for backup and recovery at such an early stage of your Microsoft Systems Management Server (SMS) 2003 hierarchy deployment, it is the perfect time to consider backup and recovery requirements, to develop a recovery plan, and to incorporate backup and recovery preparation into your SMS deployment plan. A site recovery is a complex process, and it is recommended that you plan ahead and be prepared. This helps you in the following ways: u u u You minimize the risk of failure in your site. You minimize the impact of a failure on your site, if it occurs. You simplify the recovery process, reduce the time of the recovery process, and minimize data loss, in the event of failure.
This chapter explains the concepts of site backup and recovery, and helps you plan for a successful site recovery.
In This Chapter
u u u u u u Overview of Backup and Recovery The Impact of a Site Failure Minimizing the Risk of a Site Failure Minimizing the Impact of a Site Failure Planning for Backup and Archive Planning to Simplify the Recovery Process
464 Chapter 13 Planning for Backup and Recovery
Overview of Backup and Recovery

SMS 2003 sites contain large amounts of valuable information that allows you to manage your sites clients and allows your site to operate smoothly. For enterprise solutions such as SMS, it is necessary to avoid the loss of critical data by planning for both backup and recovery operations. This is important so that you can recover SMS sites and hierarchies with the least data loss in the quickest possible time. A complete recovery cycle consists of four major administrative tasks: 1. 2. 3. 4. Planning for Recovery done during the SMS deployment planning stage. Preparing for Recovery done during the SMS deployment stage. Backing up a site done on a regular basis starting immediately after deploying SMS. Recovering a site done as needed.
It is essential to plan for recovery as early as possible. The best time to plan for recovery is during the overall SMS hierarchy planning stage. After you have incorporated recovery-planning strategies into your hierarchy and sites deployment, you must perform recovery-preparation tasks to ensure that your sites are prepared for a recovery operation. As part of your backup and recovery strategy, it is critical to start backing up an SMS site soon after that site is deployed, properly configured, and is in an overall healthy state. To ensure that backing up a site is as easy as possible, SMS provides the Backup SMS Site Server task, referred to as the SMS backup task. The SMS backup task creates a backup snapshot, which is a snapshot of the site data from the site server, the SMS site database server, and the site provider.
Caution
Backing up only one of these data stores (such as the SMS site database) is not sufficient as a backup strategy. You cannot recover a site using a partial site backup, because the sites data will be out of synch. Also, you cannot use the System Restore feature of the Windows Server 2003 family to recover a site, because it does not restore all necessary data.
The sites backup snapshot is stored at a location that you specify, referred to as the backup destination. Backing up your site on a regular basis is the main step when preparing for recovery. A failure in an SMS site can happen for various reasons, such as hardware failure, operating system failure, or data corruption. When a failure occurs at a site, then that site can no longer provide some or all of the functionality it normally provides. The site also loses some or all of its data.
Overview of Backup and Recovery 465
It is possible to repair some problems that cause failure in a site without reinstalling the site, but when the site cannot be repaired, you must reinstall the site using the site code of the failed site. SMS has a hierarchical structure, and it requires that connected sites are synchronized at all times to be able to properly communicate and to manage their clients. When a site fails, it affects other sites in the hierarchy. You cannot only run SMS Setup to recover a failing site, because the setup program does not restore or repair data. When reinstalling a site with a site code that was previously used in the hierarchy, you must prepare before running setup, and you must repair and synchronize the data after running setup. Otherwise, such an operation will most likely result in data corruption throughout the hierarchy that is nearly impossible to repair. You must perform additional steps before and after you reinstall that site to ensure that the new site reconnects to parent and child sites without corrupting any data at the new site, or at any other site in the hierarchy. This whole operation is called a recovery operation. Recovering a failed site includes restoration of the sites functionality, and recovering and resynchronizing as much data as possible.
SMS Data Types

When describing SMS related backup and recovery operations, it is important to know that SMS generates and uses two different types of data:
Configuration data
This data includes information about how the site is configured. It includes details such as site boundaries, feature configuration, and object definitions. All configuration data is critical when recovering a site. If you do not configure the site that you are recovering exactly the way it was configured before it failed, then the recovery operation might fail and the site might not function properly. Object definitions, such as software distribution objects, replicate down the hierarchy. The rest of the configuration data replicates up the hierarchy.
Administrative data
This data includes software and hardware inventory data from clients and status messages generated by clients and site systems. This data can be regenerated easily. This data is important, but not critical when recovering a site. The recovered site can function properly without having all administrative data. Administrative data replicates up the hierarchy.
The Backup and Recovery Cycle

To successfully restore complete functionality to a failed site, all of the sites configuration data must be available so that you can configure the site exactly the way it was configured before it failed. When you have properly planned and prepared for recovery, a recovery operation is most likely to be successful. The site regains complete functionality with the least amount of data lost.
Figure 13.1 Overview of the backup and recovery cycle

Planning for Maximum Uptime
Implementing Procedures
Backing Up Data
Failure
Rebuilding Servers
Restoring Data (optional)
Repairing/ Resynchronizing
Verifying Success
Understanding the Cause of Failure
For more information about how to prepare for recovery, how to back up, and how to recover a site, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
The Impact of a Site Failure 467
Backing Up and Recovering Throughout the SMS Hierarchy

You perform backup and recovery operations on individual sites. The SMS backup task can back up a single primary site or a single secondary site. To protect the entire hierarchy you must implement backup and recovery plans on each site in the hierarchy. There is no single backup plan that is appropriate for all SMS sites. You must assess each individual site in your hierarchy and determine the backup requirements of that site, such as how often you need to back it up. Using that information, develop a hierarchy backup plan. When you develop your hierarchy backup plan, consider the following: u u u There is no advantage to simultaneously backing up all the sites in the hierarchy. You can back up and restore each site independently. Schedule site backups throughout the hierarchy so that the network is not flooded, and so that the backed-up sites continue to operate normally. Do not make changes to the hierarchy while backup is scheduled to run on any site server, because all services on that site server will be stopped when the site backup task starts to run.
The Impact of a Site Failure

Before you start to evaluate recovery options for your site and make decisions about allocating resources for backup and recovery, you must understand the impact of a site failure. An SMS site consists of various site systems and clients. Each site has one site system that is the site server. The site server monitors and manages the site. Each site has one site system that is the SMS site database server, and each site has at least one (possibly more) site system that is either a client access point (CAP) or a management point. The CAP and the management point are the site systems that allow the site server and the sites clients to communicate. In addition to these essential site systems, a site can have any number of additional site systems that perform different roles in the site. For example, to distribute software, a site must have at least one distribution point. To support mobile clients, a site must have at least one management point. SMS supports site systems that are set up either on the same computer as the site server or on a separate computer. The site server and any of the other site systems can fail and thus not provide the services they regularly provide. If multiple site systems are installed on the same computer, then if that computer fails, all services regularly provided by those site systems are no longer available. Because each site system in the site provides different functionality, the impact of a failure on the site is different, depending on the role of the site system that failed. The following table contains information that can assist you in evaluating the impact of failure in your site.
Table 13.1 Impact of Site System Failure

SMS site system Site server Impact of failure The failed site server cannot receive or process any data from the sites clients, from child sites, or from parent sites. Therefore, data such as hardware and software inventory and status messages from clients accumulates at the site systems. You cannot perform site management tasks from the failed site server, such as: Remote control and troubleshoot clients. Managing or creating software distribution packages, programs, or advertisements. Managing or creating new software metering rules Managing or creating new collections. Managing or creating reports or dashboards. Managing or creating site systems The site server cannot access the site database to store or to retrieve data. You cannot perform any administrative task from the site server. You cannot store software distribution packages on the failing distribution point. Therefore, clients must use alternative distribution points or they will not be able to run advertised programs. You cannot perform Software Distribution tasks such as: Distributing or managing software distribution packages using the failing distribution point. Enabling or disabling BITS support on the failing distribution point. Clients cannot use the failing distribution point to perform tasks such as: Running advertised programs. No data propagates between the site server and the sites Legacy Clients through the failing CAP. Software and hardware inventory data and status messages from Legacy Clients cannot reach the site server. Configuration data from the site server cannot reach Legacy Clients. Legacy Clients must use an alternative CAP if one exists. The failing CAP cannot perform tasks such as: Discovering or installing new Legacy Clients. Updating configuration data of client agents for Legacy Clients. Managing advertisements and advertising new programs to Legacy Clients. Legacy Clients cannot use the failing CAP to perform tasks such as: Receiving information about new advertisements. Updating site-wide client configuration settings. Updating the Software Metering rule base.
SMS site database server Distribution point BITS-enabled distribution point
Client access point
(continued)
The Impact of a Site Failure 469
Table 13.1 Impact of Site System Failure (continued)

SMS site system Management point Impact of failure No data propagates between the site server and the sites Advanced Clients through the failing management point. Software and hardware inventory data and status messages from Advanced Clients cannot reach the site server. Configuration data from the site server cannot reach Advanced Clients. The failing management point cannot perform tasks such as: Discovering new Advanced Clients. Processing data from Advanced Clients such as software and hardware inventory. Process and propagating policies from site server to Advanced Clients Advanced Clients cannot use the failing management point to perform tasks such as: Receiving information about new advertisements. Updating Software Metering rule base. Clients cannot be installed using Logon Script-initiated Client Installation method (capinst.exe). You cannot use the failing reporting point to view reports.
Server locator point Reporting point
If any of the site systems listed in Table 13.1 remain in a failed state for a long period of time, clients can be severely impacted. However, the impact on clients is minimal if you restore functionality to the failing site system quickly. For a short period of time, there is minimal impact on the following client operations: u Advertised programs that were scheduled to run before a CAP failed, will run at their scheduled time, even if the CAP is not functioning. However, depending on which site system is failing, status from the clients might not propagate to the site server, and new programs cannot be advertised to the clients. Software continues to be metered on clients, even if the site server is not functioning. Software and hardware continue to be inventoried on clients, regardless of which site system has failed. However, the inventory data might not propagate to the site server, depending on which site system has failed.
u u
Also, if any component server has failed, it might affect communication with other sites, but otherwise, the site server continues to function with minimal interruption. However, you will receive numerous error and warning status messages to inform you of the problem. When a site system is not functioning, data starts to accumulate on clients or on other site systems. As soon as the failing site system regains functionality, the accumulated data propagates to the repaired site system, where it is processed in the regular manner. The rest of this chapter describes recovery planning that can help you reduce the impact of a site failure.
Minimizing the Risk of a Site Failure

It is to your advantage to do all you can to prevent site failures. When you take the appropriate preventive steps, you minimize the need for recovery operations. SMS sites can fail for various reasons, including hardware problems. Although it is beyond the scope of this chapter to describe all possible ways to prevent computer failure, there are a few basic strategies that you can plan to use: u u u u Monitor SMS site systems regularly. Invest in resources for the site server. Replace site server hardware before it fails. Use Microsoft Operations Manager (MOM) or similar server monitoring software.
Monitor SMS Site Systems Regularly

It is more effective to spend resources on site maintenance than on site recovery. Allocate appropriate resources to develop and implement an effective site maintenance plan. Part of your site maintenance plan must include tasks to monitor your site on a regular basis to detect problems as early as possible. If you take corrective actions at the first sign of a problem, you can often prevent a site a failure. Signs that indicate problems that require intervention include the following: u u u u File backlog on site servers and site systems. Status messages that indicate an error or a problem. Failing intrasite communication. Error and warning messages in the systems event log on the most important servers.
Note
When SMS is configured to write status messages to the systems event log, SMS error status messages are written as information events, not error events.
u u
Error and warning messages in the Microsoft SQL Server error log. Sites or clients that have not reported in a long time.
For more information about monitoring and maintaining SMS sites, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide.
Minimizing the Risk of a Site Failure 471
Invest in Resources for the Site Server

Site servers are the most important servers in SMS sites. The site server is used to initiate many administrative tasks such as distributing new software to clients, troubleshooting problems on client computers, and metering software on the clients. Site servers are also significant in that you use them to create new site systems for the site. If the site server is not functioning when a remote site system fails, you cannot set up a new site system until you recover the site server. You can back up site systems, and then restore them, if needed, but that requires a large investment, and in general, it is not a recommended strategy. In the event of a site server failure, your ability to manage the sites clients is extremely limited. Even if you do not need the site server to create new site systems, the other management tasks that are no longer available make it almost impossible to manage the site. Because of the importance of the site server, and the severe impact on the site in the event of failure, it is recommended that you invest resources in site servers to ensure their continued functionality. The budget for the site server must be adequate to ensure that: u u u u The site server is running with high-quality, reliable hardware. The site server either has adequate replacement parts available or an identical server to which you can restore the backup snapshot of the site server. The site server is backed up frequently. The site server has adequate capacity to process data beyond the regular amount. Data accumulates during a backup cycle. When the backup is complete, the site server must be able to process the accumulated data. There is staff that is trained to perform live site recoveries so that you can always recover the site server quickly and reliably.
Replace Site Server Hardware Before It Fails

Even high-quality hardware occasionally fails. Sometimes, it fails gradually, and there might be early signs. Replacing site server hardware before it completely fails is an important step in preventing site failure. As soon as you notice any signs of unreliable behavior on site servers hardware, replace the hardware. To properly replace site hardware, you must use the Recovery Expert, which is a recovery tool. For information about the Recovery Expert, see the Allocate a Server to Set Up the Recovery Expert Web Site section later in this chapter. For information about swapping the computer of a site server, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide.
Use Microsoft Operations Manager

If you use MOM or similar software to monitor applications in your organization, you can use that software to monitor the resources and performance of SMS servers.
MOM has built-in rules to monitor SMS. However, MOM relies on the systems event logs to monitor applications, while SMS, by default, does not log events to the system event logs. You must configure the status system in SMS to write to the systems event log before MOM can monitor SMS.
Note
When SMS is configured to write status messages to the systems event log, SMS error status messages are written as information events, not error events.
For more information about configuring the status system, see Chapter 14, Using the SMS Status System, in the Microsoft Systems Management Server 2003 Operations Guide. For more information about using MOM and the SMS Management Pack, refer to the MOM documentation.
Minimizing the Impact of a Site Failure

The best failure prevention plan can only minimize the risk of failure, but it cannot completely prevent one. After you have developed an effective failure prevention plan, the next step in your recovery planning is developing a plan to minimize the effects of a failure, if one occurs. These strategies can help you reduce the impact of a site failure: u u u u u u Do not share SQL Server between sites. Use multiple physical drives on the SMS site database server. Allocate multiple domain controllers. Set up multiple site systems with similar roles. Set up site systems on a computer other than the site server. Back up the central sites control file frequently.
Do Not Share SQL Server Between Sites

SMS sites store data on a computer running SQL Server. Although multiple sites can share a single computer running SQL Server to store data, this is not a recommended configuration. From a recovery perspective, it is especially important for each site to use its own computer to run SQL Server on. If a site that is sharing a computer running SQL Server with other sites fails, you must ensure that the recovery process of the failed site does not affect the other healthy sites. The recovery process becomes more complicated in this situation because you must isolate the recovery procedures to only the failed site.
Minimizing the Impact of a Site Failure 473
Use Multiple Drives on the SMS Site Database Server

Whether the site uses a local SQL Server or a remote SQL Server, it is recommended that separate physical drives be used for the SQL Server log files, the SQL Server data files and the computers operating system. If, for example, only the operating system drive fails because then there is no need to recover the site, because SQL Server can continue to function properly after the operating system is restored.
Allocate Multiple Domain Controllers

For increased security you can configure SMS to use many accounts. If you configure your site that way, then if your site fails, you must be able to re-create the same accounts to successfully recover the site. Account data is stored on domain controllers. To ensure that this information is always available to you, it is recommended that you allocate multiple domain controllers in your organizations infrastructure. When you set up multiple domain controllers, you take advantage of the regular data replication process of domain controllers. If a site fails, you can retrieve the configuration of the sites accounts from any domain controller on the network, and use that information to help recover the site. When you set up multiple domain controllers, set each one at a different physical location and on different network segments. This minimizes the risk of all domain controllers in your organization becoming unavailable. To further reduce the risk of not having account information, or if your site has a single domain controller, it is recommended that you store information about SMS accounts in a safe place, and update that information when you change accounts.
Set Up Multiple Site Systems with Similar Roles

SMS assigns site systems various roles to support different features of SMS. When a site system fails, you have limited use or no use of the feature. You can reduce the impact of site systems failure by having site systems redundancy in your site. This relies on the ability of SMS to create and support multiple site systems with the same role and the ability of clients to be able to use any site system to perform client operations. Regardless of recovery considerations, it is sometimes recommended that you set up multiple site systems with the same role in your site. If a site system fails, having additional site systems that the client can use, reduces the impact of failure from the clients perspective. The client can locate another site system to use and continue to operate without interruption. This approach applies to all site system roles.
There are two ways you can take advantage of having multiple site systems with the same role: u During the site architecture development stage, plan for multiple site systems with the same role. Also, plan to have an adequate number of site systems so that even if a site system fails at peak use, the remaining site systems have sufficient capacity to adequately support the clients until you recover the failed site system. If a site system fails, the load on the remaining site systems with the same role increases. The site continues to function and manage clients, but it might not perform as well because some of its capacity is lost. If the failed site system cannot be repaired quickly, and the site server is working properly, you can create additional site systems that the clients can use. From the clients perspective, having additional site systems helps avoids delays.
Set Up Site Systems on a Computer Other Than the Site Server

For some sites it is adequate to have only one site system with a specific role. For example, you might plan to set up only one CAP or only one distribution point for a site. From a recovery perspective, it is recommended that in this situation, you set up that site system on a computer other then the site server computer. Setting up the site server and site systems on separate computers minimizes the impact of a site server failure on the site clients. If the site server fails, then site systems running on other computers can continue to provide their respective functionality to the sites clients.
Back Up the Central Sites Control File Frequently

From the perspective of recovery, the central site has two unique characteristics that are important during recovery: u The central site is the only site in the hierarchy from which you can manage all clients in the hierarchy. Although each site contains data of its own clients of clients of lower level sites, the central site contains data of all the clients in all the sites of hierarchy. By using the central site, you can target any management task at any client of any site in the hierarchy. The central sites control file is not stored at any other sites database. SMS maintains an upto-date copy of the sites configuration file at each sites parent site, providing a built-in mechanism to back up site configuration files. If you need to recover a site, you can get the configuration data of the site you are recovering from its parent site. This, of course, is not the case with the central site, which has no parent site.
The central site is the most critical site in the hierarchy, but if you need to recover the central site, a crucial piece of information for the central site (the site control file) might not be up-to-date because it is not continually copied to a safe location. The most up-to-date copy of the central site control file would be from the most recent backup snapshot of the central site. It is reasonable for you to plan to frequently back up the central sites control file. Even if you back up the central site every day, back up the site control file a few times during the day. Depending on the activity level at the central site, back up the central site control file often enough that any change to the sites configuration is backed up. For more information about backing up the central sites control file, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Planning for Backup and Archive 475
Planning for Backup and Archive

When planning your site backup strategy, you must also plan an archive strategy. Then, develop a plan of how the backup and the archive operations will run together to ensure always having a recent, valid backup snapshot of the site. To have a complete site backup and archive plan, you must: 1. 2. 3. 4. Plan for backup. Plan for archive. Develop a backup and archive strategy. Document the backup and archive strategy.
Plan for Backup

From a backup perspective, it is recommended that you prepare sites as follows: u Configure SMS so that the sites data and the backup destination path are on two separate physical drives. This ensures that the backup task runs faster because it reads the data that it is backing up from one drive and at the same time, it writes data to another drive. While the backup task is running at the site, some site services are stopped, thus, data is not being processed. Therefore, plan for the site server to have adequate capacity to process the excess data after the backup cycle completes.
Plan for Archive

The first time the SMS backup task runs, it produces a backup snapshot, which you can use to recover your system in the event of a failure. When the backup task runs again during subsequent cycles, it creates a new backup snapshot that overwrites the previous snapshot. As a result, the site has only a single backup snapshot. This can be risky because an earlier backup snapshot wont be available if you need it. It is recommended that you archive the backup snapshot and store the archive in a safe place. It is also important to archive multiple backup snapshots for the following reasons: u u It is common for media to fail, get misplaced, or have only a partial backup stored on it. Recovering a failed site from an older backup is better than recovering with no backup at all. A corruption in the site can go undetected for several backup cycles. The SMS administrator must be able to go back several cycles and use the site backup snapshot before the corruption started. The site might have no backup snapshot at all, if, for example, the Backup SMS Site Server task fails. Because the backup task removes the previous backup snapshot before it starts to back up the current data, there will not be a valid backup snapshot.
An effective archive plan must meet the following criteria: u u u u u It must include an archive plan for every site in the hierarchy. You must be able to quickly retrieve the most recent backup snapshot from the archive location. The archive plan of the entire hierarchy must be cost effective for your organization. Which equipment will you use to archive backup snapshots, tape drives or CD-ROM burners? Is there adequate capacity in the link between the backup snapshot destination drive and the archive drive?
To develop an effective archive strategy for your site, you must make the following decisions:
Important
The SMS backup task does not validate the data that it transmits over the network when backing up the site to a remote backup destination. However, when archiving the backup snapshot from the local site to a remote location, data validity checking can be incorporated to ensure that the archived backup snapshot is valid. This is strongly recommended in configurations with low quality network between the backup destination and the archive location (if the connection fails more than once a month.)
Develop a Backup and Archive Strategy

When planning the backup and the archive operations for each site, it is important to tie both operations, so that together, they ensure always having a recent, valid backup snapshot of the site. When planning backup and archive throughout the hierarchy, it is sometimes beneficial to include multiple sites in one plan. There are a few parts of the backup and archive operations that you can decide to share between sites to increase efficiency. There are three basic backup and archive strategies that you can implement in an SMS hierarchy: u Separate backup and separate archive: u u u u u u u u Back up each site locally without sharing the backup destination between sites. Archive backup snapshots separately. Back up each site locally without sharing the backup destination between sites. Share an archive destination between sites. Share a backup destination between multiple sites. Share an archive destination between multiple sites.
Separate backup and shared archive
Shared backup and shared archive
Planning for Backup and Archive 477
To choose the backup and archive strategy that is most efficient in your organization, you must assess each site and make the following decisions: u u u Will the sites backup destination be on the local drive or on a remote drive? If the sites backup destination is on a remote drive, will the site share the backup destination with other sites? Will the site share the archive destination with other sites?
This section helps you develop a backup and archive strategy for your organization. It explains the advantages and disadvantages of each decision, and how each decision affects each backup and archive strategy.
Backup Destination on the Local Drive or on a Remote Drive?

When you configure the SMS backup task, you must specify the backup destination, which is where the backup snapshot is stored. You can specify a local drive or a remote drive. To make this decision, assess the following: u u u u u u u The quality and speed of your network. The size and speed of the site server local hard drive. Security requirements. The estimated size of the backup snapshot. Higher reliability because using a local drive will significantly reduce the risk of a corrupted backup due to network issues. Higher security because data is not transmitted over the network. Faster backup for two reasons: u u It is much faster to write to a local drive. When backing up the site database locally, SQL Server does not create a temporary copy of the database.
Benefits of backing up to a local disk:
Faster backups result in a shorter downtime for the site server. u Allows you to incorporate data validation checks when archiving the local backup snapshot into a remote location. Allows sharing of the backup destination.
Benefits of backing up to a remote disk are: u
Share a Backup Destination with Multiple Sites?

The sites that you plan to back up to a remote drive can share a single backup destination. You can configure the backup task of multiple sites to use the same backup destination.
The SMS backup task uses the backup destination that you specify to creates a folder structure that allows multiple sites to safely share the same location as their backup destination. The backup destination is set up so that it: u u Allows several sites to share a single backup destination. Prevents one sites backup snapshot from overwriting another sites backup snapshot in case there is an error. Reduced backup costs because multiple sites use a single high quality backup device such as a high capacity, high-speed tape drive. Simplified site configuration because multiple sites are configured to use the same backup destination. Simplified and less expensive archive of the backup snapshots because you archive only one location.
Benefits of shared backup destination: u u u
Share an Archive Destination With Multiple Sites?

Regardless of your plan to share backup destinations or not, you can plan to share archive destinations. Benefits of shared archive destination: u Reduces costs of archive because multiple sites use a single archive device.
Decide Which Backup and Archive Strategy to Implement

Each decision on these issues affects each backup and archive strategy differently. The following table illustrates the benefits that you gain, and the benefits that you lose with each decision: Table 13.2 Benefits of Backup and Archive Strategies
Backup and archive strategy Separate backup & separate archive Separate backup & shared archive Shared backup & shared archive Benefits of local backup Yes Yes No Benefits of shared backup destination No No Yes Benefits of shared archive destination No Yes Yes
Develop an effective backup and archive strategy that works in your organization to ensure that a recent backup snapshot is always available. When you do this, you simplify the recovery operation.
Planning to Simplify the Recovery Process 479
Document the Backup and Archive Strategy

After you decide which backup and archive strategy to implement in your hierarchy, document the details of that plan so that anyone in your organization can review the plan. Outline the backup and archive plan of each site in the hierarchy. Outline backup and archive procedures and schedules. List the backup destinations that are shared between multiple sites, and the sites that share them. List the archive destinations that are shared between multiple sites, and the sites that share them. Outline the risks you expect, and how you plan to handle them. You can include other information, such as who decides that a recovery is needed, and who performs them. Include any information that is helpful in your organization.
Planning to Simplify the Recovery Process

Even if you planned carefully and followed your plan to minimize the risk of failure in your site, your site still might fail. The recovery operation can be complex and can take a long time to complete. By planning ahead, you can simplify the process and reduce the time it takes to complete. To help simplify a recovery operation: u u u u u Ensure having reference sites. Allocate a server to set up the Recovery Expert Web site. Set your own password for the SMS Server Connection Account. Create your own SMS Client Connection account. Leverage Active Directory when site-to-site content signing is enabled.
Ensure Having Reference Sites

During regular site management you add, modify and delete configuration data such as software distribution objects. Any changes to these objects, such as changes to software distribution related object definitions are replicated down the hierarchy. Thus, a record of these changes exists on lower level sites. Any of those lower level sites, which is also a primary site, can be a reference site during a recovery operation of the originating site. A reference site helps recover object definitions such as software distribution related object definitions.
Figure 13.2 The concept of reference sites

Central Site
Site A (Primary)
Site B (Secondary)
Site C (Primary)
Site D (Secondary)
In the above diagram, Site A and Site C can take on the role of a reference site to help recover the central site. Site C can take on the role of a reference site to help recover Site A or the central site. No site can take on the role of a reference site when recovering Site B or Site D. Site B and Site D, which are secondary sites, cannot be reference sites.
Reference sites role during recovery

On large, busy sites, where changes to the site data are constant, there might be many changes done since the time of the last site backup until the time the site fails. When recovering such sites, it might be impossible to repeat the configuration changes that were not backed up. If such a site fails, all the objects, such as software distribution related objects, that you created since the last backup (besides possibly a few last minute changes that did not have a chance to replicate before the site failed) exist at child sites. However, you can no longer manage them you cannot delete or modify these objects, and they are considered orphaned. In this case, a recovery operation can be simplified if recovery tools can use designated reference sites to regain control of these SMS objects. During a recovery operation, you can designate any child primary site underneath the failed site as a reference site. Recovery tools use the data at the reference site to clone objects (including serial numbers and object IDs). The recovering site regains control of these objects after they are stored in the SMS site database. Aside from using reference sites to recover data, if possible, recovery tools use the sites site control file to recover site configuration data. Because parent site contains a copy of site control files of all its lower level sites, recovery tools obtain a copy of the failing sites site control file from its parent site. Recovery tools then use the configuration information from the file to reconfigure the site exactly as it was configured before it failed.
Designating reference sites

If all important sites, including the central site, in your hierarchy have child primary sites, then there is no need for any additional planning. Lower-tier primary sites are especially useful, because they can serve as reference sites when recovering any site above them. However, your hierarchy plan might include important sites to which only secondary child sites are connected, thus, these important sites will not have a reference site that recovery tools can use. In this case, especially if it is the central site, it is recommended that you set up an additional child primary site to serve as a dedicated reference site.
Note
Depending on your deployment, you can plan to set up a child primary site instead of one of the child secondary sites.
Setting up a site so it can serve as a reference site can be relatively inexpensive because a dedicated reference site does not need to manage any clients, or to run any SMS features. Follow these guidelines when designating reference sites: u u The reference site and the failed site are both at the same physical location. The network connection between the site and its reference site is of high quality to ensure that: u u u Definitions from the site are quickly replicated. This increases the chances of recovering all definitions that were made until the site failed. During a recovery operation, recovery tools can quickly obtain the definitions from the reference site.
When running recovery tools, you can specify multiple reference sites. This helps if there are connection problems, and one reference site has partial data. For important sites, it is safer to have multiple reference sites.
For more information about recovery tools and using reference sites during a recovery operation, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Allocate a Server to Set Up the Recovery Expert Web Site

To successfully recover a site, you must use recovery tools that guide you through the recovery process and automate some recovery tasks. The Recovery Expert is an essential recovery tool because it collects information about your failure scenario and produces a list of tasks that you must perform to recover your site. First you must set up a Recovery Expert Web site. You must allocate a server running Internet Information Services version 5.0 or higher to set up the Recovery Expert Web site on. Site administrators can then use Internet Explorer version 5.5 or later to connect to the Recovery Expert Web site and to run the Recovery Expert. For more information about the Recovery Expert Web site and the Recovery Expert, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
The number of servers that you allocate for the Recovery Expert Web site depends on the network design and domain security configuration in your organization. Ensure that every site can connect to at least one server that hosts the Recovery Expert Web site.
Set Your Own Password for the SMS Server Connection Account
When you initially set up a site, the setup program creates a default SMS Server Connection account (SMSServer_<SiteCode>) with a random password. When you recreate a site during a recovery operation, the setup program recreates the SMS Server Connection account with another random password, different from the original password. To enable proper communication between the recovering site server and all site systems in the site, you must propagate the new password of the SMS Server Connection Account to all site systems in the site. To accomplish this, you must perform a site reset, which can take some time to complete. By specifying your own password for the SMS Server Connection Account, you can avoid the need to perform a site reset during a recovery operation. When you originally set up the site, instead of allowing the Setup program to generate a random password, you can use the SMSAccountSetup.ini file or set up command-line parameters to specify your own password. Save your password in a secure place, and then reuse it when you recreate the site during a site recovery operation. This practice simplifies the recovery process. For more information about how to specify a password for the SMS Server Connection Account, see Chapter 5, Understanding SMS Security.
Create Your Own SMS Client Connection Account

While the site is healthy, create an additional client connection account using a name that is different from the default connection account, SMSClient_<SiteCode>. If account lockout is enabled, and if any client tries to access an account with a password that is not valid, then that account is locked out after the specified number of incorrect logon attempts. To avoid locking out clients, the password of a client connection account must never be changed. However, this is what happens when you run the fresh site install when recovering a site that was using the default account name and password. To prevent client lockouts resulting from a site recovery operation, you must create new SMS client connection accounts with new passwords before you experience a site failure. After the new account information is propagated to all domain controllers, CAPs, and clients, you can change or delete the original accounts. You can use the SMSAccountSetup.ini file or set up command-line parameters to specify your own accounts and passwords. Store the accounts and passwords information in a secure place, and then reuse it when you recreate the site during a site recovery operation. This practice simplifies the recovery process. For more information about creating SMS accounts and account lockouts, see Chapter 5, Understanding SMS Security.
Leverage Active Directory When Site-to-Site Content Signing Is Enabled

When site-to-site content signing is enabled, an Active Directory environment simplifies site recovery. The sites public key is stored in Active Directory. When the public key changes during a recovery operation, the new key automatically propagates to child and parent sites. In a non-Active Directory environment, you must manually propagate the recovered sites public key file to parent and child sites.
P A R T
Deployment
This part of the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide explains the tasks that are required to install a functioning Systems Management Server 2003 hierarchy.
C H A P T E R
1 4
Upgrading to SMS 2003
This chapter identifies the tasks you must perform to upgrade your site hierarchy. Before you upgrade to Microsoft Systems Management Server (SMS) 2003, ensure that you understand SMS 2003 architecture, and the concept and planning processes described throughout this book. To upgrade 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. To identify the upgrade issues that apply specifically to your SMS hierarchy and decide how to address them, see Chapter 11, Planning an Upgrade. This chapter assumes that you are familiar with SMS accounts-related security considerations. For more information about creating and configuring these accounts, see Chapter 12, Planning Your SMS Security Strategy. For more information about SMS 2003 security modes, see Chapter 5, Understanding SMS Security.
In This Chapter
u u Performing Site Upgrades Performing Post-Upgrade Tasks
488 Chapter 14 Upgrading to SMS 2003
Performing Site Upgrades

This section provides task lists to help you organize your upgrade. The task lists are followed by complete step-by-step instructions that guide you through the upgrade process. Specifically, this section describes the following upgrade tasks: u u u u Preparing a site for upgrade Upgrading primary site servers Installing SMS components Upgrading secondary site servers
Note
You can copy the SMS 2003 installation files from the SMS 2003 product CD to a network drive so that you can install SMS from the network.
Preparing a Site for Upgrade

Before you upgrade to SMS 2003, you must perform some preliminary tasks to ensure that the upgrade progresses smoothly. Use the task lists in this section to organize your pre-upgrade efforts.
SMS 2003 Deployment Readiness Wizard

The SMS 2003 Deployment Readiness Wizard is a tool that you must use before you upgrade to SMS 2003. You run the SMS 2003 Deployment Readiness Wizard on any primary site to help ensure that an SMS 2003 upgrade will be successful. The SMS 2003 Deployment Readiness Wizard identifies potential problems at the primary site and its child sites.
Important
You must run the SMS 2003 Deployment Readiness Wizard to proceed with an upgrade. In addition to this requirement, the SMS 2003 Deployment Readiness Wizard must complete without errors.
There are a number of pre-installation checks that you must perform before upgrading an existing SMS 2.0 site to SMS 2003. This tool helps you identify potential problems. For example, the SMS 2003 Deployment Readiness Wizard can check your site for unsupported platforms. Errors prevent the upgrade from continuing until all the errors are corrected. For more information about the list of the tests that are performed and how to correct the errors, see Chapter 11, Planning an Upgrade. You can run the DRW.exe file from the following folder on the SMS 2003 product CD: SMSSETUP\BIN\I386\. Also, the tool will run automatically when you start SMS 2003 Setup.
Performing Site Upgrades 489
To run the SMS 2003 Deployment Readiness Wizard by using DRW.exe

1. 2. 3. On the Welcome page, click Next. On the Tests page, select the tests that you want to run, and then click Next. On the Completing the Systems Management Server 2003 Deployment Readiness Wizard page, click Finish. The SMS 2003 Deployment Readiness Wizard runs the selected tests. After completion, you can view the detailed test results by selecting the site and clicking Details. You can also use the setup command-line options to run the SMS 2003 Deployment Readiness Wizard and for software distribution scenarios. The following table represents examples of entries that you might type at the command line. Table 14.1 SMS 2003 Deployment Readiness Wizard Command-Line Options
Entry /? /h /q Option Help mode Description Defines the supported command-line options. No tests will be performed. Any additional specified command-line options are ignored. Runs the tool without displaying the progress and results summary. If you do not specify any other command-line option, the tool runs the primary site option. Runs the tool on the primary site. You cannot run the tool on any secondary sites when you select this option. Runs the Deployment Readiness Wizard on all the secondary sites. Runs the Deployment Readiness Wizard on the specified secondary sites. The ### characters represent the threeletter site code of the secondary site. You can specify multiple secondary sites by using a space as a separator between the secondary site codes. Copies the report file to the specified drive location. Path represents the drive and folder where the reports are saved. The drive folder must exist, and the Deployment Readiness Wizard must have permission to copy files to it. Copies the report file to the specified network location. The network folder must exist and the Deployment Readiness Wizard must have permission to copy files to it. In addition, the directory must already be shared.
Quiet mode
/p /s /s:###
Primary site All secondary sites Specific secondary sites
/r:<path>\logs
Copy report to specified drive location
/r:\\<computer Copy report to specified network location name>\ <share>\logs
All Sites Task List

These site preparation tasks apply to all of your SMS 2.0 sites: u Plan your upgrade. The concept and planning processes described in the previous chapters focus on gathering information and making choices. Specifically, Chapter 11, Planning an Upgrade, focuses on gathering information and making choices for upgrading to SMS 2003. You use the results of your documentation and decision-making efforts (clearly defined high-level goals, hardware and software requirements, the site hierarchy structure, and site system roles) to supply the answers to questions that arise during upgrade. u Ensure that your existing site is running SMS 2.0 SP4 or later. If the site that is being upgraded is running SMS 2.0 SP3 or earlier, the upgrade will not complete successfully. Also, all SMS 2.0 sites that report directly to the upgraded site must be running SMS 2.0 SP4 or later before the parent site is upgraded to SMS 2003, even if you intend to upgrade the child and secondary sites. u Ensure that your existing site server supports SMS 2003. Before you upgrade to SMS 2003, ensure that your site server meets the minimum system requirements for the primary or secondary site that you plan to install. If the site server does not meet the system requirements, the upgrade might fail. For more information about system requirements and supported platforms, see the Getting Started chapter in this book. u Adjust the number of SMS licenses on the site server. To add additional SMS 2003 licenses when they are required, on the site server, navigate to:
Start X Program menu X Administrative Tools X Licensing
Primary Sites Task List

Use this task list to prepare your primary sites for the upgrade: u Ensure that your installation of Microsoft SQL Server supports SMS 2003. Check the version number of the installation of SQL Server you are using for the SMS site database. SMS 2003 supports SQL Server 7.0 SP3 or later. If you have an earlier version of SQL Server, you must upgrade SQL Server before you upgrade to SMS 2003. Otherwise, the upgrade will fail. For more information about system requirements and supported platforms, see the Getting Started chapter in this book. u Test the SMS 2.0 site database. It is recommended that you use setup /testdbupgrade on a copy of your database to verify that the database portion of the upgrade will be successful. This procedure should be performed only on a copy of your SMS 2.0 database.
To test the SMS 2.0 site database by using /testdbupgrade

1. Back up your database. Obtain a copy of the site database backup created by a recent SMS backup task. An alternative method is to stop all SMS services on the SMS site server and SQL Server, then use SQL Server Enterprise Manager to make a backup of the SMS site database.
Note
Setup /testdbupgrade fails on SMS site databases that are restored from an SMS 2003 site database with SQL Server database replication enabled. When SQL Server database replication is enabled for the SMS 2003 site database, the computer running SQL Server modifies the SQL tables that are included in the publication. When the database is restored to another database, the setup /testdbupgrade fails on that restored SMS site database.
To work around this situation, disable publishing on the SMS site database before you back up the SMS site database. 2. On another computer running the same version of SQL Server, restore the database you just backed up as follows.
Note
You do not need to install an SMS site on this server.
u u u
Manually create a new database with the same name as the one you backed up. Default data/log file sizes of 1 MB are adequate. Copy the database backup file from the SQL Server database to a local drive on the test computer running SQL Server. Restore the database using SQL Server Enterprise Manager. Because the drive letters might be different on your test SQL server, you might need to modify the destination drive and file properties during the restore operation. On the restored SQL Server database, type the following at the command prompt: setup.exe /testdbupgrade <database name>. If you successfully run the database upgrade test, the database portion of the upgrade process on your actual site database will also be successful. Any problems encountered by the test upgrade must be corrected before upgrading your production site. You can review the results of the test in SMSsetup.log, which is in the root of the system drive.
3.
Caution
Because the /testdbupgrade setup option destroys data, ensure that you use this setup option only on a copy of your SMS site database.
Set the required SMS site database free disk space. If you do not have enough free disk space on the SMS site database, then the upgrade might fail. This free space is used temporarily during the upgrade process. For more information about calculating the required SMS site database free disk space, see Chapter 11, Planning an Upgrade. If the unused space in the SMS site database log is larger than the Software Inventory table, then you have sufficient space to ensure a smooth database upgrade. After the upgrade, you can compact the SMS site database and adjust the SMS site database log to their former sizes. If the Software Inventory table is larger than the unused space in the SMS site database log, you should increase the log size. To specify how the file should grow, see the SQL Server Help. You can access the SQL Server Help within the SQL Server Enterprise Manager console. You can select from the following options: u u u To allow the currently selected file to grow as more data space is needed, select Automatically grow file. To specify that the file should grow by fixed increments, select In megabytes and specify a value. To specify that the file should grow by a percentage of the current file size, select By percent and specify a value.
Note
The maximum database size is determined by the amount of disk space available and the licensing limits determined by the version of SQL Server you are using.
Perform routine maintenance on your SMS site database. Before and after any major database operations, such as upgrading your database to SMS 2003, it is important to perform database consistency checks and other database management tasks. These tasks should include backing up the site databases. For more information, see Chapter 13, Maintaining and Monitoring SMS Systems, and Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Uninstall logon points. Logon points are not supported in SMS 2003. Before upgrading to SMS 2003, you must turn off logon discovery and logon installation and remove logon points from all domain controllers. This process takes time and involves replication between all domain controllers in the domains managed by SMS. Do not immediately proceed with the upgrade process after you turn off logon installation. If you do, clients that are not supported by SMS 2003 might get failed installations of SMS 2003.
Note
All logon points must be removed from all domain controllers. Shared logon points must be removed and the folders must be deleted. To ensure that you are ready to proceed, check the logon scripts and ensure that Smsls.bat is not present.
Remove Crystal Reports. When you upgrade a primary site server from SMS 2.0 to SMS 2003, the following conditions apply: u u u You cannot use Report Viewer to view reports that were created with Crystal Reports included in SMS 2.0. You cannot use Report Viewer to access an SMS 2.0 site database. SMS 2003 does not upgrade or remove Crystal Reports.
When you upgrade a primary site from SMS 2.0 to SMS 2003, you should continue to use Crystal Reports for SMS 2.0 if: u u You want to continue using the stand-alone version of Crystal Reports to view the reports that you created using Crystal Reports for SMS 2.0. You want to access Crystal Reports on SMS 2.0 sites in your hierarchy.
For more information about SMS 2003 reporting, see Chapter 11, Creating Reports, in the Microsoft Systems Management Server 2003 Operations Guide.
To remove Crystal Reports for SMS 2.0

1. 2. 3. In Control Panel on the primary site server, open Add or Remove Programs. In the Currently installed programs list, click Seagate Crystal Info for SMS, and then click Change or Remove Programs. On the primary site server, navigate to the following path: \SMS\CInfo\ Delete all folders and files under this directory. u Remove SMS 2.0 software metering. Before upgrading, remove SMS 2.0 software metering settings from your site server. Before upgrading any site system that is acting as a software metering server: u u On the Software Metering Server tab, open the Properties dialog box. Clear the Use this site system as a software metering server check box.
After the upgrade completes, you can remove the remaining SMS 2.0 software metering settings, although it is not required.
To remove other SMS 2.0 software metering settings

1. 2. 3. 4. 5. u Delete the SWMAccount user account if there are no other sites using it. Open ODBC Data Source Administrator, click the System DSN tab, select the LicAdmin and License Server Local DSN entries, if present, and then click Remove. Delete the \SWMtr and \SMS\Licmtr directories from your site server, if present. Remove the license metering database from SQL Server. Disable the Software Metering Client Agent on all sites.
Back up your SMS 2.0 sites. It is very important to perform and archive backups before and after you upgrade. Because these are each unique backups, it is essential that you have one of these backups available if the upgrade fails. Before the upgrade, run the backup task to back up your sites data. By default, the SMS backup task does not back up the SMS_def.mof file. You must back up the SMS_def.mof file separately. For more information, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Note
You cannot restore an SMS 2.0 backup snapshot to an SMS 2003 site. Use the SMS 2.0 backup snapshot only if the upgrade failed.
Customized files are overwritten during an upgrade. However, you can export your SMS_def.mof files for use in SMS 2003. Table 14.2 Custom Files to Back Up in Preparation for a Primary Site Upgrade
File Backup control file Site control file SMS.def.mof Folder \<SMS Folder>\inboxes\smsbkup.box\smsbkup.ctl \<SMSFolder>\inboxes\Sitectrl.box\sitectrl.ct0 \<SMS Folder>\inboxes\clifiles.src\hinv
For more information about backup and recovery in SMS 2.0, see Chapter 18, Maintaining SMS Systems, in the Microsoft Systems Management Server 2.0 Administrators Guide.
Upgrading Primary Site Servers

After you complete the tasks in the primary site task list, upgrade your primary site.
To upgrade a primary site

1. Log on to the primary site server that you are upgrading. Use an account that is a member of the local Administrators group on that computer. By default, members of the Domain Administrators group are members of the local Administrators group.
2. 3. 4. 5. 6. 7.
Insert the SMS 2003 product CD into the drive, or connect to a copy of the installation files on a network drive. On the Welcome page of the SMS Setup Wizard, click Next. Setup detects your SMS 2.0 installation and offers to upgrade it. Click Next. On the Setup Options page, select Upgrade an existing SMS installation, and then click Next. The Licensing window appears. After reading the license and accepting its terms, select I Agree, and then click Next. If you are using a computer other than the site server for your SMS site database, the SMS Provider Information page appears. If your SMS site database is on a different computer from the site server, you can install the SMS Provider on either computer. u If only a few SMS Administrator consoles access the SMS site database, and you have a computer running SQL Server that shares the SMS site database, then install the SMS Provider on the site server. If a large number of SMS Administrator consoles access the SMS site database, then install the SMS Provider on the computer running SQL Server.
Select the location where you want to install SMS Provider, and then click Next. 8. On the Completing the Systems Management Server Setup Wizard page, click Finish.
Caution
If the site you are upgrading has parent sites that have not been upgraded to SMS 2003, and you want the site to continue reporting to those parent sites, cancel the upgrade before clicking Finish and upgrade the parent sites. Choosing Cancel during a site upgrade does not undo the upgrade. The SMS 2.0 site you are upgrading will not be left intact if you choose to cancel during the site upgrade.
If the site you are upgrading is a child site, a message appears advising that you should start upgrading the sites at the top of the hierarchy and proceed down through child sites. For more information, see Chapter 11, Planning an Upgrade.
9.
When a message appears indicating that SMS is upgraded, click OK.
After the upgrade is complete, SMS 2003 uses the upgraded data to configure your upgraded site. This process, which can take 30 minutes or more, is indicated by increased activity in the SMS Executive service. You can monitor this activity with the Microsoft Windows Task Manager.
The upgrade process converts only the components that were installed in the SMS 2.0 site. You must modify the site to install components that are new to SMS 2003 or that were not installed on the SMS 2.0 site you upgraded.
Note
SMS 2003 software metering is installed, but not enabled, regardless of whether it was installed in SMS 2.0 prior to the upgrade. It is not considered an additional component.
You might want to view the upgraded data before you install new SMS 2003 components or any other components that were not installed on your SMS 2.0 site. To do this, you must wait until the initial configuration activity is complete.
Installing SMS Components

The upgrade process converts only the components already installed in the SMS 2.0 site. With the exception of software metering, components that were not installed on the original site are not installed during the upgrade. To install components on your upgraded site that were not installed before the upgrade, run SMS Setup again from the product CD and select the options you want to modify in the existing installation.
To modify a newly upgraded primary site

1. 2. 3. 4. 5. 6. 7. Log on to the primary site server that you are upgrading. Use an account that belongs to the local Administrators group. Insert the product CD into the drive, or connect to a copy of the installation files on a network drive. On the Welcome screen, click Next. Setup detects your SMS 2003 installation. To view your setup options, click Next. On the Setup Options page, select Modify or reset the current installation, and then click Next. On the Setup Installation Options page, select the components that you want to install, and then click Next. On the next three pages, you can make changes to your SQL Server database. The default settings are the settings used for your SMS 2.0 site before the upgrade. On each of the following pages, accept the defaults, and then click Next: u u u SMS Service Account Information SQL Server Database or Name Modification Windows Authentication previously known as Integrated Security for SMS Database
8.
On the confirmation page, click Finish. After SMS Setup installs the components on your site, a message appears indicating that the setup was successful.
Note
Setup writes the settings to the SMSsetup.log file, which is located at the root of your system drive. You can view this log file at any time.
Upgrading Secondary Site Servers

When a parent site is upgraded, its secondary sites are not automatically upgraded. This makes it easy for you to maintain SMS 2.0 secondary sites in your hierarchy to support clients running operating systems that are not supported by SMS 2003. In some ways, upgrading a secondary site is easier than upgrading a primary site because a secondary site has no SMS site database.
Note
Status information from the secondary site that you upgrade does not include information about the progress of the upgrade. After the upgrade is complete, the parent site receives a site control file from the secondary site. This updates the version information of the secondary site in the primary SMS site database and SMS Administrator console.
Secondary Site Upgrade Methods

You can use one of the procedures described in this section to upgrade your secondary site. There are three secondary site upgrade methods: Download the upgrade from the parent site Use this method when the secondary site does not have an administrator who can perform the upgrade and when the effect on intersite network bandwidth is not a concern. You can upgrade up to five secondary sites at one time. To download the upgrade from a parent site, see the Upgrading a Secondary Site from the Parent Site section later in this chapter. Initiate the upgrade from the parent site using source files located at the secondary site Use this method when you want to control the upgrade from the primary site, but want to minimize the effect on intersite network bandwidth. To start the upgrade from the parent site, see the Upgrading a Secondary Site from the Parent Site section later in this chapter.
Upgrade locally at the secondary site server by using the SMS 2003 product CD Use this method when the secondary site has an administrator who can perform the upgrade or when the effect on intersite network bandwidth is a concern. To perform the upgrade locally at the secondary site server, see the Upgrading a Secondary Site Locally section later in this chapter.
Note
After you run the Secondary Site Upgrade Wizard at the primary site, the secondary sites properties appear in the details pane when its parent site is selected in the console tree. However, the secondary sites properties do not appear under the parent site in the console tree until the primary site receives the site control file from the upgraded secondary site. This can take up to 24 hours.
Upgrading a Secondary Site from the Parent Site

This section describes how to use the Upgrade Secondary Site Wizard to initiate an upgrade from the parent SMS 2003 site.
To upgrade a secondary site from the parent site

1. At the parent site, open the SMS Administrator console and navigate to the parent site:
Systems Management Server X Site Database <site code - site name> X Site Hierarchy X <site code - site name>
2. 3. 4. 5.
Right-click the site name in the console tree, click Task, and then click Upgrade Secondary Sites. On the Welcome page, click Next. On the Select Sites page, select the secondary sites that you want to upgrade, and then click Next. You can upgrade up to five secondary sites at a time. On the Installation Source Files page, specify either that installation files are to be downloaded from the primary site server or that the files are already on the secondary site server. Click Next. If you specify that the files are located on the secondary site server, the product CD must be inserted into the drive on the site server. Alternatively, you can use an image of the SMS 2003 product CD on the local disk or removable media or on a mapped network connection at the secondary site server.
6.
On the Complete the Upgrade Secondary Site Wizard page, click Finish.
If an upgrade stops responding, ensure that the system requirements are met at the secondary site and that the installation source files are accessible. Then, initiate the upgrade again.
Performing Post-Upgrade Tasks 499
Upgrading a Secondary Site Locally

This section describes how to use the Setup program on the SMS 2003 product CD to upgrade a secondary site at the secondary site server.
To upgrade a secondary site server from the SMS 2003 product CD

1. Log on to the secondary site server that you are upgrading by using an account that is a member of the local Administrators group on that computer. By default, members of the Domain Administrators group are members of the local Administrators group on computers in the domain. Insert the product CD into the drive. Or, you can connect to an image of the SMS 2003 product CD on a mapped network drive, a hard disk drive, or a removable drive of the secondary site. Click Set Up Systems Management Server 2.0. On the Welcome page, click Next. On the System Configuration page, click Next. On the Setup Options page, select Upgrade an existing SMS installation, and then click Next. On the Completing the Systems Management Server Setup Wizard page, click Finish. Setup removes SMS 2.0 components from all site systems and installs SMS 2003 on the site server. When the message appears that SMS is installed, click OK.
2.
3. 4. 5. 6. 7.
8.
Because the upgrade process only converts components that you were using in your SMS 2.0 site, you must modify the site to install components that are new in SMS 2003. The procedure is essentially the same as the procedure for modifying a newly converted primary site. For more information, see the Installing SMS Components section earlier in this chapter.
Performing Post-Upgrade Tasks

After you upgrade a site, you must perform several additional tasks. You perform most of them from the SMS Administrator console. These tasks include: Upgrade Legacy Client to Advanced Client on computers running Windows 2000 or later operating systems When you upgrade the SMS 2.0 site to SMS 2003, the Legacy Client is installed on existing SMS 2.0 clients running Windows 2000 or later 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 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.
Status filter rules after upgrading the site server to Windows Server 2003 If you have configured status filter rules to send a network message when an event occurs, and you upgrade the site server to Microsoft Windows Server 2003, the status filter rules will no longer run. By default, the messenger service in Windows Server 2003 is disabled. To allow these status filter rules to run, enable and start the Messenger service. Database maintenance and consistency checks It is a good idea to back up your upgraded site and to perform database consistency checks. For more information, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide. This is a good time to schedule the backup task. For more information about backup and recovery, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide. Differences between the SMS_def.mof files at different sites of the same version in the hierarchy can lead to conflicting hardware inventory data. To prevent conflicts, you should make sure that each site of the same version in the hierarchy uses the same hardware inventory definitions. For more information about how to standardize the SMS_def.mof files in your hierarchy, see Chapter 6, Understanding Interoperability with SMS 2.0. For more information about how to restore your customized SMS_def.mof files after you upgrade, see Chapter 2, Collecting Hardware and Software Inventory, in the Microsoft Systems Management Server 2003 Operations Guide. Site configuration You must configure the site settings for all new SMS 2003 sites. This applies to newly installed SMS 2003 sites and to sites upgraded to SMS 2003 from SMS 2.0. Configuration settings from SMS 2.0 are preserved during an upgrade. For example, you must configure the site boundaries and enable client installation methods to upgrade clients and populate the SMS site database. In general, perform post-upgrade tasks in the following order: 1. Configure all site settings. u u u Assign new site system roles. Specify the IP subnets or Active Directory sites that define your site boundaries. Enable resource discovery methods.
For more information about configuring your SMS 2003 sites, see Chapter 10, Planning Your SMS Deployment and Configuration, and Chapter 15, Deploying and Configuring SMS Sites. 2. Enable client installation methods. For more information about client installation methods, see Chapter 17, Discovering Resources and Deploying Clients.

SMS 2003 includes a software update management feature. Some components of this feature are automatically installed with SMS 2003. Other components require a Web download and separate installation on the site server. See Table 14.3 for component installation information. Earlier versions of the software update management components were released as value-added features in the SMS 2.0 Software Update Services Feature Pack. For information about upgrading SMS 2.0 sites that have the software update management tools previously installed, see the Upgrading SMS 2.0 Software Update Management Features to SMS 2003 section later in this chapter. For system requirements, see the Getting Started chapter in this book. For information about interoperability issues in a mixed-site hierarchy, see Chapter 6, Understanding Interoperability with SMS 2.0.
Installation
Table 14.3 shows the components and installation details of the SMS 2003 software update management feature. Table 14.3 Software Update Tool Installation Details
Feature Distribute Software Updates Wizard Software updates installation agent Installation Details Installed by default on the SMS 2003 site server and SMS 2003 Administrator console. Installed by default on the SMS 2003 site server. Distributed to SMS client computers automatically when you run the Distribute Software Updates Wizard to create and advertise software update packages. Installed by default on SMS 2003 reporting points and the SMS 2003 Administrator console. Download from the Web at http://www.microsoft.com/smserver/downloads. Separate installation on an SMS site server. Download from the Web at http://www.microsoft.com/smserver/downloads. Separate installation on an SMS site server.
Software update reports Security Update Inventory tool
Microsoft Office Inventory tool for updates
Upgrading SMS 2.0 Software Update Management Features to SMS 2003

Table 14.4 lists the actions that are required for upgrading an SMS 2.0 site to SMS 2003 when the SMS 2.0 versions of the SUS Feature Pack tools are already installed. Table 14.4 Software Update Tool Upgrade Requirements
Feature Distribute Software Updates Wizard Action Remove the SMS 2.0 version before upgrading to SMS 2003. You can keep associated programs, advertisements, and packages that were created with the wizard. For information about upgrading SMS 2.0 software update packages to SMS 2003, see the Software Update Management section in Chapter 6, Understanding Interoperability with SMS 2.0. No separate action required. The SMS 2.0 version of this component is removed when you remove the Distribute Software Updates Wizard from the SMS Administrator console, but this component remains in the packages previously created by the Distribute Software Updates Wizard to ensure that these packages are not broken during migration or upgrade. Remove the SMS 2.0 version before upgrading to SMS 2003. This feature is replaced with the Reporting features in SMS 2003. If you created any custom software update reports, save them to a file so you can import them into SMS 2003 Reporting. As a best practice, remove these tools and install the SMS 2003 versions by using the following procedure after you finish installing and configuring SMS 2003.
Software updates installation agent
Web reporting add-in
Software update reports
Security Update Inventory tool Microsoft Office Inventory tool for updates
Use the following procedure to upgrade the SMS 2.0 version of the Security Update Inventory tool to the SMS 2003 version.
To upgrade the SMS 2.0 Security Update Inventory tool to the SMS 2003 version
Important
The following procedure upgrades the Security Update Inventory tool and its associated collections, packages, programs, and advertisements to SMS 2003 versions. While it does not remove these objects from the SMS site database, the upgrade process replaces any custom properties you set on these objects with the default values. If you have made such changes and want to preserve them, make a note of the configuration settings for these objects before you perform this upgrade.
1. 2. 3. 4. 5. 6.
On an SMS 2003 site server, download the installation program for the tool from http://www.microsoft.com/smserver/downloads. Run the installation program (SecurityPatch_xxx.exe, where xxx is the locale code of the package; for example, SecurityPath_ENU.exe for the English language version). When prompted to remove the previous version, click OK. When prompted to remove packages, collections, and advertisements, click No. When prompted to replace the existing package, collections, and advertisements during the installation of the new version, click OK. Following setup, review the configuration settings for the collections, packages, programs, and advertisements for the tool. If necessary, replace the default settings with the custom settings appropriate for your site.
This procedure describes the process of upgrading the Security Update Inventory tool. To upgrade the Microsoft Office Inventory tool for updates, follow the same steps, but substitute the file name OfficePatch_xxx.exe for SecurityPatch_xxx.exe.
Other Issues Affecting an Upgrade

The following are other points to consider when performing an upgrade of the SMS 2.0 version of the software update management tools: u SMS 2.0 software update packages created by the Distribute Software Updates Wizard are only upgraded to SMS 2003 packages when they are opened and saved in the SMS 2003 version of the Distribute Software Updates Wizard. For more information, see the Software Update Management section in Chapter 6, Understanding Interoperability with SMS 2.0. The SMS 2.0 Administration Feature Pack tools are not compatible with SMS 2003. You should remove these tools prior to an upgrade of the SMS 2.0 Administrator console to SMS 2003. Compatible versions of these tools will be available for SMS 2003, but are not included in this release.
C H A P T E R
1 5
Deploying and Configuring SMS Sites

You can install Microsoft Systems Management Server (SMS) 2003 in different configurations, depending on your business and technical needs. Your satisfaction with this product depends on your understanding of basic concepts. The concept and planning processes described in the previous chapters focus on gathering information and making choices. You use the results of your documentation and decision-making efforts (clearly defined high-level goals, hardware and software requirements, site hierarchy structure, site system roles, and security measures) to answer questions that arise during installation. SMS 2003 installation is directed by programs called wizards, which guide you through extended processes and help you accomplish common tasks. You complete preliminary system preparations and choose a setup option. Then, either the Express Setup Wizard or the Custom Setup Wizard guides you through one of three installation processes: primary site server, secondary site server, or SMS Administrator console. You complete the installation process by manually configuring the site boundaries and other site and component settings in the SMS Administrator console.
In This Chapter
u u u u u u Preparing for Installation Starting the Installation Process Installing a Primary Site Installing a Secondary Site Installing the SMS Administrator Console and Related Tools Configuring Your SMS Sites and Hierarchy
506 Chapter 15 Deploying and Configuring SMS Sites
Preparing for Installation

You must have Microsoft SQL Server installed prior to installing SMS. You can install SQL Server on the local site server or on a remote site server. Ensure that the version of SQL Server meets all the SQL Server requirements listed in the Getting Started chapter in this book.
Note
Before you install SMS, ensure that the time setting on the computers in your organization are synchronized, and then perform a network time synchronization routinely. Scheduled events in SMS occur at the scheduled time in each time zone. For example, if you advertise a program to run at 2:00 P.M. on Wednesday, the program will run at 2:00 P.M. in the Chicago site, at 2:00 P.M. in the Denver site, and at 2:00 P.M. in the Los Angeles site.
If you have the SMS site database on the same computer as the site server, SMS Setup creates the necessary databases if you have not already done so and tunes SQL Server specifically for SMS.
Note
To complete the installation of the SMS Administrator console, you must have the name of the computer that has the SMS Provider. Setup prompts you for this information when you install the SMS Administrator console.
Installation Requirements
For best results, install SMS 2003 on a fresh installation of an SMS 2003 supported operating system. Ensure that the computer meets all the site server system requirements listed in the Getting Started chapter in this book.
Note
If you are using an international version of the operating system, ensure that the code page is appropriate for the operating system. For more information about multilanguage site hierarchies, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Preparing for Installation 507
Security Modes
You can install SMS 2003 in either standard security or advanced security mode. For more information about SMS 2003 security modes and planning considerations, see Chapter 5, Understanding SMS Security, Chapter 10, Planning Your SMS Deployment and Configuration, and Chapter 12, Planning Your SMS Security Strategy.
Setup Options
There are two options for installing a primary site: Express Setup and Custom Setup. Regardless of the installation option you choose, you can review all of the information that you enter at the end of the setup process before you make any changes to your system. Until you click Finish on the final Setup page, you can go to previous pages and change the information you have entered, including the choice between Express Setup and Custom Setup. For more information about Setup option planning considerations, see Chapter 10, Planning Your SMS Deployment and Configuration. Table 15.1 describes which SMS software components are available with each setup option. This information can help you plan which type of setup to use for a specific location. Table 15.1 Component Data by Setup Option
SMS Administrator console installation Not available Installed Not available Not available
Option Site server
Custom primary site installation Installed
Express primary site installation Installed Installed Installed Installed
Secondary site installation Installed Available Optional Not available
SMS Administrator Installed console Remote Tools Optional
Package Optional automation scripts
By default, the Express Setup option: u u u u u Installs all core SMS components and client agents. Enables Legacy Client Push Installation. Enables all discovery methods, except Network Discovery. Creates all necessary service accounts. Enables the client access point (CAP), management point, and distribution point roles on the site server.
Table 15.2 lists default settings that result from the Express Setup option. Use this table as a configuration guide during a Custom Setup installation to help avoid settings that cause excessive network bandwidth. Table 15.2 Express Setup Default Settings
Feature Network Discovery Windows User Group Discovery Windows Networking User Account Discovery Heartbeat Discovery Legacy Client Push Installation Advertised Programs Client Agent Remote Tools Client Agent Hardware Inventory Client Agent Summarizers (summarize and replicate) Collection update Package distribution point update Software Metering Client Agent Software Inventory Client Agent Enabled or disabled Disabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled Disabled Disabled Disabled Interval Not applicable One day One day One day for Express Setup Not applicable One hour Not applicable One day 12 hours One hour Not applicable Not applicable Not applicable
SQL Server Preparation

An SMS 2003 primary site must have access to SQL Server. You can install SQL Server on the computer that is used as the primary site server. Or, to separate the data input and output (I/O) load and SMS server resource demands, you can install SQL Server on a different computer in the SMS site. For more information about planning where to install the SQL Server database, see Chapter 8, Designing Your SMS Sites and Hierarchy.
Note
After SMS 2003 site installation is complete, you cannot move the SMS Provider without reinstalling the site.
Preparing for Installation 509
Configuring SQL Server for SMS

To configure SQL Server for SMS, you must complete the following tasks. You can perform these tasks after you install SQL Server, but you must complete them before you install SMS 2003.
Note
SMS 2003 supports only the SQL Server default instance. SQL Server named instances are not supported in SMS 2003. This applies only to SQL Server 2000 or later. For more information, see the SQL Server Help.
This section does not cover: u u u Creating an account to access SQL Server. Creating a SQL Server account. Creating a SQL Server Login ID.
For more information about creating and configuring these accounts, see Chapter 12, Planning Your SMS Security Strategy.
Tuning SQL Server

Consider performing the following tasks to improve performance: Ensure that SQL Server has enough user connections You can specify this number during SMS Setup. It is recommended that you configure SQL Server for an unlimited number of user connections. This is the default value for SQL Server. Set the SQL Server Memory option The default SQL Server Memory option is set to dynamically configure SQL Server memory. This setting dynamically adjusts the amount of memory that is used based on demand. The maximum database size is determined by the amount of disk space that is available and the licensing limits determined by the version of SQL Server you are using. If the SQL Server Memory option is set to dynamically configure SQL Server memory, SQL Server can consume too much memory and slow down performance. Table 15.3 lists the recommendations for tuning the Memory option. These recommendations are based on the assumption that the computer running SQL Server is a member server that is dedicated to SMS.
Table 15.3 Recommendations for SQL Server Memory

Server memory 128 MB 256 MB 384 MB 512 MB and greater Operating system and SMS services 80 MB 160 MB 224 MB 256 MB 48 MB 96 MB 160 MB 256 MB and greater SQL Server
For more information about performance and tuning, see the SQL Server product documentation. Ensure that the computer running SQL Server is accessible from the site server SQL Server might not be on the same computer as the primary site server. If this is the case, ensure that the SMS Service account and either the SMS SQL Server Login ID or the Windows Group account that is used by SMS to access the SQL Server database has network access to the computer running SQL Server. To check whether this network access is available, make a network connection to the computer running the SQL Server account from the SMS SQL Server Login ID or the Windows Group account. Ensure that SQL Server starts automatically at system startup To ensure automatic SQL Server startup at system startup, run SQL Server Setup, select Set server options, and then click Auto-start server at boot time.
SQL Server Database Replication

This section describes the manual setup of transactional SQL Server database replication by using a remote distributor that is running on the subscriber. In addition, the distributor has to be configured first, and it has to be specified on the publisher computer. You can run MpPublish (MpPublish.vbs) from the following folder on the SMS 2003 product CD to publish the table and store procedures: SMSSETUP\BIN\I386\.
To set up SQL Server database replication for a remote management point

1. At the command prompt, type the appropriate command, as in the following example:
MpPublish.vbs SiteDatebaseName [PublisherMachineName] [SQLUserName] [SQLPassword]
u u 2.
The local computer name is used if PublisherMachineName is not specified. Windows authentication is used if SQLUserName is not specified.
Press ENTER.
Starting the Installation Process 511
3.
If successful, a status message appears: MpPublish completed successfully.
Note
If this procedure is performed on a computer running Microsoft Windows Server 2003, the MpPublish completed successfully message appears on the command prompt, instead of in a status message.
4. 5.
Configure the subscriber. Start the snapshot agent on the distributor.
For more information, see the SQL Server Help.
Starting the Installation Process

When you insert the SMS 2003 product CD in your drive, the first page that appears gives you several options. The instructions in this chapter assume that you are installing SMS 2003 directly from the product CD. However, you can also copy the directories and files from the product CD to a network drive and install them from there. In this case, you run Setup.exe in the root of the copied folder tree to install SMS 2003.
Note
Close any open dialog boxes, other than the Setup dialog box, before continuing with setup. This includes terminal services windows.
After you install SMS, wait 30 minutes before opening the SMS Administrator console. This waiting period allows the initial SMS configuration process to complete. You can verify if this process is completed by checking the level of CPU activity on your computer. When the activity level returns to normal, you can open the SMS Administrator console.
Caution
Do not install non-SMS files and folders within the SMS folder. Any attempt to uninstall SMS deletes all files, folders, and applications within the SMS folder, including all non-SMS files.
Upgrading or Removing a Site

If you want to upgrade your site from an earlier version of SMS, see Chapter 11, Planning an Upgrade, and Chapter 14, Upgrading to SMS 2003. If you want to remove an SMS 2.0 site, use SMS 2.0 Setup.
Running Setup
SMS Setup provides the following options: Install an SMS primary site When installing an SMS primary site, choose Express Setup or Custom Setup. For a description of both of these, see the Setup Options section earlier in this chapter. A primary site is the basic management unit in SMS. A primary site includes a SQL Server database and SMS administrative tools, such as the SMS Administrator console. Each SMS hierarchy must have at least one primary site. Install an SMS secondary site Before an SMS secondary site can be installed, an SMS primary site must exist. Secondary sites send their data to the primary SMS site database. You do not install SQL Server or SMS administrative tools on a secondary site. Install the SMS Administrator console and related utilities The SMS Administrator console is installed automatically on all primary sites. To distribute administrative tasks among various personnel in your organization, you might choose to install the SMS Administrator console on other computers. Install the Recovery Expert To successfully recover a site, you can use the SMS recovery tools that guide you through the recovery process and automate some recovery tasks. The Recovery Expert Web site is an essential tool that automates this process. It collects information about your failure scenario and produces a list of tasks that you must perform to recover your site. For more information about setting up a Recovery Expert Web site, see Chapter 15, Backup and Recovery, in the Microsoft Systems Management Server 2003 Operations Guide.
Running an Unattended Setup

You can create an SMS Setup initialization file to run an unattended setup. Specify this file when using the Setup command /script option. This file supplies the same kind of information that the SMS Setup Wizard prompts for, except that there are no default settings; all values must be specified for the setup keys that apply to the type of installation you are using.
Caution
All accounts and passwords are listed in the Setup.ini file. It is important that you restrict unauthorized access by manually setting the permissions on this file after you have created it.
Tables 15.4 through 15.6 describe each of the setup keys in an SMS Setup initialization file and their corresponding values. Each key description specifies the type of installation that requires that key. The order of the keys within sections, and the order of sections within the file, is not important. Also, the keys and data are not case-sensitive. The SMS Setup initialization file contains four sections. Each of the following tables describes the keys in one of the sections: u u u Table 15.4: [Identification] section Table 15.5: [Options] section Table 15.6: [SQLConfigOptions] section
For an example of an SMS initialization file, see the Example of an SMS Initialization File section later in this chapter. Table 15.4 SMS Setup Initialization File Keys for the [Identification] Section
Key Action Description InstallAdminUI. Installs only the SMS Administrator console. InstallPrimarySite. Installs a primary site. InstallSecondarySite. Installs a secondary site. Used in this type of installation All
Table 15.5 SMS Setup Initialization File Keys for the [Options] Section
Key AddressType Description Used in this type of installation
Specifies that one of the following types of Secondary addresses is to be used as the default address to the secondary site from its parent site: MS_ASYNC_RAS. For RAS communication over an asynchronous line. MS_ISDN_RAS. For RAS communication over an ISDN line. MS_LAN. For communication over a LAN, and over a WAN when routers connect multiple LANs. MS_SNA_RAS. For RAS communication over an SNA link. MS_X25_RAS. For RAS communication over an X.25 line.
(continued)
Table 15.5 SMS Setup Initialization File Keys for the [Options] Section (continued)
Key AllClientOptionsOn FullName Description Enables all client agents and options. The name of a person under whom this product will be registered. (This is the same as the Name field on the Product Registration page of the SMS Setup Wizard.) The account name for the Standard Sender account to be used at this site. The password for the account specified for LanUser. Specifies the maximum number of SMS Administrator consoles that the site can have running simultaneously. A good number is 5. Specifies the maximum number of clients that the site can simultaneously support. Specifies one or more of the following SMS components, in a comma-separated list (no spaces): Remote Control (called Remote Tools in the SMS Setup Wizard): Allows the administrator to control remote computers over the network. The remote computers desktop is displayed on your screen, allowing you to run its programs, examine its logs, and restart. Scripts (called Package Automation Scripts in the SMS Setup Wizard): Ready-made scripts to automate the installation and configuration of many popular software programs. The organization name under which this product will be registered. (This is the same as the Organization field on the Product Registration page of the SMS Setup Wizard.) Used in this type of installation Primary All
LanUser LanUserPassword NumberOfAdminUI
Secondary Secondary Primary
NumOfClients OptionalUnits
Primary and secondary Primary and secondary
OrgName
All
ParentSiteCode ParentSiteServer ProductID
Specifies the site code of the site that will be the new Secondary secondary sites parent site. Specifies the network name of the site server of the new secondary sites parent site. The 10-digit key from the yellow sticker on the SMS CD case. Secondary All
(continued)
Table 15.5 SMS Setup Initialization File Keys for the [Options] Section (continued)
Key RasUser RasUserDomain Description The account name for the RAS Sender account to be used at this site. The domain in which the RasUser account was created. The password for the account specified for RasUser. Used in this type of installation Secondary Secondary, if installing a RAS Sender Secondary, if installing a RAS Sender Secondary, if installing a RAS Sender Primary
RasUserPassword
RasPhoneBook
A RAS phone book name for the RAS Sender to use.
SDKServer SecurityMode
Specifies a server where the SMS Provider will be installed.
Specifies the security mode: Primary Advanced: This mode relies on using the local system context to run services and the computer accounts to communicate between servers. With advanced security, the user accounts are not applicable. Standard: On the site server, SMS services run under a user-specified service account. Specifies a user account to be used as the SMS Service account at this site. The domain in which the SMS Service account was created. The password for the SMS Service account. Three characters that will be the new sites site code. The domain containing the site server. The new sites name (with a 50 character limit). Primary and secondary Primary and secondary Primary and secondary Primary and secondary Primary and secondary Primary and secondary
ServiceAccount ServiceAccountDomain ServiceAccountPassword SiteCode SiteDomain SiteName
Table 15.6 SMS Setup initialization file keys for the [SQLConfigOptions] section
Key AutoConfigSqlConnections DatabaseName Description 1 to automatically configure SQL Server connections, 0 to not automatically configure. A name for the SMS site database, such as SMS_ABC. (SMS_<site code> is a good choice if you have more than one site.) If you choose to have SMS Setup install SQL Server for you, SMS Setup specifies the database name. This is because SQL Server is considered as a dedicated SQL Server for SMS. The number of simultaneous connections that your SMS site database can have. A recommended number is 75. A SQL Server account for accessing the SMS site database. This account must already exist (SMS Setup does not create it) and have SQL Server system administrator (sa) permissions. The password for the account specified for SQLLoginID. The name of the computer running the instance of SQL Server that contains the SMS site database for this site. The version of SQL Server that will contain the SMS site database. Additionally, the version of SQL Server that will be installed by SMS Setup if 1 was specified for InstallSQLServer in the [Options] section. 1 to have SMS use Windows authentication mode when accessing the SMS site database, 0 to not use it. Used in this type of installation Primary Primary
NumberOfSqlConnections
Primary
SQLLoginID
Primary
SQLLoginPassword SQLServerName
Primary Primary
SQLServerVersion
Primary
UseSQLIntegrated Security
Primary
Installing a Primary Site 517
Example of an SMS Initialization File

The following is an example of an SMS initialization file.
[Identification] Action=InstallPrimarySite [Options] FullName=Sam Woodman OrgName=Microsoft ProductID=123-4567890 SiteCode=FIN SiteName=Finance SiteDomain=Seattle SecurityMode=Standard ServiceAccount=smsadmin ServiceAccountDomain=Seattle ServiceAccountPassword=Animal$Cracker27 NumOfClients=100 OptionalUnits=Remote Control SMSInstallDir=D:\SMS InstallSQLServer=0 NumberOfAdminUI=5 SDKServer=Rainy [SQLConfigOptions] SQLServerName=Rainy SQLServerVersion=7.0 UseSQLIntegratedSecurity=0 SQLLoginID=sa SQLLoginPassword=Harpo&Chico CreateSQLDevice=1 DatabaseName=SMS_FIN DatabaseDevice=SMSdata_FIN LogDevice=SMSlog_FIN SQLDevicePath=F:\MSSQL\SMSDATA NumberOfSqlConnections=75 AutoConfigSqlConnections=1
Installing a Primary Site

If you chose to install a primary site on the Setup Options page, you have the choice of Express Setup or Custom Setup. You must have the SQL Server configuration and supporting accounts in place as described in Chapter 12, Planning Your SMS Security Strategy.
Express Setup
When you want to install a small SMS site hierarchy for evaluation purposes, choose Express Setup. Many SMS 2003 features are enabled by default if you use Express Setup, but they are disabled by default if you use Custom Setup. For more information about the differences between Express Setup and Custom Setup, see the Setup Options section earlier in this chapter.
To install an SMS primary site with Express Setup

1. Ensure that the computer you want to use as the site server meets all the hardware and software requirements listed in the Getting Started chapter in this book. Log on to that server with an account that has local Administrative credentials. Insert the SMS 2003 product CD into the servers drive, and then click SMS 2003. On the Welcome page, click Next. On the System Configuration page, click Next. On the Setup Options page, select Install an SMS Primary Site, and then click Next. On the Installation Options page, select Express Setup, and then click Next. The SMS Licensing Agreement page appears. Read the licensing agreement. If you approve, click I agree, and then click Next. On the Product Registration page, fill in the fields, and then click Next. You must enter the Product Key value, which is located on the SMS 2003 product CD case. On the SMS Site Information page, enter the unique three-digit site code, the site name, and the domain in which the site server resides, and then click Next.
2. 3. 4. 5. 6. 7. 8. 9.
Caution
To change the domain name and the computer name after SMS is installed, you must remove your installation of SMS, change the names, and then reinstall SMS. To avoid this time-consuming task, consider this information carefully before you enter it.
10. On the SMS Active Directory Schema page, you have the option to extend the Active Directory schema. This only applies to sites in domains that are using Active Directory. Make your selection, and then click Next.
Note
The Active Directory schema needs to be extended for SMS if you plan to implement global roaming for Advanced Clients. You must have schema administrative rights to extend the Active Directory schema. For more information, see the Extending the Active Directory Schema section later in this chapter.
11. On the SMS Security Information page, choose your security mode: u u If you choose standard security mode, go to step 12. If you choose advanced security mode, go to step 13.
12. On the SMS Security Information page, if you have not already created a service account, use the default (SMSService) or enter an account name and password, and then click Next. You can specify a local domain account by typing only the account name. Specify a trusted domain account by typing the domain and account name separated by a backslash (\). A trusted domain must be trusted by all domains within the site. If you have already created an account, enter the name and password. If you have not created an account, SMS Setup creates the account for you. 13. On the SMS Primary Site Client Load page, enter the number of clients to be managed from this SMS primary site, and then click Next. Estimate the number of clients as accurately as possible because the number you enter is used to size the database and log file. The minimum value is 1. You might want to add 20 percent to the number of clients that you plan for this site to give the database some room to grow. If necessary, you can enlarge the database later as described in the SQL Server product documentation. 14. On the Concurrent SMS Administrator Consoles page, enter the number of SMS Administrator consoles you expect to install on your site, and then click Next. 15. On the Completing the Systems Management Server Setup Wizard page, review the choices you have made throughout the setup process. To change any selection or specification, double-click the item you want to change. Make the change, and then click Next until you come back to the Completing the Systems Management Server Setup Wizard page. When you are satisfied with your choices, click Finish. After SMS Setup installs the primary site, a message appears indicating that the setup was successful.
Custom Setup
Use Custom Setup when you want to control what features SMS Setup installs, when you want to use an existing installation of SQL Server, and for installing an SMS primary site in a production environment. Also, choose Custom Setup when you want to use advanced security. You can select which SMS components to install. If you choose to use an existing SQL Server installation, you can use a local or remote database for SMS operations.
To set up an SMS primary site with Custom Setup

1. Ensure that the computer you want to use as the site server meets all the hardware and software requirements listed in the Getting Started chapter in this book. Log on to that server with an account that has local Administrative credentials. Insert the SMS 2003 product CD into the servers drive, and then click SMS 2003. On the Welcome page, click Next. On the System Configuration page, click Next. On the Setup Options page, select Install a Primary Site, and then click Next. On the Installation Options page, select Custom Setup, and then click Next. The SMS Licensing Agreement page appears. Read the licensing agreement. If you approve, click I agree, and then click Next. On the Product Registration page, fill in the fields, and then click Next. You must enter the Product Key value, which is located on the SMS 2003 product CD case. On the SMS Site Information page, enter the unique three-digit site code, the site name, and the domain in which the site server resides, and then click Next.
2. 3. 4. 5. 6. 7. 8. 9.
Caution
10. On the SMS Active Directory Schema page, you have the option to extend the Active Directory schema. This only applies to sites in domains that are using Active Directory. Make your selection and then click Next.
Note
The Active Directory schema needs to be extended for SMS if you plan to implement global roaming for Advanced Clients. You must have schema administrative rights to extend the Active Directory schema. For more information, see the Extending the Active Directory Schema section later in this chapter.
11. On the SMS Security Information page, choose your security mode: u u If you choose standard security mode, proceed to step 12. If you choose advanced security mode, proceed to step 13.
12. On the SMS Security Information page, if you have not already created a service account, use the default (SMSService) or enter an account name and password, and then click Next. You can specify a local domain account by typing only the account name. Specify a trusted domain account by typing the domain and account name separated by a backslash (\). A trusted domain must be trusted by all domains within the site. If you have already created an account, enter the name and password. If you have not created an account, SMS Setup creates the account for you. 13. On the SMS Primary Site Client Load page, enter the number of clients to be managed from the SMS primary site, and then click Next. Estimate the number of clients as accurately as possible because the number you enter is used to size the database and log file. The minimum value is 1. You might want to add 20 percent to the number of clients that you plan for this site to give the database some room to grow. If necessary, you can enlarge the database later as described in the SQL Server product documentation. 14. On the Setup Installation Options page, select the SMS components that you want to install. SMS and the SMS Administrator console are selected by default; select each additional component you want to install from this page. You can also specify a different folder in which to install SMS by clicking Browse. When you finish making the changes, click Next. 15. On the SQL Server Information for SMS Site Database page, specify the name of the server that hosts the SQL Server database that you want to use, the version number, and whether to use Windows Authentication mode when accessing SQL Server. The alternative is SQL Server Authentication security. With Windows Authentication Mode, you specify a Windows Group account for SMS to use when it logs on to SQL Server. u If you select Yes for Windows Authentication mode, SQL Server verifies logons based on a Windows accounts user name and password. When you log on to SQL Server, SMS bypasses the SQL Server logon process. If you select No for Windows Authentication mode, when SMS logs on, it must supply a SQL Server login ID. The SQL Server Account for SMS Site Database page appears. Enter the SQL Server login ID for the database that you want to use or accept the default (sa). Enter the password for your SQL Server Login ID account in the appropriate boxes, and then click Next.
16. If you chose to create the SMS site database, the SMS Site Database page appears. Enter the name of your database or accept the defaults. SMS Setup automatically detects the version of SQL Server and displays the proper page. The SMS Site Database Name page appears. Enter the SMS site database name of the SQL Server database that you want SMS to use, and then click Next.
17. On the SQL Server Directory Path for SMS site database page, enter the folder name for the SMS site database and the SQL Server transaction log. 18. On the Concurrent SMS Administrator Consoles page, enter the number of SMS Administrator consoles that you expect to install on this site. Enter the minimum number of SQL Server connections that the database will support. If other applications also use the SQL Server database, increase this number by the expected additional connections that are required. Click Next. 19. If you specified a computer other than the site server in the Computer running SQL Server text box on the SQL Server Information for SMS Site Database page, the SMS Provider Information page appears. The SMS Administrator console communicates with the SMS site database through the SMS Provider. If your SMS site database is on a different computer from the site server, you can install the SMS Provider on either computer. For best performance, place the SMS Provider on the computer running SQL Server unless either of the following conditions is true. If either of the listed conditions is true, place SMS Provider on the site server: u u The security setting on the computer running SQL Server prevents direct administrator access to the computer. The additional workload erodes SQL Server performance. This might be the case if the SMS site databases of several sites reside on the computer running SQL Server or if the computer is already performing poorly.
After SMS 2003 site installation is complete, you cannot move the SMS Provider. Select the location where you want the SMS Provider to be installed, and then click Next. 20. On the Completing the Systems Management Server Setup Wizard page, review the choices you have made throughout the setup process. To change any selection or specification, double-click the item that you want to change. Make the change, and then click Next until you return to the Completing the Systems Management Server Setup Wizard page. When you are satisfied with your choices, click Finish. After SMS Setup installs the primary site, a message appears indicating that the setup was successful.
Installing a Secondary Site 523
Installing a Secondary Site

Before you install a secondary site, you must first install a parent primary site. You can install a secondary site from the SMS 2003 product CD, or you can connect to an image of the SMS 2003 product CD on a mapped network drive, hard disk drive, or removable drive of the secondary site. You can also install a secondary site from the primary site by using the SMS Administrator console.
Note
You must have Create permission for the site security object class to perform the following procedures. Also, the SMS Service account on the primary site server must have administrative rights on the new secondary site server.
Installing a Secondary Site Using SMS Setup

You can install a secondary site from the SMS 2003 product CD, or you can connect to an image of the SMS 2003 product CD on a mapped network drive, hard disk drive, or removable drive of the secondary site.
To install a secondary site from the SMS Setup product CD

1. Ensure that the computer you want to use as the secondary site meets all the hardware and software requirements listed in the Getting Started chapter in this book. Log on to that server with an account that has local Administrative credentials. Insert the SMS 2003 product CD into the servers drive. Click Set up SMS 2003. On the Welcome page, click Next. On the System Configuration page, click Next. On the Setup Options page, select Install an SMS secondary site, and then click Next. On the Product Registration page, fill in the fields, and then click Next. You must enter the Product Key value, which is located on the SMS 2003 product CD case. On the SMS Site Information page, enter the unique three-digit site code, the site name, and the site domain of this site, and then click Next.
2. 3. 4. 5. 6. 7.
Caution
8.
On the SMS Security Information page, choose your security mode: u u If you choose standard security mode, proceed to step 9. If you choose advanced security mode, proceed to step 10.
Note
You cannot install a secondary site in Advanced security mode if the parent site is in Standard security mode.
9.
On the SMS Service Account Information page, if you have not already created a service account, use the default account (SMSService) or enter an account name and password. SMS Setup creates the account. If you have already created an account, enter the account name and password. You can specify a local domain account by typing only the account name. You specify a trusted domain account by typing the domain and account name separated by a backslash (\). The trusted domain must be trusted by all domains within the site.
10. On the Setup Installation Options page, select the SMS components that you want to install, and then click Next. You can also change the folders that the components are installed into on your server. 11. On the Parent Site Information/Identification page, enter the site code of the parent site and the name of the primary site server to which the secondary site will connect. Enter the type of network connection that this site will use to communicate with the parent site, and then click Next. This option is not available when installing in the advanced security mode. 12. On the Connection Account Information page, specify the account information that the secondary site will use to connect to the parent site, and then click Next. 13. On the Completing the Systems Management Server Setup Wizard page, review the choices you have made throughout the setup process. To change any selection or specification, double-click the item that you want to change. Make the change, and then click Next until you return to the Completing the Systems Management Server Setup Wizard page. When you are satisfied with your choices, click Finish. The SMS 2003 secondary site installation on your computer is complete.
Installing a Secondary Site Using the SMS Administrator Console

To install a secondary site from the primary site by using the SMS Administrator console, complete the following procedure.
Installing a Secondary Site 525
To install a secondary site from the SMS Administrator console

1. From the SMS Administrator console, navigate to your primary site:
2. 3. 4. 5.
Right-click the <site code - site name> of your primary site, select New, and then click Secondary Site Creation Wizard. On the Welcome page, click Next. On the Site Identity page, enter the site code and site name that you chose for the secondary site server, add any optional comments, and then click Next. On the Site Server page, specify the domain and the name of the secondary site server. If necessary, change the installation folder and processor platform. The installation folder name must not include any spaces. Click Next.
Caution
Ensure that you type the server name correctly. The Create Secondary Site Wizard does not verify that the server exists.
6.
On the Installation Source Files page, choose whether to send all the files that are required to set up a secondary site over your network from the primary site server to the secondary site server. u u If you have sufficient network bandwidth during the installation, sending the files over the network is the easiest approach. You can place the SMS 2003 product CD in the secondary site server computer and have the Secondary Site Creation Wizard load the necessary files from the product CD. This is the preferred method when you install SMS in low-bandwidth situations and when it is inconvenient to access the secondary site server remotely (installing a secondary site over RAS, for example). Alternatively, you can use an SMS 2003 product CD image on the local disk or removable media or a mapped network connection at the secondary site server.
Select the method you want to use, and then click Next. 7. On the SMS Security Information page, choose your security mode: u u 8. If you choose standard security mode, proceed to step 8. If you choose advanced security mode, proceed to step 9.
On the SMS Service Account page, enter the user name and password of the account to be used as the SMS Service account for the secondary site. Ensure that this account already exists in the secondary site domain. If it does not exist, create it before continuing the installation. When you are finished, click Next.
9.
The Addresses to Secondary Site page appears. If you already have addresses configured for this site, select one. Alternatively, create one or more addresses to the new secondary site by clicking Yes, Create a new address, and then click Next.
10. On the New Address to Parent Site page, select the sender address type that the secondary site will use when it contacts the parent site. Specify the destination site name, and then click Set to specify the account that you want the secondary site to use when it connects to the primary site. Click Next. 11. On the Completing the Create Secondary Site Wizard page, review your choices. To change any selection or specification, double-click the item you want to change. Make the corrections, and then click Next until you return to the Completing the Create Secondary Site Wizard page. When you are ready to continue, click Finish. After the secondary site has been installed and the site control file has been passed to the parent site, you can see the new secondary site displayed in the SMS Administrator console tree.
Installing the SMS Administrator Console and Related Tools

To install the SMS Administrator console and related tools, complete the following procedure.
To install the SMS Administrator console and related tools

1. Ensure that the computer you want to use meets all the hardware and software requirements listed in the Getting Started chapter in this book. Log on to that server with an account that has local Administrative credentials. Insert the SMS 2003 product CD into the servers drive, and then click Set up SMS 2003. On the Welcome page, click Next. On the System Configuration page, click Next. On the Setup Options page, select Install the SMS Administrator console and related tools, and then click Next. On the site server Information page, enter the name of the primary site server that the SMS Administrator console will initially connect to, and then click Next. Select any additional tools to install from SMS Administrator Console Installation Options, and then click Next. On the Completing the Systems Management Server Setup Wizard page, review the choices you have made throughout the setup process. To change any selection or specification, double-click the item you want to change. Make the change, and then click Next until you return to the Completing the Systems Management Server Setup Wizard page. When you are satisfied with your choices, click Finish. The SMS 2003 Administrator console installation on your computer is complete.
2. 3. 4. 5. 6. 7. 8.
Configuring Your SMS Sites and Hierarchy 527
Configuring Your SMS Sites and Hierarchy

After you install SMS 2003, you must configure the new site. You begin the site configuration process by defining site characteristics and configuring site systems at a single site. After you configure individual sites, you can build an SMS site hierarchy by establishing intersite communications and attaching primary sites to form the site-reporting structure that you designed in the planning phase. This section has step-by-step instructions for configuring your SMS site servers and site systems. It helps you configure your site up to the point of installing clients. For information about client installation, see Chapter 17, Discovering Resources and Deploying Clients. For information about planning considerations, see Chapter 10, Planning Your SMS Deployment and Configuration. For configuration information about each SMS feature, see the Microsoft Systems Management Server 2003 Operations Guide. After you install a primary or secondary site, you must configure the site boundaries and other site settings using the SMS Administrator console. In general, perform post-installation tasks in the following order: u u Configure site security. Specify all site configuration settings except for enabling client installation methods. In particular, assign site system roles, specify the IP subnets or Active Directory sites that define your site boundaries, enable and configure client agents, and enable resource discovery methods. Configure addresses and senders and ensure that they are working properly. Enable client installation methods.
u u
Note
After installing SMS 2003 on Windows 2000 Server family operating systems, it is recommended that you update the computers emergency repair disk. This step backs up your registry and preserves the SMS registry keys created during installation. If you are using Windows Server 2003, you can create an Automated System Recovery Set using Backup following SMS setup.
After you install SMS, wait 30 minutes before opening the SMS Administrator console to configure your site. This waiting period allows the initial SMS configuration process to complete.
Configuring a Single Site

Configuring a single SMS site involves configuring security rights, site assignment, and site systems within the site. After you install SMS 2003, you should first configure security for the new site. This approach prevents users from making unauthorized changes to the SMS system. After you configure security, you can then configure the boundaries of the site and the site systems that help run SMS on the site.
Configuring Site Security

To configure site security, implement the security plan you developed after reading Chapter 12, Planning your SMS Security Strategy.
Configuring Site Assignment

To set the boundaries of a site, you must have Modify permissions to the Site object class or instance. Navigate to the site in the SMS Administrator console.
Systems Management Server X Site Database (site code-site name) X Site Hierarchy X site code - site name
Right-click the site, and then click Properties. In the Properties dialog box, click the Site Boundaries tab, click the New icon, and then specify the type and ID of the IP subnet or Active Directory sites that you want to include in the site. Repeat this procedure for each subnet you want to include. By default, the subnet for the site server is listed on the Site Boundaries tab. To set the roaming boundaries of a site, click the Roaming Boundaries tab, click the New icon, and then specify the IP subnets, IP address ranges, and Active Directory sites that you want to include in the roaming boundaries of the site. Repeat this procedure for each subnet, IP address range, or Active Directory site name you want to include. The boundaries that you specify are used by roaming clients to access distribution points that belong to the site. For more information about configuring site boundaries, see SMS Help.
Configuring Site Systems

Configuring your site systems consists of the following tasks: u u Preparing the site system computers Creating the site systems in the SMS Administrator console and assigning the site system roles
Preparing Site System Computers

Before you create a site system, ensure that the computer you will use as a site system has the required disk space and other resources. For a list of the requirements for a site system, see the Getting Started chapter in this book. Ensure that users, services, and SMS client accounts have the permissions they need on the server or shared folder. For example, clients must be able to access CAPs and distribution points.
Note
If you prepare a Windows 2000 Server, Windows 2000 Advanced Server, Windows Server 2003, Standard Edition, or Windows Server 2003, Enterprise Edition, computer to be a CAP, ensure that at least one NTFS partition is available. SMS does not support CAPs on non-NTFS partitions.
Creating Site Systems

You create a site system by specifying the computer or shared folder to be used as the site system and assigning the site system roles to it. When you create the site system, SMS installs the appropriate components on the computer, and the new site system begins performing its role in the SMS site. For a list of prerequisites for site systems, see Chapter 10, Planning Your SMS Deployment and Configuration. To create a site system, you must have Modify permissions for the SMS site. Navigate to Site Systems in the SMS Administrator console. Right-click Site Systems, click New, and then click the type of site system that you want to create. In the Properties dialog box, click Set, and then specify the identity of the site system. You can then assign the appropriate site system roles.
Assigning site system roles

After you prepare your site system computers, you can assign site system roles. By default, SMS assigns CAP and distribution point roles to the site server, but you can also assign these roles to other site systems.
Note
The process of assigning a site system role to a server is usually referred to as creating the <site system role>. For example, assigning the CAP role to a server is creating the CAP.
Creating CAPs, distribution points, management points, server locator points, and reporting points
To create a CAP, distribution point, management point, server locator point, or reporting point, you must have Modify permissions for the SMS site. To assign a site system role, navigate to Site Systems in the SMS Administrator console.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Site Systems
Right-click the site system to which you want to assign a role, and then click Properties. To assign the CAP point role, click the Client Access Point tab, and then select the Use this site system as a client access point check box. To remove the role from the site system, clear the check box.
Note
Every SMS site must have at least one CAP. When you install SMS, the site server is automatically configured as a CAP. However, the SMS administrator can move the CAP to another server if necessary.
To assign the distribution point role, click the Distribution Point tab, and select the Use this site system as a distribution point check box. To remove the role from the site system, clear the check box. You can also enable Background Intelligent Transfer Service (BITS) and manage the site systems membership in distribution point groups. For more information about BITS and distribution point groups, see Chapter 5, Distributing Software, in the Microsoft Systems Management Server 2003 Operations Guide.
Note
To use BITS, the site system must have IIS installed and enabled. If you use the Microsoft IIS Lockdown Tool (Lislockd.exe) to increase security protection on a computer running IIS, be sure to apply it to the computer (using the SMS 2003-specific template) before enabling the computer as an SMS site system. This only applies to SMS site systems that require IIS components.
To assign the management point role, click the Management Point tab, and then select the Use this site system as a management point check box. In the Database box, select which SMS site database that you want to use. Typically, a site containing Advanced Clients will use only its default management point. To assign a default management point, navigate to Component Configuration in the SMS Administrator console.
If you are setting up a management point on a Network Load Balancing cluster, see your Windows Network Load Balancing documentation.
Note
During the operation of creating a management point, WMI is shut down, which might cause the SMS Administrator console to stop responding. If it does, close it, and open a new session.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Component Configuration
Note
If your computer is running Windows Server 2003, Standard Edition, or Windows Server 2003, Enterprise Edition, you must verify that Bitssvr.dll, Getauth.dll, and Getpolicy.dll are enabled on the IIS security page. You must also enable Active Server Pages as a Windows component. For more information about enabling and installing IIS, see IIS Help.
To assign the server locator point role, click the Server Locator Point tab, and then select the Use this site system as a server locator point check box. In the Database box, select which SMS site database that you want to use. To enable a reporting point, click the Reporting Point tab in the Site System Properties dialog box, and then select the Use this site system as a reporting point check box. In the Report folder box, type the name of the folder under the root folder for SMS 2003 to use for reporting. The default folder name is SMSReporting_site code. In the URL box, the URL that users can use to access reports appears as a read-only field. The URL is determined based on the site server name and the report folder name. For more information about creating reports, see Chapter 11, Creating Reports, in the Microsoft Systems Management Server 2003 Operations Guide.
Removing or reassigning roles and deleting site systems

You can remove the CAP, distribution point, management point, server locator point, and reporting point role from a site system by clearing the check box on the appropriate tab of the site system Properties dialog box. To reassign one of these roles to a different site system, remove it from the first site system and assign it to the next. You can reassign the SMS site database server roles to different servers by running SMS Setup to modify the site. For more information, see Chapter 14, Upgrading to SMS 2003. You cannot reassign the SMS Provider role.
Important
SMS does not support moving a remote database server to a local database server. When planning to move a local database server to a remote database server, it is important to remember that this operation is irreversible. For more information, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide.
Even if you remove all the roles from a site system, it remains listed under Site Systems in the SMS Administrator console. The listing indicates that the site system is still available and can have roles assigned to it. To remove the site system from the Site Systems item of the console tree, you must delete it. All roles except CAP and distribution point must be removed before the site system can be deleted. To delete a site system, navigate to Site Systems in the SMS Administrator console. Right-click the site system you want to delete, click Delete, and then confirm that you want to delete the site system.
Caution
Before you delete a site system, ensure that deleting it will not remove any needed functionality from your site. You cannot delete the site server.
Manually Add SMS Site System Roles in Windows Internet Name Service
If you do not extend the Active Directory schema for SMS, your server locator point and management points are not published to Active Directory and you must manually register the server locator point (and any management points operating in a Network Load Balancing cluster) in Windows Internet Name Service (WINS).
Note
To have administrative rights to manage a WINS server, you must be logged on with a user account that has membership in the local WINS Users group. For Windows NT Server, you must belong to the local Administrator group on that server.
For management points and server locator points requiring manual WINS registration, you should decide which method you will use to add the entries to your WINS database. For example, one method is running Netsh.exe from the command prompt on a computer running the Windows 2000 Server family. The following procedures use the Netsh.exe tool. For more information about how to manually add a dynamic WINS entry to a Windows 2000 WINS server using Netsh.exe, see article 233375 in the Microsoft Knowledge Base at http://support.microsoft.com. For information about using Winscl.exe for computers running Windows NT 4.0 Server, SP6a or later, see article 137582 in the Microsoft Knowledge Base at http://support.microsoft.com.
To manually add the server locator point entry to WINS

1. 2. 3. 4. At the command prompt, type netsh, and then press ENTER. Type wins, and then press ENTER. Type server, and then press ENTER. To manage a remote WINS server, type server [\\servername or XXX.XXX.XXX.XXX]. Type the appropriate command, as in the following example:
add name Name=SMS_SLP endchar=1A rectype=0 ip={static IP of your SLP}
To verify that the server locator point WINS entry was added correctly
show Name name=SMS_SLP endchar=1A
To manually add the Network Load Balancing cluster entry to WINS

add name name=NLB_<site code> endchar=1A rectype=0 ip={NLB Virtual IP Address}
To verify that the Network Load Balancing cluster WINS entry was added correctly
1. 2. 3. At the command prompt, type netsh, and then press ENTER. Type wins, and then press ENTER. Type server, and then press ENTER. To manage a remote WINS server, type server [\\servername or XXX.XXX.XXX.XXX].
4.
Type the appropriate command, as in the following example:

show Name name=NLB_<site code> endchar=1A
The output is as follows:

Name : NLB_<site code> [1Ah] NodeType : 1 State : ACTIVE Expiration Date : Infinite Type of Rec : UNIQUE Version No : 0 29c RecordType : STATIC IP Address : NLB Virtual IP Address Command completed successfully.
Note
Management points are automatically registered in the WINS record. However, if you are using a Network Load Balancing cluster, you must add the WINS entry. The WINS entry is MP_<site code>.
Configuring a Site Hierarchy

Configuring a site hierarchy consists of the following tasks: u u Configuring site communications Attaching primary sites If your SMS site will not be part of a site hierarchy, you do not need to perform these tasks.
Configuring Site Communications

The first step in building an SMS site hierarchy is to ensure that the sites in the hierarchy can communicate. For sites to communicate, the following criteria must be met: u Connectivity system software (such as LAN protocols or the Microsoft RAS Service) must already be installed and configured according to the connectivity system product documentation. Each site must have the appropriate senders required by the connectivity system. For more information, see the Installing and configuring senders section later in this chapter. Each site must have an address for every site it communicates with. For more information, see the Configuring Addresses section later in this chapter.
u u
Installing and configuring senders

When you set up a primary site, Standard Sender is installed on the SMS site server and configured by default. If your site-to-site communications occur over a LAN that uses a supported protocol, you do not need to install another sender. You can edit Standard Sender settings if you want to change the maximum number of concurrent sendings or the retry settings for the sender. Increasing the maximum number of concurrent sendings can increase the throughput of data between sites, but it can also result in higher demand on network bandwidth. Edit the retry settings to specify the number of times that the sender retries a sending if the first attempt fails and how long it waits between retries. To change the Standard Sender settings, navigate to Senders in the SMS Administrator console.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Senders
In the details pane, right-click Standard Sender, click Properties, click the Advanced tab, and then change the settings. If you need to use senders other than the Standard Sender, or if you want to move the Standard Sender off the site server, you must install and configure the senders. To move a sender from one server to another, you must delete the sender from the first server and install it on the second server. You can install multiple instances of a single sender type in an SMS site (two instances of Standard Sender, for example), but you can have only one sender of each type installed on a single site system (two instances of Standard Sender would have to run on different servers). The process of installing and configuring senders consists of the following tasks: u u u Preparing servers for senders Installing senders Configuring senders
Preparing servers for sender installation

You can install senders on the site server or on other computers. Before you install a sender, the connectivity system between the sites must already be installed and configured on the server on which you install the sender. For more information about installing and configuring connectivity systems, see the applicable connectivity system product documentation, such as the Windows 2000 Server Help.
Preparing servers for Standard Sender

Ensure that the server on which you install the sender uses the same LAN protocols as the site servers for the destination sites. On the server where the sender will be installed, run the command prompt. Type net view \\servername (where servername is the name of a destination site server). If both servers use the same LAN protocols, the net view command produces either a list of shared folders, or, if you do not have permissions on the destination site server that you have Read permissions for, an Access Denied error message.
Preparing servers for RAS senders

Install Microsoft RAS on the source and destination sites. Create RAS phone book entries for the RAS servers on each destination site. On each destination site, create a user account that the RAS Sender on the site server can use and then grant the account Dial in and Dial out permissions in the RAS Administrator.
To prepare a server for SNA RAS Sender

1. Check that Microsoft SNA Server is installed on computers in both the sending and destination sites. Make logical unit pair connections between these installations of SNA Server. On the server running SNA Server that you will install SNA Sender on, create an advanced program-to-program communications (APPC) local logical unit that the SNA sender and SNA receiver will use. On the destination sites, create an APPC local logical unit. The logical units on these sites are used by the current sites SNA sender. Create a connection between the current site server SNA Sender logical unit (the local logical unit) and all destination site SNA Sender logical units (remote logical units). Create the connection on both sites.
2.
3. 4. 5.
The logical unit pair for both connections can use either #BATCH (batch) or #INTER (interactive) modes. For more information about local logical units, remote logical units, modes, and connections, see the SNA Server product documentation.
Installing senders
After you prepare the servers, you can install the senders. When you install a sender on a server, the server becomes a site system for the SMS site, if it is not already a site system. When the server becomes a site system, it is given the component server role and is listed under Site Systems in the SMS Administrator console. Before you install a sender, ensure that you know the name of the computer on which you want to install the sender. To install a sender, you must have Modify permissions for the Site object type or for the individual site where you want to install the sender. To install the sender, navigate to Senders in the SMS Administrator console.
Right-click Senders, select New, and then select the type of sender that you want to install. To finish installing the sender, complete the Properties dialog box.
To Install Courier Sender

1. 2. On the Start menu, click Programs. Click Systems Management Server, and then click SMS Courier Sender.
For more information about Courier Sender, see Courier Sender Help.
Configuring senders
To configure a sender, you must have Modify permissions for the Site object type or for the individual site in which you want to configure the sender. To configure the sender, navigate to Senders in the SMS Administrator console. Open the Properties dialog box for the sender that you want to configure. Click the Advanced tab, and then edit the settings that you want to configure.
Deleting senders
To delete a sender, you must have Modify permissions for the Site object type or for the individual site from which you want to remove the sender. To delete the sender, navigate to Senders in the SMS Administrator console. Right-click the sender that you want to remove, and then click Delete. The sender component is removed from the computer. If the sender was the only SMS component on the computer, the component server role disappears from the servers entry under Site Systems. However, SMS will continue to list the computer as a site system, so that you can assign other roles to it.
Configuring Addresses
Each site must have an address for every site it communicates with.
Creating an address
To create an address, you must have Modify permissions for the Site object type or for the individual site where you want to create the address. Navigate to Addresses in the SMS Administrator console.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Addresses
Right-click Addresses, click New, and then select the type of address that you want to create. In the Address Properties dialog box, type or enter the destination SMS site, the name of the site server for that site, and (for Standard Sender and RAS Sender addresses) the account to use for connecting to the destination site server.
Note
In advanced security, you cannot specify the destination site server account. Advanced security uses the computer account for this purpose.
To limit the number of times the address is operative or the amount of network bandwidth SMS can use, change the settings o the Schedule and Rate Limits tabs of the Address Properties dialog box.
Configuring an address
To configure an address, you must have Modify permissions for the Site object type or for the individual site where you want to configure the address. Navigate to Addresses in the SMS Administrator console. Open the Properties dialog box for the address that you want to modify, and then edit the settings. To change the priority of an address, right-click the address whose priority you want to modify, and then click Increment Priority or Decrement Priority. Unless the address already has the highest or lowest priority of the addresses to the destination site, this increases or decreases the priority by one unit. When you modify the priority of an address, the position of the address is updated in the details pane of the SMS Administrator console.
Deleting an address
When you delete a sender from your site, the addresses that are related to the sender type are no longer operative. You can then delete the addresses for that sender type. In this way, you can delete addresses to sites that you do not want your site to communicate with. If you have multiple addresses to a destination site, you can delete redundant addresses when they become unnecessary.
Caution
Before you delete an address, ensure that deleting it will not break your site hierarchy.
To delete an address, you must have Modify permissions for the Site object type or for the individual site that you want to remove the address from. Navigate to Addresses in the SMS Administrator console. Right-click the address that you want to remove, and then click Delete.
Using multiple addresses to destination sites

To create multiple addresses to a single destination site, navigate to Addresses in the SMS Administrator console. Right-click Addresses, select New, and then select the type of address that you want to create. To enable SMS to use more than one address to a site simultaneously, you can specify the number of concurrent sendings for the sender that uses the address. The maximum number of concurrent sendings is the maximum number of addresses for that sender type that SMS can use simultaneously. To specify the maximum concurrent sendings, navigate to Senders in the SMS Administrator console.
Open the Properties dialog box of the sender that you want to configure, and then click the Advanced tab. To specify the maximum number of addresses for sender types that SMS can use simultaneously, click Maximum concurrent sendings per site. To specify the maximum number of addresses for sender types that SMS can use simultaneously to send data to any number of sites, click Maximum concurrent sendings for all sites.
Attaching Primary Sites

To specify a parent site for a site, you must have Modify permissions for the child site. If you want to specify a parent for the site, ensure that you know the parents site code. To set the parent site or change the site to a central site, navigate to the site in the SMS Administrator console.
Systems Management Server X Site Database (site code-site name) X Site Hierarchy X site code - site name
Right-click the site, and then click Properties. On the General tab, click Set Parent Site. In the Set Parent Site dialog box, select whether you want the site to be a central site or report to a parent site. To specify a parent site, select or type the site code of the parent to which you want the site to report.
Note
If you change the position of a site in the hierarchy, the new position of the site appears in the SMS Administrator console after SMS Hierarchy Manager processes the change. Until the change is complete, SMS marks the site Pending.
Extending the Active Directory Schema

To extend the Active Directory schema for SMS 2003, you must be a member of the Schema Administrator group. You also need to enable the extension of the Active Directory schema on domain controllers running Windows 2000. Enabling the extension of the Active Directory schema for SMS is not required for Windows Server 2003 domain controllers.
Caution
Modifying the Active Directory schema is an advanced operation that is best performed programmatically by experienced programmers and system administrators. For more information about modifying the Active Directory schema, see The Active Directory Programmers Guide.
You can extend the Active Directory schema during SMS setup or by using the command-line tool ExtADSch.exe. You can find ExtADSch.exe in the \SMSSETUP\BIN\I386 folder on the SMS 2003 product CD. Running the tool creates four classes and ten attributes in Active Directory. For more information about Active Directory planning issues, see Chapter 10, Planning Your SMS Deployment and Configuration.
Before SMS 2003 can integrate with Active Directory, appropriate security privileges must be set.
Note
You must register Schmmgmt.dll before you access the Active Directory Schema snap-in. At the command prompt, type Regsvr32 schmmgmt.dll.
To set appropriate security permissions

1. 2. 3. 4. On the taskbar, click the Start button, and then click Run. Type mmc, and then click OK. The MMC Console1 window appears displaying a blank snap-in. On the Console menu, click Add/Remove Snap-in. The Add/Remove Snap-in dialog box appears. Click Add. The Add Standalone Snap-in dialog box appears displaying all available snap-ins. Under Snap-in, select Active Directory Schema, and then click Add. 5. Click Close. The Add/Remove Snap-in dialog box appears displaying the Active Directory Schema snap-in that was added. 6. 7. Click OK. The MMC Console1 window appears displaying the Active Directory Schema snap-in. In the console tree, right-click Active Directory Schema, and then select Operations Master. The Change Schema Master dialog box appears. 8. 9. Click The Schema may be modified on this Domain Controller, and then click OK. The MMC Console1 window appears displaying the Active Directory Schema snap-in. On the Console menu, click Exit. A Microsoft Management Console message box appears prompting you to save the changes to Console1. 10. Click No, opting not to save the console settings. You have now configured the computer so that the Active Directory schema can be extended.
To extend the Active Directory schema using ExtADSch.exe

1. 2. At the command prompt, type ExtADSch. Press ENTER.
The ExtADSch.exe tool produces output to confirm that the changes have completed successfully. If an error occurs, it is reported with an error code number. You can use the command-line tool net helpmsg to provide troubleshooting information. At the command prompt, type the appropriate command, as in the following example:
net helpmsg message#
Note
After you extend the Active Directory schema, it is important that you allow enough time for the Active Directory replication to discover all Active Directory containers throughout the enterprise. For more information, see Windows 2000 Server Help.
Class common names that can be implemented and used by SMS 2003 sites include the following: u u u u MS-SMS-Management-Point MS-SMS-Server_Locator-Point MS-SMS-Site MS-SMS-Roaming-Boundary-Range
Attribute common names that can be implemented and used by SMS 2003 sites include the following: u u u u u u u u u u MS-SMS-Site-Code MS-SMS-Assignment-Site-Code MS-SMS-Site-Boundaries MS-SMS-Roaming-Boundaries MS-SMS-Default-MP MS-SMS-Device-Management-Point MS-SM-MP-Name MS-SMS-MP-Address MS-SMS-Ranged-IP-Low MS-SMS-Ranged-IP-High
You can verify the extension of the Active Directory schema by using the Active Directory Administration tool. To access the tool, click Start, point to Programs, point to Administrative Tools, and then select Active Directory Schema. For more information about using this tool, see Windows 2000 Server Help.
Creating SMS Containers in Active Directory

To create containers in Active Directory, after extending the schema, the SMS Service Account must be a member of the Administrator group to be able to create the System Management container and its child objects. Another option is to manually create the System Management container in Active Directory by using the ADSIEdit.msc tool.
Note
To access the ADSIEdit.msc tool, you must install the Windows 2000 Administrator Tools. To install these tools, run AdminPak.msi in the \system\system32 folder. For more information, see the Windows 2000 Help.
If you are using advanced security mode, grant the SMS Service Account or the computer account rights to the System Management container. It is required that Read, Write, Create All Child Objects, and Delete All Child Objects rights are granted to this object and child objects. For more information about SMS 2003 security accounts, see Chapter 5, Understanding SMS Security, and Chapter 12, Planning Your SMS Security Strategy. For more information about Active Directory, see the Active Directory Help.
To set security on the System Management object

1. 2. 3. 4. 5. 6. 7. 8. 9. Start the Active Directory Users and Computers administrative tool. On the View menu, click Advanced Features. In the tree view, select the System container for the domain. Expand the System container, right-click the System Management container, and then select Properties. On the Security tab, click Add. If the site is using advanced security, click Object Types in the Select Users, Computers, or Groups dialog box. Select the Computers check box, and then click OK. Enter the SMS Service account for standard security or the computer name for the site server for advanced security, and then click OK. In the System Management Properties dialog box, select the Read, Write, Create All Child Objects check box, and then select Delete All Child Objects permissions.
10. Click Advanced, select the SMS Service account or computer account, and then click Edit. 11. In the Apply onto list, select This object and all child objects. 12. Click OK to close the dialog boxes.
C H A P T E R
1 6
Using the SMS Administrator Console

In Microsoft Systems Management Server (SMS) 2003, the SMS Administrator console is the primary interface you use to configure, run, and access SMS features and tools. As an administrator, you install and use the SMS Administrator console to accomplish the day-to-day tasks required to administer an SMS system. The SMS Administrator console provides items you can use to configure your SMS sites, maintain your SMS site database, and monitor the status of your SMS hierarchy. This chapter includes information about the SMS 2003 user interface and a description of Microsoft Management Console (MMC). This chapter also identifies the tasks you must perform to create and save customized consoles, which address administrative concerns. You can make these consoles available to administrators when you want to delegate specific management tasks.
In This Chapter
u u u SMS Administrator Console SMS and Microsoft Management Console Creating Custom Consoles
544 Chapter 16 Using the SMS Administrator Console

There are two panes in the SMS Administrator console: the console tree on the left and the details pane on the right. The details pane displays the contents of an item in the console tree. For example, when you click a specific collection in the console tree, the contents of that collection are displayed in the details pane. If you are administering several sites, you can use the SMS Administrator console to connect simultaneously to several SMS site databases. The SMS Administrator console can manage only one SMS site database at a time. Although software and hardware inventory, product compliance, software distribution and installation, Remote Tools, software metering, and network diagnostics tools are the primary SMS features, most of the primary SMS features do not appear in the console tree. Each console item (such as Site Hierarchy, Collections, and Queries) provides access to the specific tasks you use to achieve management operations as categorized by the SMS features. You can use a specific SMS feature by using a combination of console tree items. For example, you can perform software distribution by using the Packages and Advertisements console tree items. This section describes the following: u u u u u u u u u u Supporting different versions of SMS Understanding the console tree Exploring the console tree Viewing items in the details pane Using the SMS toolbar Displaying the Action and shortcut menus. Viewing and modifying properties Viewing secondary sites Using the Import and Export Object Wizards Starting SMS Service Manager
Supporting Different Versions of SMS

If you are using different versions of SMS in the same hierarchy, it is recommended that you use the SMS 2003 Administrator console to maintain both SMS 2003 and SMS 2.0 sites. This is because the SMS 2003 Administrator console performs version checking to identify which features and properties should be displayed for the SMS 2.0 and SMS 2003 sites. For example, although you can view SMS 2.0 sites from the SMS 2003 Administrator console, you cannot view SMS 2003 sites from the SMS 2.0 Administrator console. For more information about interoperability between SMS 2.0 and SMS 2003 sites, see Chapter 6, Understanding Interoperability with SMS 2.0.
SMS Administrator Console 545
Understanding the Console Tree

The console tree contains a hierarchical listing of SMS objects. There are two panes in the SMS Administrator console: the console tree on the left and the details pane on the right. The details pane displays the contents of an item in the console tree. For example, when you click a specific collection in the console tree, the contents of that collection are displayed in the details pane. You navigate the console tree by clicking items, expanding and collapsing branches to expose the items whose functional scope meets your administrative objectives. Table 16.1 describes console tree functions. Table 16.1 Console Tree Functionality
Use these console tree items Systems Management Server Site database Site hierarchy Collections To perform these tasks Display the root item of the console tree, which represents the primary site server that the console is currently attached to. Connect to the SMS site database. Configure your primary site and any child sites attached to the primary site. Create, delete, view, and configure collections. Open Resource Explorer, where you can view specific information about resources. Use Remote Tools on collection members. Create, delete, and configure packages and programs. Create, configure, schedule, and delete advertisements. Create, delete, and modify software metering rules. Create, modify, and run reports. Configure the compliance level of products. Create, run, configure, and delete queries. Use the SMS status system for maintenance and troubleshooting tasks. Set security rights with SMS security objects such as collections, packages, and advertisements. Start and stop SMS service and thread component activity. Run the Online Library.
Packages Advertisements Software metering rules Reporting Product compliance Queries System status Security rights Tools (SMS Service Manager) Online Library
When you use the SMS Administrator console, follow this general pattern: 1. 2. 3. Determine the task that you want to perform. Refer to the appropriate chapter in this book or use SMS Help to assist you with identifying common SMS management tasks. Find the appropriate item in the console tree that makes it possible for you to accomplish the task. Expand the console tree to expose additional child items until you find the item you need to use. Or, right-click an item to open additional menus that will guide you to the appropriate item. Configure the items properties.
4.
Some management tasks have a broad functional scope, such as site configuration. These require viewing and setting several different items in the console tree. When you engage in these higher level tasks, follow this general pattern: 1. 2. 3. 4. Explore the console tree. Observe the types of results displayed in the details pane. Identify what commands the SMS toolbar buttons perform. Use either the Action menu or the shortcut menu.
For more information about how to configure specific tasks, see SMS Help.
Exploring the Console Tree

When you expand items in the console tree, the icon associated with any tree item changes to an hourglass while SMS enumerates the objects contained in that hierarchy. You can explore the console tree by using certain keystrokes, the mouse, or toolbar buttons. The following table lists keystrokes that you can use to explore the SMS console tree. Table 16.2 Navigating the Console Tree with Keystrokes
Keystroke + (plus sign) - (minus sign) Right arrow Left arrow Result Displays any child items beneath the selected item. Hides any child items beneath the selected item. Expands the parent item to display all child items beneath it, if the selected item is a parent to hidden child items. Collapses all child items, if the selected item is a parent to displayed child items. If the child items are already hidden, a left-arrow keystroke moves the cursor to the parent of the selected item. Moves the cursor up the hierarchical tree toward the root item. Moves the cursor down the hierarchical tree away from the root item.
Up arrow Down arrow
(continued)
Table 16.2 Navigating the Console Tree with Keystrokes (continued)

Keystroke TAB key F1 Shift+F10 Result Moves the focus between the console tree and the details pane. Obtains Help information related to the selected item. Displays the Action menu of the selected item.
The following table lists mouse actions that you can use to explore the SMS console tree. Table 16.3 Navigating the Console Tree with Mouse Actions
Action Click Double-click Selects an item. Shows a display of the child items, if child items exist beneath an item. Double-clicking expands or collapses the list of child items, depending on whether they are already displayed or not. If no child items exist, a double-click has the same result as a click. Displays the Action menu of the selected item. Result
Right-click
You can also explore the console tree by using the MMC toolbar buttons. Forward-arrow and back-arrow buttons help you to retrace your navigation through the console tree. By using these buttons, you can retrace your steps or return to your most recent selection. For more information about shortcuts for the SMS Administrators console, see Appendix A, Accessibility for People with Disabilities.
Viewing Items in the Details Pane

While you explore the SMS Administrator console tree, the details pane displays the results of the currently selected item in the tree. Plus and minus signs alert you to the presence of child items in the tree. The details pane shows the results of an item or a listing of the child items within the chosen parent.
Using the SMS Toolbar

Only the buttons appropriate to the currently selected item appear or are enabled. The following table describes the SMS toolbar buttons.
Table 16.4 SMS Toolbar Buttons

Button Command Explore Console tree Up One Level Console Tree Pane Properties Refresh Help Print Export List Delete Description Moves forward and backward through previously selected console tree items. Moves up one level in the console tree hierarchy. Hides or shows the console tree. Displays the Properties dialog box of a highlighted item. Refreshes the current display. Starts SMS Help. Prints items in the details pane. Exports list views to a file. Deletes the selected item.
Displaying the Action and Shortcut Menus

The Action menu displays choices appropriate to the currently selected console tree item. For example, when you select Site Systems, clicking the Action menu and then pointing to New displays choices appropriate for creating new site systems. Right-clicking any item displays a shortcut menu, which provides the same options as the items Action menu.
Note
You can use the APPLICATION key ( ) on your keyboard to display action menus in dialog boxes. For example, in the Membership Rules dialog box for a new collection, press the APPLICATION key to display a menu for creating a new direct membership rule or query rule that corresponds to the toolbar icons in the dialog box.
Viewing and Modifying Properties

To change the configuration of an item, change the items properties. If an item can be configured, you can display its Properties dialog box in any of the following ways: u u u u On the SMS toolbar, click the Properties button. On the Action menu, click Properties. Right-click an item. On the duplicate of the Action menu that appears, click Properties. Double-click an item.
Fill in the data fields that are displayed on each tab of the dialog box as required to configure the item. Click OK to select and close the Properties dialog box or click Apply to save the changes and keep the dialog box open. For more information about completing the dialog box, see SMS Help.
Viewing Secondary Sites

A secondary site, which has client computers but does not have either an SMS site database nor an SMS Administrator console, passes its data to its parent primary site. You cannot use the SMS Administrator console to connect to secondary sites, although you can use it to manage secondary sites. You must first connect the SMS Administrator console to a primary site that the secondary site reports to. The secondary site does not have to report directly to the primary site.
Using the Import and Export Object Wizards

The Import and Export Object Wizards can be used to import and export individual collections, queries, reports, or classes of objects. You can, for example, share these object definitions between sites. For more information about the Import and Export Object Wizards, see SMS Help.
Using the Import Object Wizard

The Import Object Wizard guides you through the steps necessary to import collections, queries, or reports into the SMS site database from a Managed Object Format (MOF) file.
To import a collection, query, or report

1. 2. 3. In the SMS Administrator console, navigate to and right-click the object class that you want to import (Collection, Query, or Report). Point to All Tasks, and then click Import Objects. Complete the Import Object Wizard, and then click Finish.
Note
You must have Create permission to import objects.
Using the Export Object Wizard

The Export Object Wizard guides you through the steps necessary to export collections, queries, or reports from the SMS site database into a MOF file. You can use the Export Object Wizard to export individual collections, queries, or reports or classes of objects.
To export a collection, query, or report

1. 2. In the SMS Administrator console, navigate to and right-click the object or object class that you want to export (Collection, Query, or Report). Point to All Tasks, and then click Export Objects.
3.
Complete the Export Object Wizard, and then click Finish.
Note
You must have Read permission to export objects.
Starting SMS Service Manager

You can use SMS Service Manager to control the services that SMS uses. In SMS Service Manager, you can view the status of any SMS services or components that are running on any site system. You can start, stop, pause, resume, or query SMS components. You can also use SMS Service Manager to enable or disable logging. To start Service Manager, from the SMS Administrator console, navigate to SMS Service Manager.
Systems Management Server X Site Database (site code - site name) X Tools X SMS Service Manager
Right-click SMS Service Manager, point to All Tasks, and then click Start SMS Service Manager. For more information about SMS Service Manager, see SMS Help.
SMS and Microsoft Management Console

The SMS Administrator console is a snap-in for Microsoft Management Console (MMC) version 1.2 and later. A snap-in is an application built to run within MMC. MMC provides you with a console for administrative tools where a variety of network and server administration tasks can occur within a single, integrated interface. By using MMC, you can create and save customized consoles. You can then make these consoles available to administrators when you want to delegate specific management tasks. For example, you can create a customized console where an administrator can only use Remote Tools. However, to ensure their access is limited using Remote Tools, you must also adjust SMS security appropriately. For more information about console security, see Chapter 5, Understanding SMS Security.
Note
After upgrading to SMS 2003, your SMS 2.0 customized .msc file is automatically saved as SMS.msc.backup.
SMS and Microsoft Management Console 551
You can save any MMC console as a console file, which has an .msc file name extension. (The default SMS Administrator console file name is SMS.msc.) Console files contain data about the loaded snap-ins and the console view presented to the user. You can distribute console files to other SMS administrators.
Note
The administrator must have the SMS Administrator console installed on the computer to use the .msc file.
You have the option of running the SMS Administrator console in author mode. By default, the SMS Administrator console opens with author mode turned off. In author mode, you can grant the user of the console full access to all MMC functionality, including the ability to add or remove snap-ins, create new windows, create taskpad views and tasks, add items to the Favorites list, and view all portions of the console tree.
To start MMC in author mode

1. 2. On the Start menu, click Run. Type mmc, and then click OK.
For clarity, this chapter illustrates SMS as the only snap-in that is loaded. Depending on which snap-ins you have loaded and the order in which they are loaded, your actual console might look different. MMC 1.2 has the following new functions: u u Export List Views to a File Print Items in the Details Pane
Note
For more information about MMC, see the MMC Help, which you can access from within an MMC console.
Console Taskpads
You can create a taskpad view for a tree item in MMC. Taskpad views appear in the details pane and display shortcuts to commands. You can use a console taskpad to run tasks such as starting wizards, opening property pages, using menu commands, running command lines, and opening Web pages. With console taskpads you have better performance, UI consistency, and the ability to customize the taskpad. You can use taskpads to place commonly used SMS functions, SMS objects, Web pages, commands, scripts, and other features in one location. This makes your management of SMS more efficient. Console taskpads are implemented by MMC, which means that MMC sets up a console taskpad for a particular scope item.
To create a console taskpad

1. 2. On the Action menu, click New Taskpad View. The New Taskpad View Wizard prompts you for the information required to create the console taskpad. You can select task menu commands, shell commands, or navigation shortcuts.
The menu commands you can select are the same commands that are present in the shortcut menu of the selected scope item. This is because MMC gets menu commands from snap-ins in the same way.
Export List Views to a File

The data displayed in all Standard list views can be exported to a text file. The visible columns in the Standard list view are exported to a text file in the order in which they appear in the details pane. You can export data to a text file in two ways: u u On the Action menu, click Export List. Right-click an item. On the duplicate of the Action menu that appears, click Export List.
Print Items in the Details Pane

You can print items from the Standard list view in the details pane. The Standard list view is a taskpad view style that displays: u u u u u The taskpad title. Items that can be selected. Tasks that can perform actions on the selected items. On the Action menu, click Print. Right-click an item. On the duplicate of the Action menu that appears, click Print.
You can print items from the Standard list view in the details pane in two ways:
A print dialog box appears in which you can choose your preferences.
Creating Custom Consoles 553
Creating Custom Consoles

You can create new consoles that contain only specific console tree objects. You can then save these new consoles to disk and distribute them. For example, you can create an SMS Administrator console that has only the site Tools hierarchy item. The rest of the items are not displayed.
Note
You must first install the SMS Administrator console on the target computer and then replace the default .msc file with the custom .msc file that you create. Otherwise, the SMS Administrator console will not function.
To create a customized SMS Administrator console

1. 2. 3. 4. 5. 6. 7. 8. 9. If the SMS Administrator console is running, exit the application. On the Start menu, click Run. In the Open text box, type mmc, and then click OK. An MMC console, titled Console1, opens. On the Console menu, click Add/Remove Snap-in. Click Add. The Add Standalone Snap-in dialog box appears. Click Systems Management Server, and then click Add. The Welcome to the Site Database Connection Wizard dialog box appears. Click Next. The Locate Site Database dialog box appears. You can now specify the SMS site database you want to connect to. Verify that Reconnect to the site database for this site server is selected, and then click Select console items to be loaded (custom). Click Next. The Console Tree Items dialog box appears with the SMS console tree objects that are available for the new console.
10. Clear all options except SMS Tools, and then click Next. The Completing the Site Database Connection Wizard dialog box appears, displaying settings for the new console. 11. Click Finish. The Add Standalone Snap-in dialog box appears. You can select additional snap-ins to add to the console you are creating. If you want, you can repeat this process for additional connections to other sites. 12. Click Close. Systems Management Server 2003 is now displayed as a snap-in. Click OK. The Console1 console appears. Systems Management Server appears in the console tree under the Console Root item. 13. Expand the console tree. Note that the Tools hierarchy of items is displayed as the only branch beneath Systems Management Server.
14. On the Console menu, click Save As. 15. Type a name for this custom console, and then click Save. You have now created a custom console as a file that you can distribute and that administrators can use. Your customized MMC console offers users the functionality of only the Tools SMS Service Manager.
Note
For more information about adding published snap-ins to a new MMC console, see the MMC Help, which you can access from within an MMC console.
C H A P T E R
1 7
Discovering Resources and Deploying Clients

Microsoft Systems Manager Server (SMS) 2003 discovery methods are used individually or in combination to identify resources in your organization. The discovery methods that are used depend on which versions of the Microsoft Windows operating systems, network protocols, and other resources are used in your environment. SMS client installation methods are used to deploy the SMS client software to computers that you want to manage with SMS. The variety of client installation methods provided by SMS 2003 gives you flexibility to use the most appropriate method or set of methods for your organization. For conceptual information about discovery and client installation methods, see Chapter 4, Understanding SMS Clients. For information about planning which discovery and client installation methods to use, see Chapter 10, Planning Your SMS Deployment and Configuration.
Note
The terms SMS client, Advanced Client, and Legacy Client are frequently used to refer to either a client computer that has the SMS client software installed on it or to the SMS client software itself.
In This Chapter
u u u u u Enabling and Configuring Discovery Methods Installing and Configuring SMS Clients Assigning SMS Clients to an SMS Site Upgrading SMS Client Software Removing and Repairing SMS Client Software
556 Chapter 17 Discovering Resources and Deploying Clients
Enabling and Configuring Discovery Methods

Carefully plan for discovery methods before you enable them. For more information about planning for and controlling discovery, see Chapter 10, Planning Your SMS Deployment and Configuration. For conceptual information about the each discovery method, see Chapter 4, Understanding SMS Clients. You can configure discovery methods to set discovery type, discovery schedule, and other elements, such as domains and Active Directory containers, that apply to each discovery method. To configure discovery methods, you use the same dialog box in the SMS Administrator console that you use to enable the discovery methods. You enable and configure discovery methods on a site-wide basis. The exception to this is Network Discovery, which discovers resources that are outside the SMS site boundaries.
To enable the configurable discovery methods

1. In the SMS Administrator console, navigate to Discovery Methods.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Discovery Methods
2.
In the details pane, click a discovery method, select Properties on the Action menu (or right-click the discovery method and select Properties), and then select the Enable <discovery method> check box.
This section describes how to enable and configure each of the following discovery methods in the SMS Administrator console: u u u u u u u Network Discovery Heartbeat Discovery Windows User Account Discovery Windows User Group Discovery Active Directory System Discovery Active Discovery User Discovery Active Discovery System Group Discovery
Enabling and Configuring Discovery Methods 557
Note
Both the discovery of site systems and the creation of discovery data records (DDRs) during inventory are always enabled and do not have any configuration options. You cannot administer them. Resources are discovered by using these methods whenever appropriate.
Network Discovery
Before you enable Network Discovery, you must configure discovery type and discovery scope in the Network Discovery Properties dialog box in the Discovery Methods item in the SMS Administrator console.
Important
Using Network Discovery increases the amount of traffic on your network. If you enable Network Discovery without first planning and configuring it, you risk creating a significant network load that can hinder production use of network services. For planning and configuring information, see Chapter 10, Planning Your SMS Deployment and Configuration.
Discovery Type
In the Network Discovery Properties dialog box, select from three types of network discovery: u u u Topology Topology and client Topology, client, and client operating system
Each network discovery type gathers more information than the preceding type in the list.
Topology
You can discover subnets and network devices that have a Simple Network Management Protocol (SNMP) agent and detect how they are connected by selecting the Topology option in the Network Discovery Properties dialog box. The subnets that Network Discovery finds are listed on the Subnets tab in the Network Discovery Properties dialog box. The lock symbol next to each subnet indicates that SMS has found this subnet. You can enable the listed subnets so that Network Discovery discovers them during the next scheduled discovery. You can configure topology for Network Discovery by using the following tabs in the Network Discovery Properties dialog box: u u Subnets DHCP
u u
SNMP SNMP Devices
The available options on each of these tabs are described in the Discovery Scope section later in this chapter.
Important
The DHCP tab is available only if your SMS site is running in standard security mode.
Topology and Client

You can discover other IP devices within the subnets and domains that you specify by selecting the Topology and client option in the Network Discovery Properties dialog box. When the device is displayed under Collections in the SMS Administrator console, the IP address appears in the Name column. You can configure topology and client for Network Discovery by using the following tabs in the Network Discovery Properties dialog box: u u u u u Subnets DHCP SNMP SNMP Devices Domains
The available options on each of these tabs are described in the Discovery Scope section later in this chapter.
Topology, Client, and Client Operating System

You can discover subnets, IP devices, and client computer operating systems within the subnets and domains you specify by selecting the Topology, client, and client operating system option in the Network Discovery Properties dialog box.
Note
During Network Discovery, the operating systems for all computers that are 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, after you install computers running Windows 98 as SMS clients, their operating system is displayed correctly.
You can configure topology, client, and client operating system for Network Discovery by using the following tabs in the Network Discovery Properties dialog box: u u u u u Subnets DHCP SNMP SNMP Devices Domains
The available options on each of these tabs are described in the Discovery Scope section.
Discovery Scope
You can specify the discovery scope, and you can enable and configure a combination of discovery options by using the following tabs in the Network Discovery Properties dialog box: u u u u u u Subnets Domains SNMP SNMP Devices DHCP Schedule
Subnets Tab
By default, Network Discovery attempts to discover the subnet that the SMS site server is in. You can disable this feature on the Subnets tab by clearing the Search local subnets check box. You can also specify other subnets that you want to discover by clicking the Add button and specifying the subnet IP address and mask. On the Subnets tab, Network Discovery lists the subnets that it found during each previous discovery and marks them with a lock icon, which indicates that they cannot be modified or deleted. From this list, you can enable the subnets you want to be discovered during the next discovery, which gives you control over which subnets discovery runs on. You enable the subnets by highlighting the subnet in the list and clicking Enable/disable. You cannot delete or modify the subnets that Network Discovery finds and lists. You cannot view the properties of any subnets that Network Discovery finds and lists. You can view only the properties of subnets that you enter manually. After Network Discovery discovers them, however, you cannot change their properties. If your SMS site server has multiple network adapters, a subnet appears for each network adapter.
Domains Tab
You can use the Domains tab to configure Network Discovery to discover computers in the same domains that are displayed when you use the SMS site server to browse My Network Places. By default, Network Discovery attempts to enumerate the computers in the local domain by using the Windows Computer Network Browser service. You can disable this feature on the Domains tab by clearing the Search local domain check box. You can also specify additional domains you want to discover by clicking the Add button and typing in each domain name that you want to discover.
Note
Even though Network Discovery gathers data about resources in domains, a DDR is created only for each device within the discovery scope that has an IP address.
If you run Network Discovery with all options disabled except options on the Domains tab, and you have selected the Topology, Client, and Operating System discovery type, Network Discovery does not create a DDR for the computers it finds. If no DDR is stored in the SMS site database for a specific computer that is running Windows NT 4.0, Windows 2000, Windows XP, or operating systems in the Windows Server 2003 family, Client Push Installation cannot be used to install SMS client software on it. To use both Network Discovery and Client Push Installation to install SMS clients, you must also configure the options on one or more of the DHCP, SNMP, and Subnet tabs.
SNMP Tab and SNMP Devices Tab

To gather data from SNMP devices, specify the SNMP community names that Network Discovery uses to access SNMP-enabled devices. Network Discovery cycles through all of the listed names until it finds a name that can be used successfully. If none can be used, Network Discovery stops the discovery attempt on that device. If you remove the public community name and no other community names are specified, SNMP is not used for network discovery. You can use the Add button on the SNMP Devices tab to specify additional SNMP devices that you want to discover.
DHCP Tab
If your SMS site is running in standard security mode, the DHCP tab is available in the Network Discovery Properties dialog box. You can configure which Microsoft DHCP servers Network Discovery gathers data from by typing their IP addresses on the DHCP tab. To prevent Network Discovery from discovering your site servers DHCP server, disable the Use local DHCP servers option or ensure that your site server is not also a DHCP client.
Note
SMS gathers data only from Microsoft DHCP servers, not from third-party DHCP servers.
Schedule Tab
Use the Add button on the Schedule tab to create a schedule that specifies discovery duration and the date and time to start Network Discovery. After you select a start time, Network Discovery begins at the scheduled time. When the scheduled discovery time arrives, Network Discovery uses the configuration currently specified. If you are running Network Discovery on a large network, and you want it to stop at a specific time, even if it is not completely finished, you can use the Duration options to stop discovery at the appropriate time.
Heartbeat Discovery
To keep existing DDRs updated so that they are not deleted from the SMS site database, you can enable Heartbeat Discovery. You configure the schedule for SMS to generate these updated DDRs in the Heartbeat Discovery Properties dialog box in the Discovery Methods item in the SMS Administrator console. You can configure the discovery schedule on the General tab. You can set a full schedule on Heartbeat Discovery so that clients report their discovery data at a specific time on a regular basis. You should avoid doing this in large SMS sites or on many sites at the same time, because your network and SMS servers could experience a considerable load when Heartbeat Discovery runs on all clients concurrently. If you configure Heartbeat Discovery to a frequency that is less than the frequency at which the client refresh cycle runs (every 25 hours), the SMS site receives Heartbeat Discovery DDRs only at the frequency at which the client refresh cycle runs.
Note
Heartbeat Discovery is not used to generate new DDRs. It only updates existing DDRs.
Windows User Account Discovery and Windows User Group Discovery

You can configure the domains that the Windows User Account and the Windows User Group discovery methods scan for domain users and groups. You configure these methods in the Windows User Account Discovery Properties dialog box and the Windows User Group Discovery Properties dialog box in the Discovery Methods item in the SMS Administrator console.
You can configure the frequency at which this scanning is done by clicking the Schedule button on the Polling Schedule tab. The schedule that you create specifies when the Windows User Account Discovery method and the Windows User Group Discovery method polls each domain and generates a new DDR for all user or group accounts in each domain. If you do not select Run discovery as soon as possible on the Polling Schedule tab for each discovery method, no resources are discovered until the next scheduled discovery.
Active Directory Discovery Methods

You can configure the three types of Active Directory Discovery in the Active Directory System Discovery, Active Directory User Discovery, and Active Directory System Group Discovery Properties dialog boxes in the Discovery Methods item in the SMS Administrator console. You must specify at least one Active Directory container for the Active Directory Discovery method you enable. You specify the schedule for discovery to run on the Polling Schedule tab. The schedule that you create specifies when the Active Directory discovery method polls the closest Active Directory resource to discover systems, users, or system groups in the container that you specify. If you do not select Run discovery as soon as possible on the Polling Schedule tab for each discovery method, no resources are discovered until the next scheduled discovery. After you specify which Active Directory containers to scan, you specify whether to scan recursively. Recursive scanning finds objects that are stored in the Active Directory containers that you specify, and it finds any subcontainers. By default, all containers are scanned recursively. You can toggle the recursive scanning of containers by selecting the container and then clicking the Recursive button. If you want to ensure that the Active Directory discovery methods use a particular domain controller, specify the Active Directory container by using a query with the following syntax:
LDAP://<server>/DC=<domain>,DC=<third tier DNS name>,DC=<second tier DNS name>,DC=<first tier DNS name>
If you want to ensure that the Active Directory discovery methods use the Active Directory global catalog, specify the Active Directory container by using a query with the following syntax:
GC://DC=<domain>,DC=<third tier DNS name>,DC=<second tier DNS name>,DC=<first tier DNS name>
Installing and Configuring SMS Clients 563
Installing and Configuring SMS Clients

The techniques and methods that you can use to install the Advanced Client and Legacy Client are described in Chapter 4, Understanding SMS Clients. Some methods are configured using the SMS Administrator console, and others involve initiating a program file at the client that invokes the installation. You can manually initiate a program file at the client by using logon scripts, a software distribution technique, or Windows Group Policy. This section describes how to use these techniques for installing Advanced Clients and Legacy Clients. For information about planning your client deployment and which deployment technique to use, see Chapter 10, Planning Your SMS Deployment and Configuration, and see Tables 10.6 and 10.7, which display the techniques and methods available to each client type.
Installing the Advanced Client

This section describes using the Advanced Client Installer and how to deploy the Advanced Client by using these techniques: u u u Automated installation by using the SMS Administrator console Initiating a program file at the client Computer imaging
Using Advanced Client Installer

This section describes using Ccmsetup.exe to invoke the Advanced Client Installer. The Advanced Client Installer works in the background in all Advanced Client installations, regardless of the SMS deployment method that you use. Ccmsetup.exe is in the Client\i386 folder of the SMS_<site code> shared folder on the SMS site server. It is also available on the SMS 2003 product CD in the SMSSetup\Client\i386 folder. To enable users to run it from other locations, such as domain controllers, you can copy it to those locations. However, if you install a future version of SMS, such as a service pack, that includes an updated version of Ccmsetup.exe, you must update the copies of the Ccmsetup.exe file that you put in these other locations. For more information, see the Initiating a Program File at the Client section later in this chapter.
Ccmsetup.exe uses command-line options to modify its behavior, and then calls the Client.msi program, in which specified installation properties are used to complete the client installation. You can run the Ccmsetup.exe without any command-line options. If you do, you must ensure that there is a copy of Client.msi in the same folder with Ccmsetup.exe. Client.msi is in the SMSClient\i386 shared folder on management points or in the Client\i386 folder in the SMS_<site code> shared folder on the SMS site server. It is also available on the SMS 2003 CD in the SMSSetup\Client\i386 folder. When a user is logged on to the client computer, the Advanced Client Installer pulls files (including Client.msi and any language-specific files and folders) down to the computer before it initiates the SMS client software installation, and stores the files in the %Windir%\System32\ccmsetup folder. It then sets up as a Windows service that installs the Advanced Client. Administrators can modify this default behavior by using the command-line options and installation properties that are described here to modify Advanced Client Installer options. By default, the Advanced Client is installed to the %Windir%\System32\CCM folder. Ccmsetup.exe command-line syntax is as follows:
Ccmsetup.exe <command-line options> <installation properties>
Command-line Options
Command-line options for Ccmsetup.exe are identified by a forward slash (/). The switches described here are used alone or in combination on the command line following Ccmsetup.exe. These options modify Advanced Client Installer behavior.
/source:
Provides a local or remote location where Ccmsetup.exe locates Client.msi and any languagespecific files or folders, such as Client.mst. You can specify this switch multiple times to provide more than one possible installation source. The syntax for this switch is:
Ccmsetup.exe /source:<folder>
For example,
Ccmsetup.exe /source:<folder> SMSSITECODE=AUTO
Note
For more information about the SMSSITECODE installation property, see the Installation Properties section later in this chapter.
/mp
Provides a management point as an installation source. This source is added to the source list as \\<server>\SMSclient\i386. You can specify this switch multiple times to provide more than one management point. The syntax for this switch is:
Ccmsetup.exe /mp:<server>
For example,
Ccmsetup.exe /mp:<server> SMSSITECODE=AUTO
/useronly
Forces Ccmsetup.exe to run in the logged-on users security context. Be careful when using this option. If the user does not have administrative credentials, the operation will fail.
Ccmsetup.exe /useronly SMSSITECODE=AUTO
/service
Forces Ccmsetup.exe to run in the local system account context. The Client.msi file download and the client installation are both performed in the local system context. Use this option only when you are using Active Directory and the client computer account has access to the SMSClient\i386 shared folder on the management point. If the user does not have administrative credentials, the operation will fail.
Ccmsetup.exe /service SMSSITECODE=AUTO
Installation Properties
The properties described here are used alone or in combination following any command-line options that are specified after Ccmsetup.exe on the command line. These properties modify Client.msi behavior. Installation properties for Ccmsetup.exe do not use a forward slash (/).
Note
You can also specify these installation properties on the Advanced Client tab in the Client Push Installation Properties dialog box in the SMS Administrator console. For more information, see the Configuring Client Push Installation section later in this chapter.
CCMINSTALLDIR Identifies the folder where the Advanced Client files are installed. If this property is not set, then the client software is installed in the %Windir%\System32\CCM folder.
Ccmsetup.exe CCMINSTALLDIR=<installation folder>
CCMADMINS Allows SMS administrators to specify one or more user or group accounts to grant the same Advanced Client settings and policy access as those in the local Administrators group. The syntax for this installation property is:
Ccmsetup.exe CCMADMINS=<account>[;<account>[...]]
where account is a user or group account in the format domain\name.

Ccmsetup.exe CCMADMINS="MyDomain\SMS Admins;MyDomain\JohnDoe"
When you are specifying a single account, the quotation marks are optional. For multiple accounts, they are required. If you do not use quotation marks for multiple accounts, the first account is the only account applied. CCMALLOWSILENTREBOOT If this property is set to 1 and a reboot is required to complete the Advanced Client installation, the computer is rebooted, even if a user is currently logged on.
Ccmsetup.exe CCMALLOWSILENTREBOOT=1
CCMDEBUGLOGGING Enables debug logging. Values can be 0 (off) or 1 (on). The default value is 0. This causes the client to log low-level information that might be useful for troubleshooting client problems. Use this command-line switch only in your test lab environment. As a best practice, avoid using this property in production deployments because excessive logging can occur. This must be used with CCMENABLELOGGING.
Ccmsetup.exe CCMDEBUGLOGGING=1 CCMENABLELOGGING=TRUE
CCMENABLELOGGING Enables logging if this property is set to TRUE. By default, logging is disabled. The log files are stored in the Logs folder in the Advanced Client installation folder. By default, this folder is %Windir%\System32\CCM\Logs.
Ccmsetup.exe CCMENABLELOGGING=TRUE
CCMLOGLEVEL Identifies the logging level. Specify an integer ranging from 0 to 3, where 0 is the most verbose logging, and 3 logs only errors. The default is 1. Set logging level to 0 (verbose mode) to provide messages that allow component operations to be traced:
Ccmsetup.exe CCMLOGLEVEL=0
Set logging level to 1 to log only informational, warning, and error messages:
Set logging level to 2 to log only warning and error messages:

Set logging level to 3 to log only error messages:

CCMLOGMAXHISTORY Specifies maximum number of previous versions of the log file to keep. If this property is set to 0, no history is kept. The default is 1. For example, to keep one version of the log file:
Ccmsetup.exe CCMLOGMAXHISTORY=1
CCMLOGMAXSIZE Specifies the maximum log file size in bytes. When a log grows to the size that is specified, it is renamed as a history file, and a new file is created. This property must be at least 10000. The default value is 250000. For example, to allow for a maximum log file size of 20,000 bytes before the file is renamed as a history file and a new file is created:
Ccmsetup.exe CCMLOGMAXSIZE=20000
DISABLESITEOPT Disables the ability of end users with administrative credentials on the client computer to change the Advanced Clients assigned site using the Systems Management icon in Control Panel.
Ccmsetup.exe DISABLESITEOPT=TRUE
DISABLECACHEOPT Disables the ability of end users with administrative credentials on the client computer to change the cache settings for the Advanced Client by using the Systems Management icon in Control Panel when it is set to TRUE.
Ccmsetup.exe DISABLECACHEOPT=TRUE
SMSCACHEDIR Specifies the Advanced Client cache used to store packages that are downloaded before they are run. This can be a relative or absolute path. If the path that is specified does not contain a specific drive letter, the cache is installed on the disk that is identified by SMSCACHEFLAGS. If the path contains a specific drive letter, the drive identification flag in SMSCACHEFLAGS is ignored. Do not use a backslash (\) at the beginning of the path when you are specifying a relative path. If this property is set to C:\temp, for example, the cache is created as C:\temp\CCMcache. If this property is not set, the cache is installed to a folder named Cache in the folder where the Advanced Client is installed. By default, this folder is %Windir%\System32\CCM\Cache. The syntax for this property is:
Ccmsetup.exe SMSCACHEDIR=<folder path>
For example, to create the cache as C:\temp\CCMcache

Ccmsetup.exe SMSCACHEDIR="C:\temp"
To create the cache on the largest disk:

Ccmsetup.exe SMSCACHEDIR=Cache SMSCACHEFLAGS=MAXDRIVE
Note
Use quotation marks around folder paths that contain spaces. If folder paths do not contain spaces, quotation marks are optional.
SMSCACHESIZE Specifies cache size in MB or as a percentage. If this property is not set, the cache defaults to a maximum size of 250 MB. If a new package that must be downloaded would cause the cache to exceed the maximum cache size, and the cache cannot be purged to make sufficient space available, then the package download fails and the advertised program does not run.
Ccmsetup.exe SMSCACHESIZE=50
SMSCACHEFLAGS Allows control of the SMS cache. You can use SMSCACHEFLAGS properties individually or in combination, separated by semicolons. If this property is not specified, the cache is installed according to the SMSCACHEDIR property, the cache is not compressed, and the SMSCACHESIZE value is used as the size in MB of the cache. Use PERCENTDISKSPACE to specify cache size as a percentage of disk space. If this flag is set, then the SMSCACHESIZE property must be expressed in a percentage value for the SMS cache. You cannot use this flag with the PERCENTFREEDISKSPACE flag.
Ccmsetup.exe SMSCACHEFLAGS=PERCENTDISKSPACE
Use the PERCENTFREEDISKSPACE flag when SMSCACHESIZE is a percentage of free disk space, calculated when the cache is created. For example, if 10 MB is free on the disk, and the SMSCACHESIZE value is 50, then the cache is set to 5 MB. You cannot use this flag with the PERCENTDISKSPACE flag.
568 Chapter 17 Discovering Resources and Deploying Clients Ccmsetup.exe SMSCACHEFLAGS=PERCENTFREEDISKSPACE
Use MAXDRIVE to install the cache on the largest disk. This value is valid only if a relative path for the folder is specified using the SMSCACHEDIR property. You cannot use this flag with the MAXDRIVESPACE flag.
Ccmsetup.exe SMSCACHEFLAGS=MAXDRIVE;SMSCACHEDIR="<folder path>"
Use MAXDRIVESPACE to use the drive with maximum free space for the cache. This value is valid only if a relative path for the folder is specified by using the SMSCACHEDIR property.
Ccmsetup.exe SMSCACHEFLAGS=MAXDRIVESPACE; SMSCACHEDIR="<folder path>"
Use NTFSONLY to use only disks that are formatted with the NTFS file system for the location of the cache. This value is valid only if a relative path for the folder is specified by using the SMSCACHEDIR property. Use this flag with MAXDRIVESPACE or MAXDRIVE.
Ccmsetup.exe SMSCACHEFLAGS=NTSFONLY; SMSCACHEDIR="<folder path>"
Use COMPRESS to compress contents of the cache.

Ccmsetup.exe SMSCACHEFLAGS=COMPRESS
Use FAILIFNOSPACE to remove the client software if the disk does not have enough space for the cache as specified in SMSCACHESIZE. The installation is completed even if there is insufficient disk space for the cache.
Ccmsetup.exe SMSCACHEFLAGS=FAILIFNOSPACE
SMSCONFIGSOURCE Specifies where and in what order the Advanced Client Installer checks for configuration settings. The property is a string containing one or more characters, each defining a specific configuration source. Use the character values R, P, M, and U, alone or in combination, as shown in the examples below. By default, the client installation uses PU to check first the installation properties and then the existing settings. Use R to instruct the client installation program to check for configuration settings in the registry:
Ccmsetup.exe SMSCONFIGSOURCE=R
Use P to instruct the client installation program to check for configuration settings in the installation properties provided on the command line:
Ccmsetup.exe SMSCONFIGSOURCE=P
Use M to instruct the client installation program to check for configuration settings when you are replacing an existing SMS 2.0 client or Legacy Client with the Advanced Client (uses the existing site code):
Ccmsetup.exe SMSCONFIGSOURCE=M
Important
Do not use the M value on SMSCONFIGSOURCE if you are upgrading any SMS 2.0 or SMS 2003 Legacy Clients that are currently assigned to an SMS 2.0 secondary site. These clients will become orphaned because Advanced Clients cannot be assigned to secondary sites.
Use U to upgrade the Advanced Client to a newer version of the Advanced Client (uses the assigned site code):
Ccmsetup.exe SMSCONFIGSOURCE=U
To use multiple configuration sources, specify multiple characters. For example, use RP to force the client installation program to first check for configuration options in the registry and then check the installation properties on the command line:
Ccmsetup.exe SMSCONFIGSOURCE=RP
When you are installing Advanced Clients, specify the SMSCONFIGSOURCE property with the options in the order that is most appropriate for your deployment plan so clients have the maximum opportunity to find a suitable site code and client type. For example, you might use PUM so that if the installation is an upgrade from the Legacy Client or an older version of the Advanced Client, the existing site code is used. However, the administrator can still override the existing site code on the command line by using the SMSSITECODE property. See the Important note about the M value, earlier in this section, before you use this property during a client upgrade. SMSNOWINSLOOKUP Controls failover from Active Directory to WINS. If the property is set to TRUE, the Advanced Client does not fail over from Active Directory to WINS to look up the resident management point. If missing or set to FALSE, the client fails over from Active Directory to WINS.
Ccmsetup.exe SMSNOWINSLOOKUP=TRUE
SMSPREFERREDCLIENT Functions the same as the PREFERREDCLIENT registry entry, except that only the REMOTE and ANY values are valid. If the property is set to ANY, Advanced Client installation proceeds only if the Legacy Client is not installed.
Ccmsetup.exe SMSPREFERREDCLIENT=ANY
SMSSITECODE Specifies the SMS site to assign the Advanced Client to. This can either be a three-character SMS site code or the word AUTO. If AUTO is specified, the Advanced Client attempts to determine its SMS site assignment by using Active Directory or server locator points.
Ccmsetup.exe SMSSITECODE=AUTO
Important
If you do not set the SMSSITECODE property (to either AUTO or a threecharacter SMS site code) when you run Ccmsetup.exe, the client software is installed, but the client is not assigned to an SMS site. In this state, the client is installed, but it is not functional and is considered dormant.
Command examples
The commands in this section demonstrate various options for installing the Advanced Client. The following command installs the Advanced Client by using default values for command-line options. If an SMS site code is not entered, the client is installed, but it is not assigned to a site. The Advanced Client components do not log their activities. The cache is a folder called Cache under the folder where the Advanced Client is installed. It is not compressed, and its maximum size is 250 MB.
Ccmsetup.exe
The following command is the same as the previous example, but the client is assigned to SMS site XYZ. Logging of the Advanced Client activities is enabled, and the logging level is set to verbose.
Ccmsetup.exe SMSSITECODE=XYZ CCMENABLELOGGING=TRUE CCMLOGLEVEL=0
The following command is the same as the first example, except that Ccmsetup.exe looks in the Windows registry for the SMS site code. The registry might also indicate that only the Legacy Client or no client is to be installed on this computer, in which case Ccmsetup.exe does not install the Advanced Client. If the Advanced Client is to be installed, but the site code registry value is not found, the SMS Advanced Client Setup Wizard is displayed.
Ccmsetup.exe SMSCONFIGSOURCE=R
The following command is the same as the first example except that the cache is created in a folder named \<installation folder>\Cache on the NTFS file system disk with the most free space. The maximum cache size is 50 percent of the available free space on that disk.
Ccmsetup.exe SMSCACHEFLAGS=NTFSONLY;COMPRESS;MAXDRIVESPACE;PERCENTFREEDISKSPACE SMSCACHEDIR="\<installation folder>\Cache" SMSCACHESIZE=50
Automated Installation by Using the SMS Administrator Console

To deploy the SMS Advanced Client software by using the SMS Administrator console, you enable and configure Client Push Installation. Client Push Installation is started when computers that require installation with Client Push Installation are discovered, as configured in the Client Push Installation properties. Client Push Installation can also be started from a collection or resource by using the Client Push Installation Wizard.
Important
Client Push Installation configuration is automatically used by the Client Push Installation Wizard even if Client Push Installation is not enabled.
To prepare the SMS Site for Client Push Installation

1. In the SMS Administrator console, navigate to Client Installation Methods.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Client Installation Methods
2.
In the Client Push Installation Properties dialog box, click the Accounts tab, and then specify a valid remote installation account. This account must have administrative credentials on client computers. Ensure that the security accounts used for Client Push Installation are specified on the Accounts tab. Because a single account might not work for all computers (for example, because the computers might be in multiple domains), you can specify multiple accounts. Each account is tried in the order specified until one succeeds. If the SMS site is in standard security mode, Client Push Installation tries the SMS Service account after the other accounts have been tried. In advanced security mode, only the accounts listed on the tab are tried. Alternatively, you can specify %ComputerName%\AccountName on the Accounts tab. This substitutes the name of the computer the client is deployed to on for %ComputerName% so that installation can proceed using a local administrator account on the computer.
3.
Navigate to Component Configuration, and then specify an Advanced Client network access account on the General tab in the Software Distribution Properties dialog box.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Component Configuration
4.
Navigate to Site Systems, and then configure an SMS site system as a management point. Ensure that there is at least one default management point in the site.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Site Systems
You can troubleshoot Advanced Client Push Installation problems, by reviewing the Ccm.log file on the SMS site server, located in the SMS\Logs folder. On the client computer, review the Ccmsetup.log and Client.msi.log file, located in %Windir%\System32\ccmsetup folder.
Important
Client Push Installation does not deploy Advanced Clients if the SMS site does not have a management point configured.
Enabling Client Push Installation

After you have prepared the SMS site, you are ready to enable the Client Push Installation method.
To enable the Client Push Installation method

1. Navigate to Client Push Installation in the SMS Administrator console.
Systems Management Server X Site Database (site code - site name) X Site Hierarchy X site code - site name X Site Settings X Client Installation Methods X Client Push Installation
2.
In the details pane, click Client Push Installation, select Properties on the Action menu, (or right-click Client Push Installation and select Properties), and then click Enable Client Push Installation. To include SMS site systems in the Client Push Installation, you must also select the Enable Client Push Installation to site systems option on the General tab.
Configuring Client Push Installation

Using the same dialog box that you used to enable Client Push Installation, you can configure it to install to any combination of the following: u u u Servers (other than domain controllers) Workstations Domain controllers
If you want to use Client Push Installation to install the SMS client on domain controllers, you must enable Client Push Installation to both domain controllers and servers. If you do not want to enable Client Push Installation for servers, you can create a collection or query for the domain controllers and use the Client Push Installation Wizard.
Note
Network Discovery triggers Client Push Installation only on computers for which the SMS site server does not have DDRs, even if the SMS client has been removed from the computers. If you remove an SMS client and want to install it again with Client Push Installation, run the Clear Install Flag maintenance task. For more information about this task, see Chapter 13, Maintaining and Monitoring SMS Systems, in the Microsoft Systems Management Server 2003 Operations Guide.
You can configure Client Push Installation to install only Advanced Clients by using the Client types options. If you want to use the Advanced Client on all computers that support it, select Platform dependent. On the Advanced Client tab, specify the installation properties that were used when you installed the Advanced Client. For more information about Advanced Client installation properties, see the Installation Properties section earlier in this chapter. If you must exclude any computers from Client Push Installation, you can specify them by using the following REG_MULTI_SZ registry value on the SMS site server. Enter the name of each client you want to exclude on a separate line: HKLM\Software\SMS\Components\SMS_DATA_DISCOVERY_DATA_MANAGER\Excl udeServers
Important
This exclusion registry entry does not apply to the Client Push Installation Wizard.

You can use the Client Push Installation Wizard by right-clicking a collection or query in the SMS Administrator console. On the All Tasks menu, select Install Client. Or, you can rightclick an individual computer in a collection or query results list, and then select Install Client from the All Tasks menu. Follow the instructions that are provided in the wizard. To install clients at a child site of the site the SMS Administrator console is connected to, you can elect in the Client Push Installation Wizard to install Advanced Clients, and clear the Include only clients assigned to this site check box. If you do not do this, you can install SMS client software only on resources that are assigned to the site that the SMS Administrator console is connected to. This ensures that active clients are not replaced with an SMS client that is not assigned to any site. You must configure Client Push Installation for the Client Push Installation Wizard to work. Enabling Client Push Installation is not necessary.
When you use the Client Push Installation Wizard to initiate Advanced Client installation, the Advanced Client software components are downloaded and installed if the version of the Advanced Client software on the management point is newer than the version already installed on the client computer. The Advanced Client software components are not downloaded or installed if the version of the Advanced Client software on the management point is older than the version already installed on the client. If the version of the Advanced Client software on the management point is the same as the version already installed on the client, then the Advanced Client software is downloaded but not installed. In this case, no change is made to the client unless the SMS site code has changed.
Note
Unlike the Client Push Installation Wizard, the Client Push Installation method is a site-wide setting. When you use the Client Push Installation method, if the Advanced Client is already installed on the client computer, it is not installed again.
Initiating a Program File at the Client

This section describes three techniques for initiating a program file at the client computer that installs the Advanced Client: u u u Logon Script-initiated Client Installation Manual Installation Software Distribution

Use Logon Script-initiated Client Installation (Capinst.exe) to discover and install Advanced Clients when users log on. Capinst.exe is located in the Client\i386 folder in the SMS_<site code> shared folder on the SMS site server. It is also available on the SMS 2003 CD in the SMSSetup\Client\i386 folder. To enable users to run it from other locations, such as domain controllers, you must copy it to those locations. However, if a future version of SMS 2003 (including service packs and other updates) has an updated version of Capinst.exe, you must update the copies of Capinst.exe that you have put in these other locations. Client.msi, Ccmsetup.exe, and any language-specific files or folders must be in the same folder as Capinst.exe. Logon Script-initiated Client Installation never displays error messages. All messages are written to the %Temp%\Capinst.log file on the client. This section contains information about setting up the logon script and examples that illustrate Logon Script-initiated Client Installation by using Capinst.exe to install the Advanced Client.
Setting up logon scripts to discover and install clients

When you modify the logon script, you must include: u u u u A call to Capinst.exe. Any command-line options or installation properties. A script to ensure that computers that already have the SMS client. Do not try to reinstall it unnecessarily, unless you want to reinstall the clients. A script to ensure that computers that log on over slow network links do not try to install the client. For more information, see the Checking for slow network links section later in this chapter. A script to selectively install the SMS client software so that you do not install the SMS client on all computers in a short period of time, causing excessive network traffic, or so that you do not install SMS on computers that you must exclude from management by SMS.
Optionally, you can also include:
If your changes to the logon scripts use program files that are not available on all destination client computers, add those program files to the Netlogon shared folder on all your domain controllers. These files include: u u u Capinst.exe. Slownet2.exe or Rascheck.exe. Rndlogin.exe.
If you have too many domain controllers to manually configure them, you can set up file replication on a domain controller (usually the primary domain controller or equivalent), and then copy these files to the domain controller. That domain controller then replicates the files to all other domain controllers. For more information, see the Setting up file replication section later in this chapter. If you have a small number of domain controllers, you can copy the files to the Netlogon shared folder on the domain controllers.
Note
Windows Installer installs only one program at a time. If your logon script also installs other programs, you might want to configure the logon script to install the Advanced Client software first.
Use the Capinst.exe command in the logon script with the following switches, alone or in combination, to support and control Advanced Client installation. /AdvCli Installs the Advanced Client with a default configuration by using Ccmsetup.exe. The Advanced Client files are downloaded from the management point that the server locator point determines is appropriate for the client. If the /AdvCli switch is not used, or if the computer operating system is not supported by the Advanced Client, then the Legacy Client is installed. Ccmsetup.exe, Client.msi, and any relevant language-specific files or folders must be in the same folder as Capinst.exe. Use the following command to install the Advanced Client:
Capinst.exe /AdvCli /SLP=<server locator point>
/SLP= Indicates a server locator point to use during client installation. A server locator point server name must be specified with this switch. Do not specify a path to the server name. If this switch is not used, Capinst.exe automatically searches for a server locator point. For example, if your organization does not use Active Directory, and you want to install the Advanced Client, use the following command:
Capinst.exe /AdvCli /SLP=<server locator point>
Note
As a best practice, always include the /SLP switch when installing either type of SMS client with Logon Script-initiated Client Installation. Capinst.exe fails to find the server locator point if the Active Directory schema is not extended for SMS and the server locator point is not specified.
/AdvCliCmd Passes the rest of the string following /AdvCliCmd directly to Ccmsetup.exe, as in:
Capinst.exe /AdvCli /SLP=<server locator point> /AdvCliCmd <Client.msi installation properties>
For example,
Capinst.exe /AdvCli /SLP=<server locator point> /AdvCliCmd CCMENABLELOGGING=TRUE CCMLOGLEVEL=0 CCMLOGMAXSIZE=100000 CCMLOGMAXHISTORY=1
Important
If you do not specify the SMSSITECODE property on the Capinst.exe command, SMSSITECODE=AUTO is appended to the other installation properties and the Advanced Client is automatically assigned to an SMS site.
/AutoDetect= Calls a script or program file that is specified after this switch. The script or program file must be in the same folder as Capinst.exe. You can either specify the path or set the path as an environment variable on the client. The script must not display output to the user. The correct syntax is:
Capinst.exe /AutoDetect=<script>
The following is a sample script (Wscript.Echo):

set wmiObject = GetObject("winmgmts:root\CIMV2:Win32_SystemEnclosure='System Enclosure 0'") if wmiObject.ChassisTypes(0)=10 Then wscript.quit 1 else wscript.quit 0 end if
Important
This script is only an example. It does not successfully find laptops in all circumstances. For more information, see Chapter 2, Collecting Hardware and Software Inventory, in the Microsoft Systems Management Server 2003 Operations Guide.
Use /AutoDetect=<script> to install a Legacy Client, Advanced Client, or no client, depending upon the value returned by the script. If the /AutoDetect= return value is 1, and the client operating system is supported by the Advanced Client, then the Advanced Client is installed. If the /AutoDetect= return value is 1, and the client operating system is not supported by the Advanced Client, then the Legacy Client is installed. If the /AutoDetect= return value is 0, then the Legacy Client is installed. If the /AutoDetect= return value is other than 1 or 0, then no client is installed. /DC Installs the Advanced Client even when the destination computer is a domain controller:
Capinst.exe /DC
Checking for slow network links

Installing the SMS client from a logon script on a computer that has a slow network link to the source of the SMS client software files can take an extended period of time. If this is a likely situation for your users, include commands in your logon script to test the network link and skip the SMS client installation on slow links. You can use Slownet2.exe to test the network speed. Create the script as shown in the following sample script. This script presumes that the Slownet2.exe file is on the Netlogon shared folder of your domain controllers.
%0\..\Slownet2.exe IF ERRORLEVEL 1 GOTO SKIPSMS REM substitute this line with whichever SMS client installation command you use :SKIPSMS
In some cases, Slownet2.exe might be unreliable. If you use Remote Access Service (RAS), you can use the RAS Connection Tester (CheckRAS.exe) in place of Slownet.exe. RAS Connection Tester detects whether the network link is a RAS dial-up link. RAS Connection Tester does not work with all dial-up servers. As a best practice, test it with your dial-up solution to ensure that it works in your environment. Slownet2.exe is available on the SMS 2003 CD. RAS Connection Tester is included in the SMS 2.0 SP2 Support Tools, which you can download from http://www.microsoft.com/smserver/downloads.
Setting up file replication

For maximum efficiency and reliability, replicate the files that are used to install SMS clients from logon scripts to the Netlogon shared folder of every domain controller. If all your domain controllers run Windows 2000 or Windows Server 2003 family operating systems, you must use File Replication Service (FRS) to replicate the files. If you have Windows NT 4.0 domain controllers, you must use the Directory Replicator Service. If you have a mix of both kinds of domain controllers, see Microsoft Knowledge Base article 248358 at http://support.microsoft.com for more information about file replication in a mixed mode environment.
The Windows NT 4.0 Directory Replicator Service is configured using Server Manager or the Server icon in Control Panel on a Windows NT 4.0 domain controller. After replication is enabled, you must copy the logon script files to the Export\Scripts folder of the Repl$ shared folder on the computer that performs the replication. That computer then replicates those files to all the other Windows NT 4.0 domain controllers. FRS replication of files for the Netlogon shared folder is enabled by default on all domain controllers that are running Windows 2000 or Windows Server 2003 family operating systems. You copy the logon script files to the <domain>\Scripts folder of the Sysvol shared folder on any domain controller. The files are automatically replicated to all other domain controllers that are running Windows 2000 Windows Server 2003 family operating systems. If you have multiple user account domains, the above process must be repeated for each domain that contains SMS clients.
Manual Installation
To install the Advanced Client manually on a client computer, use the Advanced Client Installer (Ccmsetup.exe). For more information about using Ccmsetup.exe, see the Using Advanced Client Installer section earlier in this chapter.
To install Advanced Clients through software distribution, use Ccmsetup.exe with your software distribution package. You can fully preconfigure the client using registry entries and commandline options described earlier in this section. Also, SMS 2003 includes a package definition file (Smsclint.sms) for distributing the Advanced Client by using SMS software distribution. This file is installed on your SMS site server only if you choose the optional Package Automation Scripts during SMS setup. It is also available on the SMS 2003 CD. Use the Create Package from Definition Wizard to use this package definition file. For information about using the Create Package from Definition Wizard, see Chapter 5, Distributing Software, in the Microsoft Systems Management Server 2003 Operations Guide.
Using Computer 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. When the master image is deployed to computers, the Advanced Client is preinstalled on those computers and remains dormant until you assign the client to an SMS site.
Computer Imaging Tips

Install the Advanced Client software on the master computer image using techniques described in the Using Advanced Client Installer and Initiating a Program File at the Client sections earlier in this chapter. To complete deployment of the Advanced Client on a computer that has been set up by using a master image, specify a site code in the Systems Management icon in Control Panel.
Each Advanced Client must also have a security certificate for the computer that it is installed on. The Advanced Client generates a valid certificate if the previous one is removed. Remove certificates by extracting and running the CCMdelcert.exe tool from the CCMtools.msi file found on the SMS 2003 CD in the SMSSetup\Tools folder. Delete the certificate on the original computer before the master image is created. If a client refresh cycle runs, such as when the computer reboots, then before the image is created, the certificate must be deleted again.
Registry Modifications
If the logged-on users at the client computers that you deploy the Advanced Client to through software distribution have administrative credentials, you have the option of preconfiguring the client computers with specific Advanced Client options. These options are configurable through the Windows registry: u u Setting the preferred client type Assigning the client to an SMS site
Caution
Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
These registry entries are valid only if the Advanced Client is installed with the SMSCONFIGURESOURCE switch set to R. The Advanced Client Installer (Ccmsetup.exe) passes these options to Client.msi during Advanced Client installation.
Setting the preferred client type

Use the following registry subkey to set the preferred client type to install:
HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\SmsClientConfig\PREFERREDCLIENT
The PREFERREDCLIENT registry value specifies which client type to install on the computer. If this registry value is not available, the default behavior for Client.msi is to install the Advanced Client and remove the Legacy Client if it is already installed. Table 17.1 summarizes these registry entry values. Table 17.1 Registry Entry Values
Value Standard Remote Any None Effect Install only the Legacy Client on this computer. Install only the Advanced Client on this computer. Install either the Legacy Client or the Advanced Client on this computer. Installation proceeds only if the Legacy Client is not installed. Install no SMS client on this computer.
Note
The Legacy Client installation methods do not respect the PREFERREDCLIENT registry value. These methods install the Legacy Client even if this registry value is set to REMOTE or NONE, unless the Advanced Client software is already installed.
Assigning the client to an SMS site

Use the following registry subkey to set an SMS site to assign the client to: HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\SmsClientConfig\SITECODE The SITECODE registry value specifies the SMS site to assign the installed Advanced Client to. Specify either a three-character site code, or the string AUTO. The default action, if this property is not set, is to leave the client unassigned. The client remains dormant until you assign it to an SMS site.
Installing the Legacy Client

For information about planning which techniques to use to install the Legacy Client, see the Deploying SMS Clients section and Table 10.7 in Chapter 10, Planning Your SMS Deployment and Configuration. This section describes how to deploy the Legacy Client by using these techniques: u u Automated installation using the SMS Administrator console Initiating a program file at the client
By default, the core SMS Legacy Client software components are installed in the %Windir%\MS\SMS folder.
Automated Installation by Using the SMS Administrator Console

To deploy the SMS Legacy Client software by using the SMS Administrator console, you enable and configure Client Push Installation as described in the Installing the Advanced Client section earlier in this chapter. Configure Client Push Installation to install only Legacy Clients by using the Client types options. If you want to install the Legacy Client on computers that cannot support the Advanced Client, such as computers running Windows NT Workstation 4.0, select Platform dependent. Be sure there is a client access point (CAP) available in each SMS site where you want to install the Legacy Client. If no CAP is available, then the installation fails.
Initiating a Program File at the Client

There are two techniques for installing the Legacy Client by initiating a program file at the client computer: u u Logon Script-initiated Client Installation Manual Client Installation
Important
When you use Logon Script-initiated Client Installation or Manual Client Installation to install an SMS Legacy Client in a site that is using advanced security mode, and the client computer has insufficient security credentials, ensure that you specify a valid client connection account in SMS. You must set up the client connection account manually. For more information, see Chapter 12, Planning Your SMS Security Strategy.

Using Logon Script-initiated Client Installation (Capinst.exe) to discover and install Legacy Clients when users log on is very similar to using Logon Script-initiated Client Installation to install Advanced Clients. Capinst.exe works with server locator points and CAPs to install the Legacy Client. If your organization uses Active Directory, and you want to deploy the Legacy Client software by using Logon Script-initiated Client Installation, you can use the Capinst.exe command in the logon script. Capinst.exe checks with the server locator points returned from the Active Directory global catalog. It uses the first server locator point it locates that is associated with the site boundaries that the client computer is in. The first CAP returned by the server locator point for the site is used for client installation. If your organization does not use Active Directory, be sure to append the Capinst.exe command with the /SLP switch. For more information about using the /SLP switch, see the Setting up logon scripts to discover and install clients section earlier in this chapter. You can use /AutoDetect=<script> to install a Legacy Client, depending on the value returned by the script you point to. The Legacy Client only supports return values of 1 and 0. You cannot pass any parameters to SMSman.exe from the Capinst.exe command.
Manual Client Installation

Use Manual Client Installation (SMSman.exe) to install Legacy Clients manually. Manual Client Installation installs the Legacy Client directly from a CAP. You run SMSman.exe from the CAP using a Universal Naming Convention (UNC) path. If SMSman.exe is not run from a CAP using a UNC path, you must specify the CAP using the SMSman.exe command-line switches described later.
SMSman.exe is found in the Client\i386 folder of the SMS_<site code> shared folder on your SMS site server. It is also available on the SMS 2003 CD in the SMSSetup\Client\i386 folder. If you want users to run it from other locations, such as domain controllers, you must copy it to those locations. However, if you install a future version of SMS, such as a service pack, that includes an updated version of SMSman.exe, you must update the copies of the SMSman.exe file that you put in these other locations. If you run SMSman.exe without any switches, the Systems Management Installation Wizard is displayed. This wizard guides you through the process of Manual Client Installation. The following examples illustrate Manual Client Installation by using SMSman.exe with command-line switches that you can append to SMSman.exe.
/A
Automatically sets the SMS installation location to the path used to run the Systems Management Installation Wizard.
SMSman.exe /A
/D
Generates a DDR and skips client installation.
SMSman.exe /D
/H or /?
Displays command-line help.
SMSman.exe /H SMSman.exe /?
/M
Specifies the CAP path location. Use UNC path to the CAP in the form \\<server>\CAP_<site code>. The syntax for this command is:
SMSman.exe /M <CAP path>
For example,
SMSman.exe /M <\\<server>\CAP_<site code>>
/Q
Specifies quiet mode. No windows or messages are displayed, even if the installation fails.
SMSman.exe /Q
/T
Allows the Systems Management Installation Wizard to run in a Terminal Services session.
SMSman.exe /T
/U
Removes the core SMS client components.
SMSman.exe /U
/F
Forces the client to be assigned to the SMS site of the given CAP path.
SMSman.exe /F
Important
If /F is specified when running SMSman.exe on a computer that does not have an SMS client installed, and the user does not have sufficient security credentials on the computer, a request for the client to install using Client Push Installation is not generated.
Installing Clients with Insufficient Security Credentials

On computers running Windows NT 4.0, Windows 2000, Windows XP, or an operating system in the Windows Server 2003 family, installing the SMS client software requires administrative credentials on the computer. Most of the client installation methods run in the users security context. If the logged-on user does not have administrative credentials, the installation method fails. A client configuration request is created, which could trigger the installation of a client through Client Push Installation, but the client cannot be installed by the original client installation method. If you are attempting to install the Advanced Client, the technique that you use might be able to provide administrative credentials. For example, an SMS software package can be configured to provide the necessary administrative credentials. Or, you can use a discovery method combined with Client Push Installation to perform the installation. Client Push Installation is initiated when all of the following conditions are true: u u u The client is discovered but not installed. The resource is within the SMS site boundaries or roaming boundaries of the site. Client Push Installation is properly enabled and configured. For example, the discovered resource is included in the kinds of computers that Client Push Installation is configured to install (servers, workstations, and/or domain controllers). You can exclude computers on the basis of being SMS site systems by not selecting the Enable Client Push Installation to site systems check box.
For more information about using Client Push Installation, see the Configuring Client Push Installation section earlier in this chapter. Finally, if Client Push Installation cannot install the SMS client, a user with administrative credentials must run a client installation method on the computer.
Assigning SMS Clients to an SMS Site

Both the Advanced Client and the Legacy Client can be assigned to an SMS site at installation time. There are additional methods for assigning an Advanced Client to an SMS site, as described in this section. For information about unassigned clients, see Chapter 4, Understanding SMS Clients.
Assigning the Advanced Client

You assign Advanced Clients to a primary site either during client installation or after installation. To assign an Advanced Client to an SMS site, you use one of these methods: u u Configuring the Advanced Client for automatic assignment to an SMS site Assigning the Advanced Client to an SMS site manually
If the SMSCONFIGSOURCE installation property is used, Advanced Clients that are upgraded from SMS 2.0 clients or SMS 2003 Legacy Clients are assigned to the SMS site that is first in the list of assigned sites, as seen in the Systems Management icon in Control Panel on the SMS client.
Caution
Advanced Clients cannot be assigned to secondary sites. If you use the SMSCONFIGSOURCE installation property in this scenario, and you are upgrading SMS 2.0 clients or Legacy Clients that are currently assigned to secondary sites, you risk creating orphaned Advanced Clients clients that are assigned to a site that is not valid. Orphaned clients are not functional. For important information about using SMSCONFIGSOURCE, see the Installation Property section earlier in this chapter.
Automatic Assignment
Advanced Clients can be automatically assigned to an SMS site, but only when the Advanced Client is not currently assigned to a site. This can be done at client installation time or after client installation if the Advanced Client is still dormant. When an Advanced Client is assigned to a site, it maintains that assignment unless an administrator changes the assignment. This section describes two ways to automatically assign the Advanced Client: u u Assigning Advanced Clients to SMS sites by using Client Push Installation Assigning Advanced Clients to SMS sites by using other installation techniques
Assigning SMS Clients to an SMS Site 585
Assigning Advanced Clients to SMS Sites by Using Client Push Installation

You can use the SMSSITECODE installation property on the Advanced tab of the Client Push Installation method to assign the client to an SMS site. Options are: u u Setting the SMSSITECODE installation property to the three-character SMS site code of the site you want to assign the client to. Setting the SMSSITECODE installation property to AUTO. The client is automatically assigned an SMS site during installation, based on the roaming boundary it is in.
The default configuration is SMSSITECODE=AUTO.
Assigning Advanced Clients to SMS Sites by Using Other Installation Techniques

You can use the SMSSITECODE installation property on the Ccmsetup.exe command. Options are: u u Setting the SMSSITECODE installation property to the three-character SMS site code of the site you want to assign the client to. Setting the SMSSITECODE installation property to AUTO. The client is automatically assigned to an SMS site during installation, based on the roaming boundary it is in.
For more information, see the Installation Properties section earlier in this chapter.
Manual Assignment
This section describes two ways to manually assign the Advanced Client: u u Assigning Advanced Clients from Control Panel Assigning Advanced Clients from the command prompt
With manual assignment, even if the Advanced Client does not currently reside within SMS site boundaries, it is still assigned to the site you specify. If the Advanced Client is not set to automatically determine a site, and it is not set to a specific site, it is not assigned to a site and remains dormant, but its installation continues.
Assigning Advanced Clients from Control Panel

To assign the Advanced Client to an SMS site manually after the core client components are installed, you use the Systems Management icon in Control Panel on the client. This requires that you have administrative credentials on the client computer. To assign an Advanced Client to an SMS site, at the Advanced Client computer, double-click the Systems Management icon in Control Panel. On the Advanced tab in the Systems Management Properties dialog box, type in the three-character site code of the SMS site that you want to assign the client to. Or, click Discover to automatically find the local SMS site.
Assigning Advanced Clients from the Command Prompt

You can assign Advanced Clients to SMS sites by running a script at the command prompt. The Advanced Client has a scripting object (Microsoft.SMS.Client) that you can use to do this. This object is installed with the Advanced Client software. For more information, see the Microsoft Systems Management Server 2003 Software Development Kit. The following example demonstrates several of the Advanced Client scripting methods.
Set smsclient = CreateObject("Microsoft.SMS.Client") oldsite = smsclient.GetAssignedSite wscript.echo oldsite smsclient.EnableAutoAssignment(True) 'or: smsclient.SetAssignedSite("NES")
Adjust the script as necessary for your specific requirements.
Removing Advanced Client Assignment

The Advanced Client is unassigned from an SMS site by setting the site code to a null value. You do this by using the Systems Management icon in Control Panel on the client or by using a script. The Advanced Client software is not removed, but it is also not functional. The client is considered dormant. Heartbeat Discovery DDRs, inventory, and status messages are not generated, and advertisements and policies are not downloaded to the client computer.
Assigning the Legacy Client

To assign a Legacy Client to an SMS site, you install the Legacy Client software. Legacy Clients are assigned to an SMS site automatically at installation time.
Legacy Client Assignment

When the Legacy Client installation process starts, the installation component compares the computers IP subnet or assigned Active Directory site to the SMS site boundaries that are recorded on the CAPs. If the computer falls within the SMS site boundaries, it is assigned to the site and the installation continues. If the computer is not assigned to the site, the installation process stops, and the SMS client software is not installed on the computer. If a client computer runs an SMS discovery or installation method and then installs the Legacy Client, it cannot be specifically included or excluded in the assignment process. It is assigned the same way all the computers in that subnet or Active Directory site are assigned.
Assigning SMS Clients to an SMS Site 587
When you install the Legacy Client software, the client is assigned to the first SMS site that is associated with the CAPs that are specified or found during installation. If the client is not in the site boundaries of any SMS site, it is unassigned and its software is removed.
Important
Computers that are running operating systems other than Windows 2000, Windows XP, or operating systems in the Windows Server 2003 family cannot be assigned to Active Directory sites. These computers cannot be assigned to SMS sites based on membership in Active Directory sites. They can only be assigned based on their IP address.
Removing Legacy Client Assignment

Legacy Clients analyze their site assignment every time a client refresh cycle is run. The client refresh cycle runs when the client service restarts, which is once every 25 hours, when the client computer is rebooted, or when Update Configuration is selected on the Sites tab of the System Management icon in Control Panel. Analyzing the site assignment 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. When a Legacy Client moves to another SMS site, its assignment to its original SMS site is automatically removed. The exceptions to this are if the client has travel mode enabled or if the Site4c.exe tool has been used. If the Legacy Client is no longer assigned to any sites, it removes the SMS client software. If an installation method is run on the Legacy Client, the client assigns itself to the site it has moved to.
Note
The Site4c.exe tool forces an SMS 2.0 client or SMS 2003 Legacy Client to use a specified site, overriding the assignment analysis based on the site boundary the client is in. Site4c.exe is included in the SMS 2.0 Support Tools, which is available for download from the Microsoft Web site at http://www.microsoft.com/smserver/downloads.
Upgrading SMS Client Software

This section describes the following: u u Upgrading to the SMS 2003 Client Updating an SMS 2003 Client to a Newer Version
Note
If you want to change a computer from using the Advanced Client to using the Legacy Client, you must remove the Advanced Client software and run a Legacy Client installation method on the computer.
Upgrading to the SMS 2003 Client

This section describes how to upgrade from the SMS 2.0 client or the SMS 2003 Legacy Client to the SMS 2003 Advanced Client, and how to upgrade the SMS 2.0 client to the SMS 2003 Legacy Client. Before upgrading any client computer to the Advanced Client, ensure that its operating system is listed in the supported operating systems in the Getting Started chapter in this book.
Upgrading to the Advanced Client

If you want to change a Legacy Client computer to use the Advanced Client software, you must run an Advanced Client installation method on the computer. You do this by initiating Ccmsetup.exe at Legacy Client computers by using the Client Push Installation method or one of the other methods described in the Installing the Advanced Client section earlier in this chapter. This section describes items that you must be aware of when you are using the Client Push Installation Wizard or a software distribution method when you are upgrading from the SMS 2.0 client or the SMS 2003 Legacy Client to the SMS 2003 Advanced Client.
Note
The Advanced Client software is sometimes considered a replacement for the Legacy Client, not an upgrade. In that case, the terminology used might be replacing the Legacy Client instead of upgrading the Legacy Client.
Upgrading SMS Client Software 589

If you use the Client Push Installation Wizard to upgrade SMS 2.0 clients or SMS 2003 Legacy Clients to Advanced Clients: u u Do not select Include only clients assigned to this site. Do not select Always install (repair or upgrade existing client).
Using a Software Distribution Method

Be aware that when you are using a software distribution method to upgrade to the Advanced Client, by default, the Advanced Client installation is not run until a user is logged on to the client computer. This is necessary to download installation files from the network. Alternatives to this requirement of having a user logged on to the computer to complete the Advanced Client installation are: u u u u Specifying a valid client connection account. Specifying the /service command-line option after Ccmsetup.exe. Specifying the /useronly command-line option after Ccmsetup.exe. Running a dependent program first that downloads Ccmsetup.exe, Client.msi, and any relevant languages-specific files or folders, such as Client.mst, to the client computer. Then, the program calls another program that runs Ccmsetup.exe from the local hard disk. Finally, another program runs later to delete the downloaded files.
Table 17.2 describes the reason to use each of these alternatives and the restrictions that each entails. Table 17.2 Alternatives to Logged-on User Requirement
Alternative /service command-line option Reason to use Use this on computers that are rarely logged on to (such as file servers). Ccmsetup.exe uses the computer account to download Client.msi to the client. Caveats and restrictions Active Directory is required.
(continued)
Table 17.2 Alternatives to Logged-on User Requirement (continued)

Alternative /useronly command-line option Reason to use Use this on computers that are rarely logged on to (such as file servers). Caveats and restrictions Blocks further software distribution advertisements until installation is completed. If the client computer is rebooted or the Advanced Client Installer fails for any other reason, software distribution does not automatically retry the advertisement. First connects to package source shared folder using the SMSCliTokenLocalAcct& account to impersonate a user with Administrative security credentials, risking a potential account lockout. Can cause the software installation account to connect to the package source shared folder, risking a potential account lockout.
Dependent program
The Advanced Client Installer finds Client.msi on a local hard disk and performs the Advanced Client installation immediately without requiring a user to log on.
Installation fails if a dependent program does not run.
Upgrading to the Legacy Client

SMS 2.0 clients update automatically whenever a new patch, service pack, or updated version of the client software is available on any of the CAPs of the site the client is assigned to. Upgrading the SMS site software from SMS 2.0 to SMS 2003 causes SMS 2.0 clients to upgrade to Legacy Clients automatically within 25 hours. This section describes items that you must be aware of when you are using the Client Push Installation Wizard or the Manual Client Installation method (SMSman.exe) when you are upgrading from the SMS 2.0 client to the SMS 2003 Legacy Client.
Upgrading SMS Client Software 591

You can upgrade the SMS 2.0 client to the Legacy Client by using the Client Push Installation Wizard in the SMS 2003 Administrator console. Be sure to select Always install (repair or upgrade existing client) in the wizard when performing this upgrade. For more information about using the wizard, see the Using the Client Push Installation Wizard section earlier in this chapter.
Using Manual Client Installation

If you want to move an SMS 2.0 client to an SMS 2003 site and upgrade the client from an SMS 2.0 client to an SMS 2003 Legacy Client at the same time, use Manual Client Installation (SMSman.exe) with the /F switch. For more information, see the Installing the Legacy Client section earlier in this chapter.
Updating an SMS 2003 Client to a Newer Version

This section describes how to update an existing SMS 2003 Advanced Client or Legacy Client to a newer version of the client software.
Updating the Advanced Client

Advanced Clients are updated by using the same methods that are used to install them. Unlike Legacy Clients, Advanced Clients do not automatically update when a newer version of the Advanced Client software is available at the SMS site. The SMS administrator is responsible for ensuring that Advanced Clients are running the latest version. For information about updating to a newer version of the Advanced Client, see the documentation provided with the service pack or other SMS software updates from Microsoft. To update an Advanced Client, you must run an Advanced Client installation method on it. When clients are upgraded, they retain their site assignment and their inventory and software distribution histories. If you use software distribution to update the Advanced Client software, be aware that the Advanced Client installation is not run until a user is logged on to the client computer. The alternative to this requirement of having a user logged on to the computer to complete the Advanced Client installation is to configure the software package to download the program from the distribution point before running it. To do this, specify the Download option on the Advanced Client tab of the Advertisement Properties. Select one of the two download first options when advertising the package to Legacy Clients: u u Download program from distribution point Download program from a remote distribution point
If you do not choose one of these two download options, the Advanced Client installation is not performed on the client computer until a user logs on.
The other alternative is to use Client Push Installation to perform the update. The Client Push Installation method automatically supplies the appropriate user credentials necessary to complete the installation.
Updating the Legacy Client

Like SMS 2.0 clients, Legacy Clients update automatically whenever a new patch, service pack, or updated version of the client software is available on any of the CAPs of the site the client is assigned to. Updating the SMS site software causes Legacy Clients to update automatically. If you do not want to automatically upgrade of all your Legacy Clients at one time, disable this automatic update of clients by using the Client Upgrade Control tool (CliUpgrade.exe) that is included on the SMS 2003 CD.
Note
You can use the Client Upgrade Control tool on many clients at the same time by sending it as an SMS advertisement. You can also distribute it through logon scripts, e-mail messages, or other techniques suitable for distributing small software programs.
SMS 2003 Legacy Clients update in much the same way that they update their configuration details. When a Client Configuration and Installation Manager (CCIM) client cycle runs, the Legacy Client also checks for the availability of updated client components. If new versions of the SMS client components are available, the client installs them. The client update behavior of SMS is the same for all product updates, including service packs and other updates.
Removing and Repairing SMS Client Software

Removing the SMS client software from computers might be necessary in rare circumstances, such as when you have completed the pilot project and you want to start your production deployment without SMS installed on any computers. Both clients lose inventory history and any custom Management Information Format (MIF) files when the client software is removed.
Removing the Advanced Client

The SMS Advanced Client software is not automatically removed under any circumstances. Only a user with administrative credentials on the computer can remove the Advanced Client software. Remove the Advanced Client software by using the Ccmclean.exe tool. This tool is available for download on the Microsoft Web site at http://www.microsoft.com/smserver/downloads.
Ccmclean.exe
Removing and Repairing SMS Client Software 593
If the client is installed on a management point, use the following syntax to prevent Ccmclean.exe from removing the management point:
Ccmclean.exe client
Removing the Legacy Client

As described in Chapter 4, Understanding SMS Clients, the Legacy Client software can be removed from client computers in a site by removing the SMS site boundaries from the site configuration. You can also use other methods to remove Legacy Clients, as described in this section.
Important
Removing the SMS client software from computers does not remove the clients from the SMS site database. Clients that are not updated are automatically purged from the SMS site database after a period of time, usually 30 days. If you want to remove these clients immediately from the SMS site database, use the SMS Administrator console to delete them.
When the Legacy Client is removed, the client loses the history of advertisements it ran. If the client is reinstalled later, it might re-run advertisements that were already run on the client.
Automatic Removal
The Legacy Client analyzes its site assignment every time the client refresh cycle runs (every 25 hours). The SMS Legacy Client software is automatically removed when it is no longer assigned to an SMS site. To remove the SMS client at the client refresh cycle, the client must be able to contact a CAP in its assigned site. If the client finds that it is no longer in the site boundaries, the client software is automatically removed. If a Legacy Client cannot contact a CAP for its assigned site for 60 days, then the client software is automatically removed. An efficient way to automatically remove all Legacy Clients in an SMS site is to remove the SMS site boundaries by using the SMS Administrator console. If you remove the site boundaries from the site configuration, allow enough time for the Legacy Clients to run their client refresh cycles. One and a half days is sufficient, but if some computers are turned off or are away from the SMS site, allow extra time for them to complete the cycle. This method does not work for Legacy Clients that have travel mode enabled.
Manual Removal
You can use the following command to display the Systems Management Installation Wizard. You select the Remove systems management components option, the SMS client component services are stopped, and their files and directories are deleted. You must have administrative credentials on the computer to do this.
SMSman.exe
You can use the following command to remove all SMS client components. This aggressive option, which uses the /U switch, is appropriate when the client is not fully functional and might not be able to perform an orderly removal. The SMS client component services are stopped, and their files and directories are deleted.
SMSman.exe /U
You are prompted to confirm that you want to delete the SMS client. If you do not want that prompt, also include the /Q switch to specify quiet mode.
SMSman.exe /U /Q
The following command is the same as using SMSman.exe without any switches and selecting Remove systems management components option, except that the Systems Management Installation Wizard is not displayed.
20clicln.bat /U
Note
20clicln.bat is included in the SMS 2.0 Support Tools, which is available for download from the Microsoft Web site at http://www.microsoft.com/smserver/downloads.
The following command is the same as 20clicln.bat, except that it also deletes %Windir%\SMScfg.ini. The next time the SMS client software is installed, the client is given a new GUID.
20clicln.bat /scrub
Setting the following registry value to TRUE causes an automatic removal: HKLM\SOFTWARE\Microsoft\SMS\Client\Configuration\Client Properties\SMS Client Deinstall
Repairing SMS Clients

Reinstalling SMS clients can be useful when: u u Clients have outdated or incorrect security information. For example, the account or password for the SMS Client Connection account is incorrect. Clients are not behaving correctly, and you suspect the problem is related to missing or corrupted SMS software components on the clients.
Reinstalling clients to repair them does not require removing the core SMS client components first.
A P P E N D I C E S
Appendices
This part of the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide describes the features, products, and services that make Systems Management Server 2003 accessible to people with disabilities.
A P P E N D I X
Accessibility for People with Disabilities

Microsoft is committed to making its products and services easier for everyone to use. This appendix provides information about the following features, products, and services that make Microsoft Systems Management Server (SMS) 2003 more accessible for people with disabilities: u u u u u u u SMS 2003 Accessibility Features and Options Accessibility in Microsoft Windows Adjusting Microsoft Products for People with Accessibility Needs Assistive Technology Products for Windows Microsoft Documentation in Alternative Formats Customer Service for People Who Are Deaf or Hard-of-Hearing Getting More Accessibility Information
For accessibility information in languages other than English, see http://www.microsoft.com/enable/worldwide.htm.
598 Appendix A Accessibility for People with Disabilities
SMS 2003 Accessibility Features and Options

In addition to the Windows accessibility features and utilities described in the next section, the following features make SMS 2003 more accessible for people with disabilities: u u u u u SMS Help Keyboard Shortcuts MMC Navigation Keyboard Shortcuts MMC Navigation Mouse Shortcuts MMC Main Window Keyboard Shortcuts MMC Console Window Keyboard Shortcuts
For more information about SMS 2003 accessibility features and options, see SMS 2003 Help.
SMS Help Keyboard Shortcuts

The following table lists access keys for the SMS Help Viewer. Table A.1 SMS Help Viewer Access Keyboard Shortcuts
Action ALT+O ALT+O+T ALT+O+B ALT+O+F ALT+O+P Result Displays and hides the Options menu. Hides and displays the Navigation pane. Goes to the previous topic. Goes to the next topic. Displays the Print dialog box.
MMC Navigation Keyboard Shortcuts

Working with the Microsoft Management Console (MMC) console tree is very similar to working with folders in Windows Explorer. You navigate from item to item, expanding and collapsing branches as needed by using the + and keys on the keyboard or by clicking and double-clicking. The following table lists the actions you can use to navigate in and between console windows.
SMS 2003 Accessibility Features and Options 599
Table A.2 MMC Console Tree Keyboard Shortcuts

Action TAB or F6 SHIFT+TAB or SHIFT+F6 NUM + NUM NUM * UP ARROW DOWN ARROW PAGE UP PAGE DOWN HOME END RIGHT ARROW LEFT ARROW Result Moves forward between panes in the active console window. Moves backward between panes. Expands the selected item. Collapses the selected item. Expands the entire console tree below the root item in the active console window. Moves the focus up one item in a pane. Moves the focus down one item in a pane. Moves the focus to the top item visible in a pane. Moves the focus to the bottom item visible in a pane. Moves the focus to the root of the console tree. Moves the focus to the last item in the console tree. Expands the selected item. Collapses the selected item. If the selected item does not contain exposed items, LEFT ARROW moves the focus to the top of the current branch of the console tree.
MMC Navigation Mouse Shortcuts

The following table lists the mouse actions that you can use to navigate the MMC console tree. Table A.3 MMC Console Tree Mouse Shortcuts
Action Click Double-click Right-click Selects an item. Displays or hides items contained by the selected item. Displays properties for or opens an item. Displays the Action shortcut menu for the selected item. Results
MMC Main Window Keyboard Shortcuts

This table lists keyboard shortcuts for the commands that you can use to perform tasks for a console or for the main window of a console.
Table A.4 MMC Main Window Keyboard Shortcuts

Action CTRL+O CTRL+N CTRL+S CTRL+M CTRL+W F5 ALT+SPACEBAR ALT+F4 Opens a saved console. Opens a new console. Saves the open console. Adds or removes a snap-in. Opens a new window. Refreshes the selected node. Displays the MMC menu. Closes the active console. Result
MMC Console Window Keyboard Shortcuts

This table lists keyboard shortcuts for the commands that you can use in the active console window of a console or on the contents of a console window. Table A.5 MMC Console Window Keyboard Shortcuts
Action CTRL+P ALT+ Prints the current page or active pane. Displays the window menu for the active console window. Result
SHIFT+F10 or Displays the Action shortcut menu for the selected item. ALT+A ALT+V F1 F5 CTRL+F10 CTRL+F5 ENTER Displays the View menu for the active console window. Opens the Help topic (if any) for the selected item. Refreshes the content of all console windows. Maximizes the active console window. Restores the active console window. Opens or displays the Properties dialog box for the selected item.
Accessibility in Microsoft Windows 601
SMS Administrator Console Keyboard Shortcuts

Table A.6 SMS Administrator Console Keyboard Shortcuts
Action Result You can use the APPLICATION key ( ) on your keyboard to display action menus in property pages. CTRL + SHIFT +arrow key or ALT +M In the Rate Limits property page of the Standard Sender Address Properties dialog box, use CTRL + SHIFT and left or right arrow keys to select blocks of time, then tab to the control for setting time. Use ALT+M to select the Limit % of connection bandwidth control. In the Schedule property page of Standard Sender Address Properties dialog box, use CTRL + SHIFT and a left or right arrow key to select blocks of time, then tab to the control to set Availability. You can also use ALT + V to set the Availability drop down menu, or ALT + U to select the check box control for Unavailable to substitute for inoperative addresses.
CTRL + SHIFT +arrow key or ALT +V or ALT + U
Accessibility in Microsoft Windows

When Microsoft Windows platforms are SMS clients, the Windows accessibility features help disabled administrators, disabled users, and others who may have limited access to mouse devices. Many accessibility features have been built into the Microsoft Windows operating system, starting with the introduction of Microsoft Windows 95. These features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or are deaf or hard-of-hearing. The features can be installed during setup. The following sections provide more information about the various accessibility features of Microsoft Windows XP, Windows 2000, Windows Millennium Edition, Windows 98, Windows NT 4.0, and Windows 95.
Windows XP Professional and Home

Accessibility enhancements and improvements in Microsoft Windows XP provide better integration with assistive technology products and richer communications. Accessibility improvements and other Windows XP Professional features make it easier for people with accessibility needs to work more efficiently. For more information about accessibility enhancements and features in Windows XP, see http://www.microsoft.com/windowsxp/accessibility/.
Windows 2000
Windows 2000 includes several accessibility tools to help people with disabilities configure and use business computers quickly. Accessibility features from earlier versions of the Windows operating system are still included, and with the increased integration of Microsoft Active Accessibility, many assistive technology products work better. For more information about accessibility in Windows 2000, see http://www.microsoft.com/enable/products/.
Windows 98
For more information about accessibility in Windows 98, see http://www.microsoft.com/enable/products/.
Windows 95 and Windows NT Workstation 4.0

Windows 95 and Windows NT Workstation 4.0 have several built-in accessibility features to help people with disabilities use computers more easily and effectively. For more information about accessibility in these operating systems, see http://www.microsoft.com/enable/products/.
Adjusting Microsoft Products for People with Accessibility Needs

Accessibility options and features are built into many Microsoft products. Accessibility options and features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or are deaf or hard-of-hearing.
Free Step-by-Step Tutorials

Microsoft offers a series of step-by-step tutorials to help you learn how to adjust the accessibility options and settings on your computer. The tutorials provide detailed information about how to adjust options, features, and settings to meet accessibility needs. This information is presented in a side-by-side format so that you can see at a glance how to use the mouse, the keyboard, or a combination of both. See http://www.microsoft.com/enable/training/ to find step-by-step tutorials for the following products: u u Windows XP Windows 2000
Assistive Technology Products for Windows 603
u u u u
Windows Millennium Edition Windows 98 Microsoft Internet Explorer 6.0 Microsoft Internet Explorer 5.0
Assistive Technology Products for Windows

A variety of assistive technology products are available to make computers easier to use for people with disabilities. Microsoft provides a searchable catalog of assistive technology products that run on Microsoft Windows operating systems at http://www.microsoft.com/enable/at/. Products available for the MS-DOS, Windows, and Windows NT operating systems are: u u u u u u Programs that enlarge or alter the color of information on the screen for people with visual impairments. Programs that describe information on the screen in Braille or that provide synthesized speech for people who are blind or have difficulty reading. Hardware and software utilities that modify the functions of the mouse and keyboard. Programs that enable people to type by using a mouse or their voice. Word or phrase prediction software that allows people to type more quickly and with fewer keystrokes. Alternative input devices, such as single switch or puff-and-sip devices, for people who cannot use a mouse or a keyboard.
Upgrading
If you use an assistive technology product, contact your assistive technology vendor to check compatibility with products on your computer before upgrading. Your assistive technology vendor can also help you learn how to adjust your settings to optimize compatibility with your Microsoft products.
Microsoft Documentation in Alternative Formats

Obtaining Documentation for SMS 2003
Microsoft product documentation is available in print, online, and electronic formats. You can access the official SMS 2003 product page at http://www.microsoft.com/smserver/default.asp. 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. To access product documentation and other technical resources, see the Online Library, which is available from the SMS Program Group or SMS Administrator console. For more information, see the Getting Started chapter in this book.
Obtaining Documentation for Additional Microsoft Products

Microsoft Web site You can obtain accessible documentation for Microsoft products from the Microsoft Accessibility Web site at http://www.microsoft.com/enable/products/docs/. Recording for the Blind & Dyslexic, Inc. You can obtain additional Microsoft publications from Recording for the Blind & Dyslexic, Inc. These documents are distributed to registered, eligible members of the distribution service on audiocassettes or floppy disks. The collection contains more than 80,000 titles, including Microsoft product documentation and books from Microsoft Press. For information about eligibility and availability of Microsoft product documentation and books from Microsoft Press, contact: Recording for the Blind & Dyslexic, Inc. 20 Roszel Road Princeton, NJ 08540 Phone from within the United States: (800) 221-4792 Phone from outside the United States and Canada: (609) 452-0606 Fax: (609) 987-8116 Web: http://www.rfbd.org/
Customer Service for People Who Are Deaf or Hard-of-Hearing 605
Customer Service for People Who Are Deaf or Hard-of-Hearing

If you are deaf or hard-of-hearing, complete access to Microsoft product and customer services is available through a text telephone (TTY/TDD) service.
Customer Service
You can contact the Microsoft Sales Information Center on a text telephone by dialing (800) 8925234 between 6:30 A.M. and 5:30 P.M. Pacific Time, Monday through Friday, excluding holidays.
Technical Assistance
For technical assistance in the United States, you can contact Microsoft Product Support Services on a text telephone at (800) 892-5234 between 6:00 A.M. and 6:00 P.M. Pacific Time, Monday through Friday, excluding holidays. In Canada, dial (905) 568-9641 between 8:00 A.M. and 8:00 P.M. Eastern Standard Time, Monday through Friday, excluding holidays. Microsoft support services are subject to the prices, terms, and conditions in place at the time the service is used.
Getting More Accessibility Information

The Microsoft Accessibility Web site at www.microsoft.com/enable/ provides information about assistive technology. The information in this site benefits people with disabilities, their friends and family members, people in outreach organizations, educators, and advocates. A free monthly electronic newsletter is available to help you keep up to date with accessibility topics about Microsoft products. To subscribe, see http://www.microsoft.com/enable/news/subscribe/default.asp.
Glossary
A
access To connect to a resource, either remotely (such as to a file share or the named pipe for a service) or locally (such as to a file, directory, WMI class, WMI instance, or database). See also Windows Management Instrumentation (WMI). access account A user or user group account that is given access to a package on a distribution point. Access accounts are used for security to specify which users or user groups will be permitted to access the package to run advertised programs. See also advertised program; distribution point; package. access control entry (ACE) An entry in an objects discretionary access control list (DACL) that grants permissions to a user or group. An ACE is also an entry in an objects system access control list (SACL) that specifies the security events to be audited for a user or group. See also access control list (ACL); security descriptor. access control list (ACL) A list of security protections that apply to an entire object, a set of the objects properties, or an individual property of an object. There are two types of access control lists: discretionary and system. See also access control entry (ACE); security descriptor. account A security element that verifies the identity of a user or computer. An account has an associated name and password as well as group memberships, privileges, and constraints. See also privilege. account expiration A time limit that is applied to the life of an account, so that it can be used only for a predetermined period of time. See also account. account management The process of minimizing security risks to accounts by ensuring that strong passwords are used and that unused accounts are removed. Account management also includes adding, modifying, and deleting accounts; changing rights; and resetting passwords. See also account; strong password. ACE See definition for access control entry (ACE). ACL See definition for access control list (ACL). Active Directory The Windows-based directory service. Active Directory stores information about objects on a network and makes this information available to users and network administrators. Active Directory gives network users access to permitted resources anywhere on the network using a single logon process. It provides network administrators with an intuitive, hierarchical view of the network and a single point of administration for all network objects. address An object that connects sites to other sites and specifies how SMS should use those connections. See also SMS site. Advanced Client An SMS 2003 client that is secure and easy to administer. The Advanced Client is optimized for software distribution to mobile and remote computers. See also SMS Administrator console; Legacy Client. Advanced Client policy Configuration details for the Advanced Client that are provided after client installation. See also Advanced Client; management point. Advanced Program-to-Program Communication (APPC) An IBM Systems Network Architecture communications method that uses the LU 6.2 protocol to establish, manage, and terminate network communication between programs in a distributed computing environment. advertise The process of making a program available to members of a collection. See also advertised program; assigned program. advertised program A program that has been advertised to a collection, but that clients are not required to run. See also advertise; assigned program. advertisement A notification that the site server sends to the client access points (CAPs) specifying that a software distribution program is available for clients. See also advertise; client access point (CAP); collection; package; site server; software distribution. agent See definition for client agent. alert An audible or visual alarm that signals an error or serves as a warning.
608 Glossary
aliasing In software metering, a process that enables a program to run and be monitored as another program that is already a registered product. See also software metering. APPC See definition for Advanced Program-toProgram Communication (APPC). architecture A structure that records information about an object. There are different architectures for different objects. Each object is composed of groups that contain attributes. An example of an architecture is the Systems architecture. assigned management point The default management point of the site to which the Advanced Client is assigned, as defined in the management point properties. Also known as a home management point. See also Advanced Client; management point; proxy management point; resident management point. assigned program A program that has been advertised to a collection and is mandatory to run. See also advertise; advertised program; assigning; collection. assigned site A site to which the client computer is currently assigned. This is typically one site, but an SMS client can be assigned to multiple sites. See also SMS site. assigning In Windows 2000, Windows XP, the Windows Server 2003 family, and Systems Management Server (SMS), to deploy a program to members of a group, where installation of the program is mandatory. See also advertise; advertised program; assigned program; collection. assignment See definition for site assignment. asynchronous RAS sender See definition for sender. attribute A name or value that is used to query the SMS site database. Also known as a property. For example, the Disk attribute class contains attributes such as Manufacturer, Model, and Name. See also attribute class; SMS site database. attribute class A container object that groups related attributes within an object type. See also attribute. authentication The process by which the system verifies that an account is being accessed by an authorized user, computer, service, or process. A users name and password are compared against an authorized list. If the system detects a match, access is granted to the extent specified in the
permissions list for that user. See also password; permission.
B
backup domain controller (BDC) A domain controller running Windows NT Server 4.0 or earlier that receives a read-only copy of the directory database for the domain. The directory database contains all account and security policy information for the domain. See also Active Directory; primary domain controller (PDC). backup snapshot A snapshot of a sites data, created by the Backup SMS Site Server task or by another backup utility. The backup snapshot is used during a site recovery process to restore the sites data. BDC See definition for backup domain controller (BDC). binary MIF See definition for Management Information Format (MIF) file. broadcast A transmission that is sent to all stations on a network. buffer A region of random access memory (RAM) reserved for use with data that is temporarily held while waiting to be transferred between two locations, such as between an applications data area and an input/output device.
C
CAP See definition for client access point (CAP). capture In Network Monitor, the process of reviewing all frames as they are received from the network, selecting particular frames to record, and storing the selected frames in a buffer. See also buffer. capture file In Network Monitor, a file containing captured data. After a capture process is stopped, the data can be saved to a capture file using the .cap file name extension. See also capture filter; captured data; Network Monitor. capture filter The mechanism that reads frames and compares the data to a defined set of criteria. Frames that meet the criteria are copied to a temporary capture file; those that do not meet the criteria are not copied to the temporary capture file. See also capture file; captured data.
Glossary 609
captured data In Network Monitor, frames that meet a defined set of criteria and that have been copied to a temporary capture file. See also capture file; Network Monitor. central site The primary site at the top of the SMS hierarchy. All other sites in the SMS system report (either directly or indirectly) their inventory, site configurations, software metering data, and status to the central site. See also primary site; secondary site; SMS hierarchy; software metering. child site A site that has a parent site. In an SMS hierarchy, every site (except the central site) is the child of another site. A site can be both a parent site and a child site. See also central site; parent site; primary site; secondary site; SMS hierarchy. CIM Object Manager The primary component in the management infrastructure of the Web-based Enterprise Management (WBEM) technology. See also CIM repository; Web-based Enterprise Management (WBEM); Windows Management Instrumentation (WMI). CIM repository A central storage area that is managed by the CIM Object Manager. See also CIM Object Manager. CIMOM See definition for CIM Object Manager. client A computer that has SMS client software installed and belongs to an SMS site. See also SMS site. client access point (CAP) A site system that has the CAP role provides a communication point between the site server and Legacy Client computers. Computers contact CAPs to install and update SMS Legacy Client software. After SMS Legacy Client software has been installed on computers in a site, they contact a CAP for updated information from the SMS site server. Clients deliver collected files, inventory information, discovery data records, software metering data, and status information to CAPs. See also collected files; site server; site system; site system role; Legacy Client. client agent Software that runs on SMS clients to perform specific functions. For example, the Software Metering Client Agent reports the applications that ran on a client to the site. See also Advanced Client; Legacy Client. client assignment See definition for site assignment.
client components SMS threads, services, and applications that run on client computers and provide SMS functionality. client installation The process of installing SMS client software on discovered computers within a site. client installation methods Procedures that are used to install SMS client software on discovered computers within a site. See also client installation. collected files Files that are copied from SMS clients during a software inventory. After the files are collected from clients, they are stored on the site server. See also file collection; site server; software inventory. collection A set of resources in a site. The set is defined by membership rules. Collections are used to distribute software, view the inventories of clients, and access clients for remote control sessions. An example of a collection is All Windows NT Workstation 4.0 Systems. See also membership rule; subcollection. collection limiting A method of restricting the scope of a query or a collection membership rule. A query that is collection limited can only return resources that are in a specified collection, even if other resources in the SMS site database match the query criteria. See also collection; membership rule; SMS site database. Common Information Model Object Manager See definition for CIM Object Manager. community An administrative security relationship between Simple Network Management Protocol (SNMP) entities. For SNMP transactions, it is always necessary to specify the community name. complete inventory A hardware or software inventory cycle that creates a complete inventory file containing all the hardware attributes or inventoried software types found on a client and that are set to be reported. See also delta inventory; hardware inventory; resynchronization; SMS site database; software inventory. compliance level The category types that indicate the compliance level of a software product. See also compliance type.
610 Glossary
compliance type A list of items that differentiates one type of product compliance from another. Y2K and Euro compliance are both compliance types. See also compliance level. component server A site system role that is filled by any SMS site system running an SMS component installed by SMS Site Component Manager. The only site system that is not a component server is the distribution point. See also distribution point; site server; site system; site system role. console tree An ordered, hierarchical listing of objects. The items in the console tree and their hierarchical order determine the management capabilities of that console. See also SMS Administrator console. container object An object that can logically contain other objects. For example, a folder is a container object. See also Active Directory. Courier Sender See definition for sender. credentials A set of information that includes identification and proof of identification that is used to gain access to local and network resources. Examples of credentials are user names and passwords, smart cards, and certificates. See also password.
D
dashboard A set of reports that are arranged in a grid and displayed in a single window of Report Viewer. See also Report Viewer. data summarization In software metering, the process of condensing software usage data from the multiple, detailed records of each monitored program to one general record. See also software metering. database See definition for SMS site database. database server A computer that is running SQL Server and is being used by SMS. DDR See definition for discovery data record (DDR). delta inventory A hardware or software inventory cycle that creates a delta inventory file containing all the information that was added, removed, or changed since the previous inventory. The delta inventory file is smaller than the complete inventory file. See also complete inventory; hardware inventory; software inventory.
delta MIF See definition for Management Information Format (MIF) file. dependent program A program that requires that another program run first. destination address The address of the computer to which data is sent. details pane The pane that displays the results of selecting an item in the SMS Administrator console. The results that are displayed depend on the item that is selected. See also SMS Administrator console. DHCP See definition for Dynamic Host Configuration Protocol (DHCP). discovery data Information that identifies a resource. For example, discovery data for an SMS client can include the IP address of the network connection, the operating system type and version, and the SMS unique identifier that is assigned to the client. See also discovery data record (DDR); IP address; resource discovery; SMS site database. discovery data record (DDR) The file format and the actual file that reports discovery data to an SMS site database. See also discovery data; resource discovery; SMS site database. discovery method A procedure that detects and acquires information about resources on the network. See also discovery data record (DDR); SMS site database. display filter In Network Monitor, the feature that hides or displays categories of information in the Frame Viewer window. See also Frame Viewer window; Network Monitor. display name In a software inventory, a company or product name that you want to use instead of the actual names that are read from the header information of files on clients. See also inventoried name; Resource Explorer; SMS site database; software inventory. distribution point A site system that has the distribution point role and stores package source files. Clients contact distribution points to obtain source files when they run programs that are advertised to them through a client access point or a management point. See also client access point (CAP); management point; site system. distribution point group A set of distribution points that you can manage as a single entity. A distribution point group simplifies management tasks when a site includes too many distribution points to manage individually. See also distribution point.
Glossary 611
domain synchronization The process of replicating the domain database from the primary domain controller to one or all backup domain controllers in a domain. See also backup domain controller (BDC); primary domain controller (PDC). Dynamic Host Configuration Protocol (DHCP) An industry standard method for simplified and dynamic configuration of IP addresses for computers on TCP/IP networks. See also IP address.
E
expert In Network Monitor, an analytical tool that parses a capture file and identifies problem areas on the network. For example, the Average Server Response Time expert generates a report on the average response time of servers on a segment. See also capture file; Network Monitor. explicit permissions SMS security rights that are assigned to a user. See also explicit security right; implicit permissions; security rights. explicit security right An SMS security right that is assigned to an individual user, not a user group. See also explicit permissions; implicit security right; security rights.
from the change log before replication in a partial domain synchronization takes place, and when a new BDC is added to a domain. See also backup domain controller (BDC); domain synchronization; partial domain synchronization; Security Accounts Manager (SAM). global roaming Roaming to lower level sites, higher level sites, and sibling sites. This roaming method requires Active Directory and the SMS Active Directory schema extensions and only applies to the Advanced Client. See also Active Directory; Advanced Client; higher level site; lower level site; regional roaming; sibling sites.
H
hardware history A hardware inventory that was collected in the past. See also hardware inventory. hardware inventory The automated process that SMS uses to gather detailed information about the hardware in use on client computers in your organization. See also hardware history. Hex pane The pane in the Network Monitor Frame Viewer window that shows the hexadecimal bytes that are transmitted in the frames that are included in the capture. See also Frame Viewer window; Network Monitor. hierarchy See definition for SMS hierarchy. hierarchy branch A group of interconnected SMS sites that report up to the same primary site. Sibling sites are not part of the same hierarchy branch. See also primary site; SMS site. higher level site Any parent or indirect parent of the current site. See also child site; lower level site; parent site.
F-G
file collection The process of copying specific files from SMS clients during a software inventory. SMS saves the collected files on the site server. See also collected files; site server; SMS Administrator console; software inventory. file system security File, directory, or auditing security that allows security control through file attributes. filter In Network Monitor, user-specified restrictions on captured or displayed data. See also capture filter; captured data; display filter; Network Monitor. Frame Viewer window The Network Monitor window that displays detailed information about individual frames that have been saved to a capture file. See also capture file; capture filter; captured data; Network Monitor. full domain synchronization The copying of the entire Security Accounts Manager (SAM) database to a backup domain controller (BDC). Full domain synchronization is performed automatically when changes have been deleted
I-K
IDMIF A custom Management Information Format file that creates new architectures or updates existing architectures in the SMS site database. See also Management Information Format (MIF) file; NOIDMIF. implicit permissions SMS security rights that are assigned to a user group. See also implicit security right; permission; security rights. implicit security right An SMS security right that is assigned to a user group, not an individual user. See also explicit security right; implicit permissions; security rights.
612 Glossary
interactive session The time during which a user is logged on. inventoried name In a software inventory, the name of a company or product as it appears in the header information of files on clients. See also display name; software inventory. Inventory Agent A client agent that scans a client for a hardware or software inventory and reports the inventory to the SMS site database. See also hardware inventory; SMS site database; software inventory. IP address For Internet Protocol version 4 (IPv4), a 32-bit address used to identify an interface on a node on an IPv4 internetwork. Each interface on the IP internetwork must be assigned a unique IPv4 address, which is made up of the network ID, plus a unique host ID. This address is typically represented with the decimal value of each octet separated by a period (for example, 192.168.7.27). You can configure the IP address statically or dynamically by using Dynamic Host Configuration Protocol (DHCP). For Internet Protocol version 6 (IPv6), an identifier that is assigned at the IPv6 layer to an interface or set of interfaces and that can be used as the source or destination of IPv6 packets. See also Dynamic Host Configuration Protocol (DHCP).
L
Legacy Client An SMS 2003 client that is similar to the SMS 2.0 client. The Legacy Client is supported on Windows operating systems that were released prior to the Windows 2000 family of operating systems. See also Advanced Client; SMS Administrator console. load signature The set of performance metrics of installed SMS components on a specific computer hardware configuration. local address The network address of the computer that runs Network Monitor. See also Network Monitor. local roaming boundary A roaming boundary in which the site distribution points are local (that is, is well-connected) to the Advanced Client and software packages are available locally to that client. See also Advanced Client; distribution point; remote roaming boundary; wellconnected. local user account A user account on a specific computer. A local user account is available only
on the computer where the local account is defined. locked-down client A computer that is highly secured so that most users and processes cannot change characteristics of the computer, applications, or files on the computer. Clients are often locked down to enforce standards and to prevent damage due to malicious processes or user error. logical operator In a query, a connector between two expressions, two subclauses, or a combination of an expression and a subclause. There are three primary logical operators: AND, OR, and NOT. logon discovery A resource discovery method that detects computers when users log on to an SMS-enabled domain. Logon discovery is an SMS 2.0 feature, not an SMS 2003 feature. See also resource discovery. logon installation A client installation method that begins when a user logs on to a domain configured for SMS logon installation. Logon installation is an SMS 2.0 feature, not an SMS 2003 feature. See also client installation. logon point A site system role that hosts the logon discovery and logon installation methods. Logon point is an SMS 2.0 site system role, not an SMS 2003 site system role. See also logon discovery; logon installation; resource discovery; site system; site system role. lower level site Any child or indirect child of the current site. See also child site; higher level site; parent site.
M
Managed Object Format (MOF) A language, based on the Interface Definition Language (IDL), that describes management information. The MOF syntax is a way to describe object definitions in textual form. See also CIM repository; Managed Object Format (MOF) file. Managed Object Format (MOF) file A text file that contains computer management information in a standard format that can be loaded into the CIM repository. See also CIM repository; Managed Object Format (MOF). Management Information Format (MIF) A standard designed by the Distributed Management Task Force for computer management data. See also Management Information Format (MIF) file.
Glossary 613
Management Information Format (MIF) file A file used by SMS to extend SMS inventory collection and to provide detailed software distribution status. See also hardware inventory; Management Information Format (MIF); software distribution; software inventory. management point The SMS site system role that serves as the primary point of contact between Advanced Clients and the SMS site server. See also Advanced Client; site server; site system role. media access control (MAC) address A hardware address that uniquely identifies each node of a network. See also address. membership rule The criteria by which SMS evaluates whether a resource belongs to a particular collection. A membership rule can be a query or it can explicitly specify a resource. See also collection; resource. Microsoft Management Console (MMC) A framework used to host management tools. Management tools that are hosted in MMC are known as snap-ins. See also details pane; SMS Administrator console; snap-in. MIF See definition for Management Information Format (MIF). MIF file See definition for Management Information Format (MIF) file. MMC See definition for Microsoft Management Console (MMC). MOF See definition for Managed Object Format (MOF). MOF file See definition for Managed Object Format (MOF) file.
Network Monitor A packet capture and analysis tool used to view network traffic. See also capture; capture file; Frame Viewer window. Network Trace An SMS Administrator console tool that calculates and diagrams routes between an SMS site server and any site system role that you select, based on the discovery data in the SMS site database. See also discovery data; site server; SMS Administrator console. NOIDMIF A custom Management Information Format (MIF) file that SMS administrators can create and then use to extend the hardware inventory data gathered from client computers. See also hardware inventory; IDMIF; Management Information Format (MIF) file.
O
object type A set of attributes that represents an SMS site database object, such as a client, a package, an advertisement, or a user group. All objects of a specific type are labeled and grouped together. See also advertisement; client; package. orphaned client A client that cannot communicate with its assigned site. See also client.
P
package An object that contains the files and instructions for distributing software to a distribution point and executing the package on SMS clients targeted by advertisements. See also advertisement; client; distribution point; package distribution. package access list The list of users or groups that can access an SMS package on its distribution points. See also distribution point; package. package definition file An ASCII text file that contains predefined programs and property settings for a package. You can create a new package by importing a package definition file. SMS includes package definition files for a number of software applications and operating systems. See also package.
N
namespace A unit for grouping WBEM classes and instances to control their scope and visibility. In SMS, namespace usually refers to the specific WBEM namespace: \SMS\Site_<sitecode>. This namespace is the location that exposes the classes and functionality of the SMS Provider. See also SMS Provider; Web-based Enterprise Management (WBEM); Windows Management Instrumentation (WMI). Network Discovery A method that uses ARP, DHCP, OSPF, RIP, WINS, DNS, NetBIOS, and SNMP to discover the network topology and all systems and devices attached to the network. See also discovery data; resource discovery.
614 Glossary
package distribution The process of placing a decompressed package image on distribution points, sharing that image, and making it accessible to clients. This process occurs automatically when you specify distribution points for a package. See also distribution point; package. package routing The distribution process in which a site can route a package to its destination even if it has no direct address. The routing site is able to determine the most appropriate path for the package to reach its destination. See also package. package source directory A directory containing package source files that are used for package distribution. See also package; package distribution. package source files The files that are contained within an SMS package and that each advertised program needs in order to run. Each program within the package uses one or more of these source files, if they do not already exist on the target client. For example, the Setup program might need installation files and libraries to operate properly when run. See also advertised program; package; software distribution. parcel Any set of files that is transferred from one site to another with Courier Sender. Parcels are created in Courier Sender Manager. See also sender. parent site An SMS site that has one or more child sites. See also child site. parser In Network Monitor, a program that separates protocol information into smaller pieces so that Network Monitor can act on the information. Each parser can parse one protocol or family of protocols for analysis in Network Monitor. See also Network Monitor. partial domain synchronization The automatic, timed delivery to all domain backup domain controllers of only those SAM database changes that have occurred after the last synchronization. Partial domain synchronizations can also be invoked by a domain administrator. See also domain synchronization; full domain synchronization. password A security measure used to restrict logon names to user accounts and access to computer systems and resources. A password is a string of characters that must be provided before a logon name or an access is authorized. A password can be made up of letters, numbers, and symbols, and it is case-sensitive. See also
password restrictions; password strength; password uniqueness. password age The number of days a password is allowed to be used before it must be changed. See also password; password expiration. password expiration The event that occurs when a password reaches its password age. At this point, the password must be reset before the account can be used. See also password; password age. password filter A process that ensures that passwords meet certain minimum requirements so that they are complicated enough that they cannot be easily guessed. See also password. password reset To set a password to a new value. See also password; password restrictions; password strength; password uniqueness. password restrictions Limitations on a password to ensure that it is more difficult to guess. These limitations typically include length, history, age, and not being in a dictionary of commonly used words. See also password; password strength; password uniqueness. password strength The degree to which a password has password restrictions. See also password; password restrictions; password uniqueness. password uniqueness The number of new passwords that must be used by a user account before an old password can be reused. See also password; password restrictions; password strength. PDC See definition for primary domain controller (PDC). permission The part of a security right that determines what a user can do to a security object; for example, Read, Create, or Delete. See also security rights. permitted viewers A list of users and user groups who can remotely control a client running Windows NT, Windows 2000, Windows XP, or a Windows Server 2003 family operating system. See also Remote Tools Permitted Viewers list. pragma statement A line in a Management Information Format (MIF) file, Managed Object Format (MOF) file, or event configuration file that indicates how the information in the file relates to the information in an SMS site database. See also Managed Object Format (MOF) file; Management Information Format (MIF) file; SMS site database.
Glossary 615
primary domain controller (PDC) In a Windows NT domain, a domain controller running Windows NT Server 4.0 or earlier that authenticates domain logon attempts and updates user, computer, and group accounts in a domain. The PDC contains the master read-write copy of the directory database for the domain. A domain has only one PDC. In a Windows 2000 or Windows Server 2003 domain, the PDC emulator master supports compatibility with client computers that are not running Windows 2000 or Windows XP Professional. See also Active Directory; backup domain controller (BDC). primary site A site that has its own SMS site database to store information for itself and its child sites. Primary sites can report to other primary sites and can have both primary and secondary sites report to them. See also child site; secondary site; SMS site database. privilege A users right to perform a specific task, usually one that affects an entire computer system rather than a particular object. Privileges are assigned by administrators to individual users or groups of users as part of the security settings for the computer. See also permission. process An operating system object that consists of an executable program, a set of virtual memory addresses, and one or more threads. When a program runs, a process is created. promiscuous mode In Network Monitor, a state in which a network adapter card copies all the frames that pass over the network, regardless of destination address, to a local buffer. This mode enables Network Monitor to capture and display all network traffic. See also buffer; capture; destination address; Network Monitor. prompt A report property that you can configure to request the user to enter a value when the report is run. The user-specified value is passed as the value of a variable in the reports SQL statement to limit or target the data returned. prompted query A query in which a dialog box prompts a user to supply more information. Prompted queries are constructed with a general expression, not a specific value. The SMS Administrator console prompts the user to supply the actual value when the query is run. See also SMS Administrator console. property A protocol element in Network Monitor that describes a separate field within each frame
that is sent by using that protocol. See also Network Monitor. proxy management point A secondary site management point that services the Advanced Clients that are in its roaming boundaries. See also management point; roaming boundaries; secondary site.
Q
query A set of criteria that is used to find objects in an SMS site database. When it runs, a query searches the SMS site database for objects that match the querys criteria. For example, a query can be used to search for all client computers that have Microsoft Word 97 installed. See also collection; SMS site database. query clause In a query, the combination of an expression (or query subclause) and its adjacent logical operator. See also logical operator; query; query subclause. query criteria The set of criteria used to search for objects. See also query. query expression A statement that uses an operator (such as, is equal to) to compare a specific value against a specific attribute. An expression is made up of an attribute, an operator, and a value. See also query. query group A set of expressions that are explicitly grouped by parentheses. By making a set of expressions a group, you ensure that the groups expressions are treated as a single entity. Groups have a higher operator precedence than the logical operators (AND, OR, and NOT). See also logical operator; query. query relational operator Part of an expression (such as, is equal to) that defines how a specified attribute should be compared with a value. See also query; query expression. query subclause A set of expressions that can be logically treated as a single expression. You can explicitly specify that a subclause is a group. See also query; query clause.
616 Glossary
R
Recovery Expert A Web-based site recovery tool that guides a site recovery process. The Recovery Expert collects information about a site failure scenario by presenting questions. It then evaluates the answers and presents a list of tasks that must be performed to recover the site. See also Recovery Expert Web site. Recovery Expert Web site A Web site on which the Recovery Expert runs. See also Recovery Expert. reference computer In SMS Installer, the computer that is used to build and test an SMS Installer executable file. SMS Installer is installed and run on the reference computer. The reference computer should, as much as possible, match the configuration of the target computers. See also SMS Installer executable file; target computers. reference site Designated child primary sites that are used to regain control of software distribution objects during a recovery operation. See also primary site; software distribution. refresh An administrative command that is used in software distribution to replace corrupted package source files on distribution points or to copy package source files to newly installed distribution points. See also distribution point; software distribution. regional roaming Roaming to lower level sites. This is the only roaming method available when Active Directory is not present. See also Active Directory; global roaming; lower level site. registered products Software whose use on clients is monitored by software metering. A product can be monitored without the license limit being enforced so that data is gathered about its use, or the license limit can be enforced so that no unauthorized copies are used. See also client; software metering. remote capture The process in which Network Monitor Agent performs a capture on a remote computer but displays the results on another computer (on a different subnet or physical segment) that is also running Network Monitor. See also Network Monitor; subnet. Remote Control Agent A program running on an SMS client that enables an SMS administrator to use remote troubleshooting tools to diagnose client problems or remotely control a client.
remote roaming boundary A roaming boundary in which the site distribution points are remote (that is, is not well-connected) to the Advanced Client, and software packages are not available locally to that client. See also Advanced Client; distribution point; local roaming boundary; wellconnected. remote site A site to which a client is assigned and has a network connection, but the client is not currently located. See also client. remote site system service accounts SMS accounts that site system services (other than those running on the site server) run under. See also site server; site system. Remote Tools Tools that an SMS administrator uses to directly control, monitor, or analyze client computers. Remote Tools Permitted Viewers list The accounts or groups that can use SMS Remote Tools on a computer that is running Windows NT. See also Remote Tools. Report Viewer A browser-based application that displays predefined SMS reports and dashboards. This application can be started from within the SMS Administrator console or by using a URL with Microsoft Internet Explorer. See also dashboard; SMS Administrator console. reporting point A site system that stores files that are used by Report Viewer and stores reports and dashboards. See also Report Viewer; site system. resident management point The closest management point to a roaming Advanced Client in an Active Directory environment. See also Active Directory; Advanced Client; management point. resource An object (such as a computer, a router, or a user group) that can be discovered and potentially be managed by SMS. Resources can be organized into collections. See also collection. resource class A class for a type of discovered resource, such as computers, users, or user groups. resource discovery The process of detecting and acquiring information about resources on the network. resource domain A Windows NT 4.0 domain that is used for hosting file, print, and other application services.
Glossary 617
Resource Explorer An SMS Administrator console feature that displays the hardware and software inventory that has been collected from clients. See also hardware inventory; SMS Administrator console; software inventory. resynchronization A process that occurs whenever an inventory file tries to update data that does not exist in the SMS site database, when the inventory data is corrupted, or when a client attaches to a new site. See also complete inventory; delta inventory; SMS site database. roaming boundaries The list of IP subnets, IP address ranges, and Active Directory sites that determine which roaming Advanced Clients are able to access the sites distribution points. See also Active Directory; distribution point; IP address; subnet.
S
SAM See definition for Security Accounts Manager (SAM). secondary site An SMS site that has no SMS site database or administrative tools. A secondary site is managed by and forwards inventory and status information to its parent site. A secondary site can only be a child site. See also child site; parent site; SMS site; SMS site database. Security Accounts Manager (SAM) A Windows service used during the logon process. SAM maintains user account information, including groups to which a user belongs. See also Security Accounts Manager (SAM) database. Security Accounts Manager (SAM) database The database that contains the accounts for a domain. Copies of the SAM are stored on all domain controllers. It can only be changed at the primary domain controller. All domain controllers use the SAM to authenticate account logons. See also primary domain controller (PDC); Security Accounts Manager (SAM). security context The security attributes or rules that are currently in effect. For example, the rules that govern what a user can do to a protected object are determined by security information in the users access token and in the objects security descriptor. Together, the access token and the security descriptor form a security context for the users actions on the object. See also security descriptor. security descriptor A data structure that contains security information associated with a protected
object. Security descriptors include information about who owns the object, who can access it and in what way, and what types of access are audited. See also security context. security log An event log containing information about security events that are specified in the audit policy. security policies The account, user rights, and audit policies that are managed using User Manager. There are also trust relationship policies that apply to domain controllers. See also trust relationship. security rights The functional level of access that is given to an SMS administrator. Security rights comprise three parts: a user or user group, a permission, and a security object. See also explicit security right; implicit security right; permission. send The method SMS uses to transfer data and instructions among sites. Data or instructions are compressed and written to a send request file. A sender transfers the file to the target site, which routes the data or instructions to the appropriate SMS services. See also send request file; sender. send request file A file with instructions that a sender uses to connect to and transfer data to a destination. See also send; sender. sender An SMS thread component that uses an existing connectivity system to communicate with other sites. A sender manages the connection, ensures the integrity of transferred data, recovers from errors, and closes connections when they are no longer needed. See also send; send request file. server locator point An SMS 2003 site system that locates CAPs and management points for SMS clients. See also client access point (CAP); management point; site system. service accounts Accounts that are intended to be used to run a service. A service account has privileges beyond those provided when a service is run as part of the system, such as being able to connect over the network to another computer. See also privilege; remote site system service accounts. service component SMS programs that run as services that can be started and stopped through the Services icon in Control Panel or the Computer Management administrative tool. session authentication Verification of an accounts logon information during the establishment of a session.
618 Glossary
sibling sites Sites on the same hierarchy tier that are child sites to the same parent site. See also child site; parent site. site assignment The process of allocating selected resources to an SMS site. See also resource; site assignment rules; SMS site. site assignment rules The list of subnets and Active Directory sites that an SMS administrator defines as the boundaries of an SMS site. SMS uses these rules to determine which resources and clients belong to the site. See also Active Directory; site assignment; site boundaries; SMS site; subnet. site boundaries A site property that defines the resources that the site manages and that contains the IP subnets and Active Directory sites. See also Active Directory; resource; roaming boundaries; subnet. site code A three-character code that SMS uses to identify a site. When a site is installed, a site code is assigned. The site code cannot be changed after installation. Site codes must be unique across an SMS site hierarchy. The valid characters for site codes are A through Z and 0 through 9. See also SMS hierarchy; SMS site. site control file An ASCII text file (such as Sitectrl.ct0) that contains the configuration of a site. There are two types of site control files: actual site control and delta site control. See also SMS site; SMS site database. site database See definition for SMS site database. site database server A site system role assigned to the computer that hosts the SMS site database (a SQL Server database). The computer might or might not be the site server. See also site server; SMS site database. site server A server on which SMS Setup has been run successfully. When SMS is installed on a computer, that computer is automatically assigned the site server role. See also site system role; SMS site. site system A server or share that provides SMS functionality to the site. The functionality that is contributed by a site system is indicated by its assigned roles. A site system can perform all roles or only one role. You determine some site system roles during installation and others by using the SMS Administrator console. In SMS 2003, there are two types of site systems: server and server share. See also site system role; SMS Administrator console.
site system role A role that a site system can perform on an SMS site. There are several possible site system roles. All of the roles can be assigned to the primary site server or spread out over several different site systems. Some of the roles are assigned during installation and others are assigned through the SMS Administrator console. See also site system; SMS Administrator console; SMS site. SMS Administrator console The primary interface that you use to configure, run, and access SMS features and tools. See also console tree. SMS hierarchy The relationship of all SMS sites within an organization. The main administrative site at the top of the hierarchy is known as the central site. See also central site; primary site; secondary site; SMS site. SMS Installer executable file The compressed executable file that SMS Installer generates with the installation script and all of the included files and directories. The Installer executable file is a self-extracting executable file that can be distributed to and run on clients. SMS Provider A site system role that processes requests for data from the SMS site database. See also CIM Object Manager; site system role; SMS site database. SMS site Site systems and resources that are bounded by a group of subnets, such as IP subnets or an Active Directory site. See also Active Directory; subnet. SMS site database A Microsoft SQL Server database that stores discovery data, a configuration and status inventory, and a software inventory. Every primary site has an SMS site database. The server supporting the SMS site database is automatically assigned the site database server role. See also discovery data; primary site; site system role; software inventory. SNA RAS Sender See definition for sender. snap-in A management tool or set of management tools designed to run within Microsoft Management Console (MMC). A snap-in can also be defined as code that provides management functionality. See also Microsoft Management Console (MMC); SMS Administrator console. software distribution The automated process of distributing software programs to client computers in an SMS hierarchy. See also SMS hierarchy.
Glossary 619
software inventory The automated process that SMS uses to gather information about software on client computers in an SMS site. See also SMS site. software metering The process by which SMS monitors program usage on client computers. source address A unique hexadecimal number in Network Monitor that identifies the computer from which data is sent. See also destination address; Network Monitor. Standard Sender See definition for sender. status filter rule A user-defined rule that determines the actions that Status Manager performs when it receives a status message from a component. Status Manager actions determine whether status messages are written to the SMS site database, replicated to the parent site, or written to the operating system event log. See also parent site; SMS site database; status message. status indicator Graphics that depict the overall status of an SMS component or site system. See also site system; status summarizer. status message A message for the SMS Administrator console generated by an SMS component. Status messages differ from operating system events in that they represent the flow of activity within an SMS site. See also SMS Administrator console; SMS site. status message ID A unique status message identifier. However, each instance of the same status message does not have a different ID. For example, if a certain messages ID is 62, it is 62 every time the message is generated. A status message has the same ID regardless of locale. Status Message Viewer maps each ID to localespecific message text. See also status message; Status Message Viewer. status message property An optional attribute of a status message that lets you differentiate among groups of messages when you are querying, finding, and filtering. A status message property can be Advertisement ID, Collection ID, Package ID, or User Name. See also status message; status message property value. status message property value An optional attribute of a status message property that is applied by the SMS component that generates the message. Status message properties let you differentiate messages associated with particular advertisements, collections, packages, and users when you are querying, finding, and filtering.
See also collection; package; status message; status message property. status message severity An indication of the significance of a status, such as error, warning, or informational. See also status indicator; status message. status message type The nature of the status message, such as audit, detail, or milestone. See also status message. Status Message Viewer A tool in the SMS Administrator console that is used to browse the status messages in the SMS site database. See also SMS Administrator console; SMS site database; status message. status reporting level The level at which client and server components report status messages to Status Manager and the Windows NT event log. See also status message. status summarizer A component that works with Status Manager to produce status summaries from status messages and other data in the SMS site database. See also SMS site database; status indicator; status message. status summary A data set that is generated by a status summarizer. Status summarizers use both the status messages that are collected by Status Manager and other data in the SMS site database to generate status summaries. See also SMS site database; status message; status summarizer. status system The overall system that generates, collects, processes, replicates, and presents status messages and other data to the SMS Administrator console. See also SMS Administrator console; SMS site database; status message; Status Message Viewer. strong password A password that provides an effective defense against unauthorized access to a resource. A strong password is at least six characters long, does not contain all or part of the users account name, and contains at least three of the four following categories of characters: uppercase characters, lowercase characters, base 10 digits, and symbols found on the keyboard (such as !, @, #). See also password; password restrictions; password strength; password uniqueness.
620 Glossary
subcollection A collection that is associated with another collection for the purpose of software distribution. See also collection; software distribution. subnet A subdivision of an Internet Protocol (IP) network. Each subnet has its own unique subnetted network ID. Summary pane In Network Monitor, the pane in a Frame Viewer window that lists the frames contained in the capture file. See also capture file; destination address; Frame Viewer window; Network Monitor; source address. supplemental report A file created outside of SMS and stored in a designated folder on a reporting point to extend reporting capabilities. See also reporting point.
For example, domain A trusts domain B, and domain B trusts domain A. All parent-child trusts are two-way. See also trust relationship.
U-V
update Used in software distribution to recopy package source files when a file is changed. When an update occurs, the package source version is incremented and the package source files are recopied from the site server to all distribution points currently specified for the package. See also distribution point; package; package source files; site server; software distribution. user profile A file that contains configuration information for a specific user, such as desktop settings, persistent network connections, and application settings. Each users preferences are saved to a user profile that Windows uses to configure the desktop each time a user logs on.
T
target computers Client computers that receive an SMS Installer executable file. See also reference computer; SMS Installer executable file. thread component An SMS program that runs as a thread of the SMS Executive service component. A thread component can be started and stopped through the SMS Service Manager. threshold A user-defined limit (a number of status messages or a percentage of available storage space) that, when crossed, changes a status indicator from OK to Warning or from Warning to Critical. See also status indicator; status message. transaction A bundle of related status messages that are evaluated together as a single unit. See also status message. trust relationship A logical relationship established between domains to allow passthrough authentication, in which a trusting domain honors the logon authentications of a trusted domain. User accounts and global groups defined in a trusted domain can be given rights and permissions in a trusting domain, even though the user accounts or groups dont exist in the trusting domains directory. See also permission; security rights. trusted domain A domain that is trusted by other domains. In the master domain model, the trusted domain is the master domain. See also trust relationship. two-way trust A trust relationship between two domains in which both domains trust each other.
W
WBEM See definition for Web-based Enterprise Management (WBEM). WBEM application An executable application that makes API calls to the CIM Object Manager to view or manage data from providers. Formerly called WBEM client. See also CIM Object Manager; Web-based Enterprise Management (WBEM); Windows Management Instrumentation (WMI). Web-based Enterprise Management (WBEM) A collection of technologies designed to facilitate management of an organization. Windows Management Instrumentation (WMI) is the Microsoft implementation of WBEM. See also Windows Management Instrumentation (WMI). well-connected A fast (high-bandwidth), reliable (low-latency) network connection. The precise meaning of well-connected is determined by your particular needs. See also local roaming boundary; remote roaming boundary. Windows Management Instrumentation (WMI) A management infrastructure in Windows that supports monitoring and controlling system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status. See also Web-based Enterprise Management (WBEM).
Glossary 621
Windows Management Instrumentation Service A service that starts and stops the CIM Object Manager. See also CIM Object Manager. Windows Management Service A Windows NT service that starts and stops the CIM Object Manager. See also CIM Object Manager. WMI See definition for Windows Management Instrumentation (WMI).
X-Z
X25 RAS Sender See definition for sender.
Technical Support Options
Product Name
Systems Management Server 2003
OEM distributed
If your product came installed with a new computer or device, the hardware manufacturer provides technical support and assistance for this software. Contact your manufacturer directly for support.
Support information online

http://support.microsoft.com In Canada, see http://microsoft.ca/support.
TTY users
Microsoft text telephone (TTY/TDD) services are available at (425) 635-4948 in Washington State, or (800) 892-5234 elsewhere in the U.S. Call (905) 568-9641 in Canada.
Worldwide
The support terms listed here are available in the United States and Canada only. Support elsewhere might vary. See the International Support list at http://support.microsoft.com/international.aspx for details about regional contacts. If there is no Microsoft subsidiary office in your country or region, contact the establishment from which you obtained your Microsoft product.
Conditions
Microsoft Product Support Services are subject to then-current prices, terms, and conditions, which are subject to change without notice.
Index
A
access account lists 154 access control 136 accessibility for people with disabilities 597605 account lockouts avoiding 165 enabling 458 accounts advanced security 442 Client Push Installation Accounts 151 client-level accounts, list of 149150 common server accounts 150151 creating 444 Database Accounts See Database Accounts list of 148150 lockouts 165, 458 managing 166, 436437 mandatory local multiple instance 443 mandatory multiple instance 442 minimizing number used 442444 modifying 444 optional multiple instance 443 overview 147 planning See planning accounts policies 459 principles 434435 security 136137 server-level accounts, list of 148149 Site Address Accounts 151 site reset 170172 site setup 166169 software distribution 190 standard security 442 trusted domains environment 184 ACL Reset 20 Active Directory authentication 308 client roaming across forests 263 creating containers 542 designing sites and hierarchies 255 discovering objects 370371 domain controllers 108, 337 domain models 225226 environment preparation 336 ExtADSch.exe 540 extending schema 336, 345, 422, 539541 forest considerations 338 overview 15 performance 300 planning migrations 281 planning site boundaries 262263 planning site deployments 335338 replication 336 schema extension 336, 345, 422, 539541 site boundaries 422 site membership 386 structure 227 Active Directory System Discovery 119, 371, 562 Active Directory System Group Discovery 121, 371, 562 Active Directory User Discovery 120, 370, 562 addresses configuring 362, 537539 creating 362, 445, 537 deleting 538 site communications 49 administering mixed-version hierarchies See mixedversion hierarchies Administrator console See SMS Administrator console Advanced Client Installer (Ccmsetup.exe) advantages 378 client deployment 123 command examples 570 command-line options 564565
626 Index Advanced Client Installer (Ccmsetup.exe) (continued) installation properties 565570 overview 378, 563564, 578 Advanced Client Network Access Account creating 449450 modifying 449450 overview 161 Advanced Client policy 29, 33, 36 Advanced Clients Advanced Client Network Access Account 449450 advantages 100 assigning to sites 382, 584586 automatically assigning to sites 584585 BITS-enabled software distribution 101 configuration overview 18 connectivity 164 imaging 126, 379 installing See installing Advanced Clients management points 3334, 105, 275277 manual client installations 126 manually assigning to sites 585586 mobile computer support 100 overview 13, 99 planning client deployments 375 planning roaming boundaries 257258 planning site boundaries 259261 remote computer support 101 removing 592 roaming and roaming boundaries 3334, 257258 site assignments 127 software distribution 68, 126, 379, 589590 software distribution security 190 unassigning from sites 586 updating 591592 upgrading to 588590 advanced security accounts 442 adding site systems to advanced security sites 146 maximizing benefits of 431 migrating to 145146 overview 14, 144, 430 planning site deployments 344 advanced security (continued) planning upgrades to SMS 2003 422 requirements 144 server accounts and groups 154 site system setup 432 Advertised Programs Client Agent 65 advertisements 64 Alpha-based systems 421 archive strategy planning 475479 archiving backup snapshots 475 asking for user permission 185 assigned management points 33 assigning Advanced Clients to sites 584586 assigning clients to sites 126128, 584587 assigning Legacy Clients to sites 586587 assignments 64 assistive technology products 603 attaching primary sites 539 attaching sites 362 attrition, upgrading clients by 419 auditing security 459 authentication overview 137 performance 308 automated Advanced Client installations 571574 automated Legacy Client installations 580 automatic removal of Legacy Clients 593 automatically assigning Advanced Clients to sites 584 585 automatically discovering resources 367368
B
Background Intelligent Transfer Service See BITS (Background Intelligent Transfer Service) backup and recovery administrative data 465 allocating servers to set up the Recovery Expert Web site 481 central sites 474 configuration data 465 developing backup and archive strategy 476478 impact of site failure 467469 minimizing impact of site failure 472474
Index 627 backup and recovery (continued) minimizing risk of site failure 470472 mixed-version hierarchies 206207 overview 1920, 92, 464 planning 463 planning for backup and archive 475479 planning site deployments 342 planning to simplify recovery processes 479483 reference sites 479481 backup destination local vs. remote drives 477 overview 464 sharing with multiple sites 477 Backup SMS Site Server task See SMS backup task backup snapshot overview 464 planning for archives 475 best practices operating system security 458459 risk avoidance 216217 BITS (Background Intelligent Transfer Service) Advanced Clients 101 benefits 101 distribution points 29, 274 overview 101 planning site configurations 355 BITS-enabled distribution points 274 BITS-enabled software distribution 101 blind accessibility 604 boundaries roaming See roaming and roaming boundaries sites See site boundaries budget planning See planning methodology building SMS hierarchy 47 business needs 233 CAP (client access point) (continued) Legacy Clients 106 overview 18 planning site configurations 355 polling for new advertisements 301 polling for software metering rules 303 propagating files between CAPs and site servers 301 roles 29 Set Preferred Distribution Point and CAP tool (PrefServ.exe) 104 capacity planning CPU utilization thresholds 292 definitions 290291 designing sites and hierarchies 254 disk utilization thresholds 293 memory utilization thresholds 293 modeling introduction 289293 modeling principles 292293 monitoring performance 294296 overview 287 performance and 294299 terms 290291 tools 291 Capinst.exe (Logon Script-initiated Client Installation) 124125, 377378, 574578, 581 CCM Boot Loader Account 161 Ccmclean.exe 592 Ccmsetup.exe See Advanced Client Installer central sites 26, 267, 338 change control and change management 218 child sites 26, 265 class level objects 173 client access point See CAP (client access point) Client Accounts 160163 client agents installing 128 manually starting 131 polling intervals 304 security settings 186 Client Connection Account creating 450452 managing 441 assigning site system roles 273 clients 104106 creating 530531 hardware requirements planning 318319
C
CAP (client access point)
628 Index Client Connection Account (continued) modifying 450452 overview 162 client deployment Active Directory System Discovery 119, 562 Active Directory System Group Discovery 121, 562 Active Directory User Discovery 120, 562 Advanced Client site assignments 127 assigning Advanced Clients to sites 584586 assigning clients to sites 126128, 584587 assigning Legacy Clients to sites 586587 automatically assigning Advanced Clients to sites 584585 CCMSetup.exe 123 client installation executables 123124 Client Push Installation 124125, 571574, 585 Client.msi 123 configuring discovery methods 556562 discovering resources See discovering resources enabling discovery methods 556562 Heartbeat Discovery 112, 561 imaging 126, 578580 installing Advanced Clients See installing Advanced Clients installing client agents 128 installing client software 121126 installing Legacy Clients 580583 Legacy Client site assignments 127 Logon Script-initiated Client Installation (Capinst.exe) 124125, 574578, 581 Manual Client Installation (SMSman.exe) 123, 126, 581583, 591 manually assigning Advanced Clients to sites 585 586 Network Discovery 112119, 557561 overview 108, 555 reinstalling clients 594 removing Advanced Clients 592 removing Legacy Clients 593594 repairing clients 594 unassigned clients 128 unassigning Advanced Clients from sites 586 unassigning Legacy Clients from sites 587 client deployment (continued) updating Advanced Clients 591592 updating Legacy Clients 592 upgrading client software 588592 upgrading to Advanced Client 588590 upgrading to Legacy Client 590 Windows User Account Discovery 112, 561 Windows User Group Discovery 112, 561 client discovery and installation mixed-version hierarchies 198200 overview 1617 Client Push Installation 124125, 376377, 571574, 585 Client Push Installation Accounts creating 444445 modifying 444445 overview 151 Client Push Installation Wizard 124, 573, 589, 591 client service accounts 162 Client Upgrade Control tool (Cliupgrade.exe) 408409 Client User Token Account 162 Client.msi 123 client-level accounts 149150 clients Active Directory domain controllers 108 Advanced Clients See Advanced Clients assigning to sites 126128, 381387, 584587 CAP (client access point) 104106 client agents See client agents Client Push Installation 124125, 376377, 571 574, 585 configuring 18, 129130 configuring primary sites 340 deployment See client deployment discovery methods overview 16 distribution points 106107 domain controllers 104108 environment planning methodology 223224 imaging 126, 578580 installation executables 123124 installation methods overview 17 installation strategies 364374
Index 629 clients (continued) installing See installing clients Legacy Clients See Legacy Clients Logon Script-initiated Client Installation (Capinst.exe) 124125 maintenance 129130 management points 104106 Manual Client Installation (SMSman.exe) 126 mobile computers 99 overview 3031, 9798 planning deployments See planning client deployments reinstalling 594 remote computers 99 repairing 594 requirements xxiiixxiv roaming See roaming and roaming boundaries server locator points 107 Set Client Travel Mode tool (CliTravl.exe) 103 site systems 104108 subnet membership 384 Systems Management Control Panel icon 131 types 132, 363364 unassigned 128 upgrading software 588592 user control 130132 version determination 132 CliTravl.exe (Set Client Travel Mode tool) 103 Cliupgrade.exe (Client Upgrade Control tool) 408409 cloning users 180 collections benefits 5455 IDMIF collection 191 membership rules 53, 63 mixed-version hierarchies 200 NOIDMIF collection 191 overview 2, 53 planning security 454 security 177, 191 software distribution 63 target collections 63 command-line options See also tools Capinst.exe (Logon Script-initiated Client Installation) 124125, 377378, 574578, 581 Ccmsetup.exe See Advanced Client Installer SMSMan.exe See Manual Client Installation (SMSman.exe) common server accounts 150151 common server groups 152153 communications management points 142 sites 4749, 262, 303 strategies See planning methodology compliance level 91 compliance type 91 component servers 28 computer imaging 126, 379, 578580 configuring addresses 362, 537539 configuring clients 18, 129130 configuring hierarchies See configuring sites configuring logging 349 configuring Performance Logs and Alerts 349 configuring primary sites with clients 340 configuring roaming and roaming boundaries 35, 350 352 configuring security 456457 configuring senders 535, 537 configuring site boundaries 350352 configuring site communications 358362, 534537 configuring site systems 528 configuring sites Active Directory schema extension 539541 assigning site system roles 529 attaching primary sites 539 CAP (client access point) 530531 communications 358362, 534537 configuring addresses 537539 configuring senders 535, 537 Courier Sender 536 creating addresses 537 creating containers in Active Directory 542 deleting addresses 538
630 Index configuring sites (continued) deleting senders 537 deleting site systems 531 distribution points 530531 ExtADSch.exe 540 extending Active Directory schema 539541 hierarchies 358362, 534 installing senders 535, 536 installing SMS 2003 See installing SMS 2003 management points 530531 manually adding site system roles in WINS 532533 overview 1718, 505, 527 planning See planning site configurations RAS senders 536 reassigning roles 531 removing roles 531 reporting points 530531 security 528 server locator points 530531 single site configurations 528533 site assignments 528 site hierarchy configurations 534539 site systems 528533 SNA RAS Sender 536 Standard Sender 535 WINS (Windows Internet Name Service) 532533 configuring SMS hierarchies See configuring sites configuring SQL Server 509 configuring status systems 349 configuring System Monitor 349 configuring Windows Event Viewer 349 console taskpads 551552 containers in Active Directory, creating 542 conventions, document xix counters 294299 Courier Sender 44, 536 Courier Sender Manager 203 CPU utilization thresholds 292 Create Package from Definition Wizard 190 credentials 136 Crystal Reports, removing 421, 493 Custom Setup installing primary sites 519522 overview 507 planning site deployments 343344 customer service for people who are deaf or hard-ofhearing 605 customizing hardware inventory 61, 422 customizing SMS Administrator console 553554 customizing software inventory 423
D
Database Accounts access account lists 154 account lockouts, avoiding 165 Advanced Client connectivity 164 Advanced Client Network Access Account 161 advanced security server accounts and groups 154 CCM Boot Loader Account 161 Client Connection Account 162 client service accounts 162 Client User Token Account 162 Legacy Client connectivity 163 Legacy Client Software Installation Account 163 mapping site server computer accounts to dbo users 153 orphaned clients, avoiding 166 overview 153 password filters 166 Remote Service Account 158 Server Connection Account 158 Site System Connection Account 158 SMS Service Account 157 standard security server accounts and groups 156 158 DDR (discovery data record) 109110, 300 deaf or hard-of-hearing accessibility 605 deep vs. flat hierarchies 4445, 267 definitions capacity planning 290291 glossary 607 deleting addresses 538 deleting senders 537 deleting site systems 531
Index 631 delta inventories 57 deploying clients See client deployment; planning client deployments deploying sites installing SMS 2003 See installing SMS 2003 overview 505 planning See planning site deployments secondary sites 340 Deployment Readiness Wizard (DRW.exe) preparing sites for upgrades 488489 resolving issues found by 399404 designing sites and hierarchies Active Directory migration planning 281 Active Directory site structure 255 advanced design issues 278281 advantages of multiple sites 279280 assigning site system roles 269 business considerations 251253 capacity 254 central sites 267 client environments 254 client management needs 259262 cost issues 266 data flow 252 domain migration planning 281 domain models 255 flat vs. deep hierarchies 267 geographic profiles 251 hierarchy design changes 282 information technology organization 252 interoperability 253, 280 legal policies 253 limiting impact of site failures 267269 management scope 265 multilanguage site hierarchies 280 network topology 254 number of child sites per parent 265 optimizing management plans 265 organizational policy 252 organizational structure 251 overview 247251 parent-child site relationships 265 designing sites and hierarchies (continued) performance 254, 266 planning site boundaries See planning site boundaries and roaming boundaries previous installations 253 primary site decisions 265 remote access servers 255 resources available for implementing SMS 253 reviewing designs in lab environments 281285 roaming and roaming boundaries See roaming and roaming boundaries sample design verification plan 284285 secondary site decisions 265 security 255 server environments 255 server sharing at secondary sites 266 server sizing 266 site communications 266 site server locations 264 site server relocation 270 site server types 264 site system relocation 270 site system roles See site system roles technical considerations 253255 testing designs in lab environments 281285 upgrading 280 disabilities, accessibility for people with 597605 discovering resources Active Directory System Discovery 119, 562 Active Directory System Group Discovery 121, 562 Active Directory User Discovery 120, 562 configuring discovery methods 556562 DDR (discovery data record) 109110 discovery methods 110111 enabling discovery methods 556562 Heartbeat Discovery 112, 561 installing Advanced Clients See installing Advanced Clients Network Discovery 112119, 557561 overview 108, 555 Windows User Account Discovery 112, 561 Windows User Group Discovery 112, 561
632 Index discovery automatically discovering resources 367368 choosing methods 366372 configuring methods 556562 controlling 372374 methods 110111, 556562 overview 16, 31 planning client deployment strategies 364374 polling intervals for discovery methods 304 scripts 372 discovery data record (DDR) 109110, 300 disk utilization thresholds 293 Distribute Software Updates Wizard 74 distribution of software See software distribution distribution points assigning site system roles 273 BITS-enabled distribution points 274 clients 106107 creating 530531 distributing software from site servers 301 downloading software to clients 302 hardware requirements planning 320321 overview 18, 29, 64 planning site configurations 355 protected distribution points 41, 274, 417418 Set Preferred Distribution Point and CAP tool (PrefServ.exe) 104 document conventions xix documentation in alternative formats 604 domain controllers clients 104108 planning client deployments 380 planning security 431 planning site deployments 337 domains planning methodology 224226 planning migration 281 planning security 430 planning site deployments 345 DRW.exe See Deployment Readiness Wizard (DRW.exe) dyslexic accessibility 604
E
education plans for users and IT professionals 242243 encryption, network security 139141 end-to-end response time 311312 environment analyses Active Directory structure 227 clients 223224 domain models 224226 geographic profiles 221 IT organization 231232 network topology 222223 organizational structures 221222 overview 218220 previous installations 220 security 231 server environments 228229 Event Viewer 349 exchanging keys among sites 141 Export Object Wizard 549 Express Setup installing primary sites 518519 overview 507508 planning site deployments 343344 ExtADSch.exe 540 extending Active Directory schema 336, 345, 422, 539 541
F
fan-out 69 features See SMS features filters 166 finalizing upgrade plans 420 flat vs. deep hierarchies 4445, 267 Forced Sites tool (Site4c.exe) 383 forcing client assignments 383
Index 633 forests client roaming 263 planning security 430 planning site deployments 338 higher level sites 27 holding sites 406
I
IDMIF collection 191 IIS (Internet Information Services) 138139 imaging 126, 379, 578580 Import Object Wizard 549 in-place hierarchy upgrades 406414 installation properties Capinst.exe (Logon Script-initiated Client Installation) 124125, 377378, 574578, 581 Ccmsetup.exe See Advanced Client Installer installing Advanced Clients automated installations 571574 Ccmsetup.exe See Advanced Client Installer imaging 578580 initiating program files at clients 574578 Logon Script-initiated Client Installation (Capinst.exe) 574578 manual installations 578 overview 17, 563 SMS Administrator console 571574 software distribution 578 installing client agents 128 installing clients Advanced Clients See installing Advanced Clients client software 121126 insufficient security credentials 583 Legacy Clients 17, 580583 installing Legacy Clients 17, 580583 installing primary sites 512, 517522 installing Recovery Expert 512 installing secondary sites 512, 523526 installing senders 535, 536 installing SMS 2003 components 496497 Custom Setup 507, 519522 Express Setup 507508, 518519 installation requirements 506 installing primary sites 512, 517522 installing Recovery Expert 512
G
getting started xvii global roaming 3941 glossary 607 groups common server groups 152153 creating 444 modifying 444 overview 147
H
hard-of-hearing or deaf accessibility 605 hardware inventory See hardware inventory planning site deployments 334335 replacing before upgrading to SMS 2003 399 SCSI RAID disk controllers 314315 site server hardware requirements See site server hardware requirements site system requirements 317322 hardware compatibility list (HCL) 334 hardware inventory benefits 6061 customizing 61, 422 mixed-version hierarchies 201202 overview 34, 5560 site hierarchies 60 Hardware Inventory Agent 56 hashing 139141 HCL (hardware compatibility list) 334 Heartbeat Discovery 112, 561 Help Desk 95 Help Viewer 598 hierarchies See site hierarchies; SMS hierarchy hierarchy branches 26 Hierarchy Maintenance Utility 20
634 Index installing SMS 2003 (continued) installing secondary sites 512, 523526 installing SMS Administrator console 512, 526 overview 505 preparing for installation 506511 process start 511517 security modes 507 Setup See Setup setup options 507508 SQL Server preparation 508511 unattended setup 512517 installing SMS Administrator console 512, 526 instance level objects 173174 international client deployment planning 380 Internet Information Services (IIS) 138139 interoperability See mixed-version hierarchies introduction 1 Inventory Agent 56 inventory collection 191 inventory data files 56 inventory resynchronization 57 inventory rules 56 IPX site boundaries 421 IT asset management 93 IT organization planning methodology 231232 Legacy Clients (continued) automatic removal 593 CAP (client access point) 106 configuration overview 18 connectivity 163 installing 17, 580583 Legacy Client Software Installation Account 452453 Manual Client Installation (SMSman.exe) 126 manual removal 593 mobile computer support 103 overview 102 planning client deployments 375 planning site boundaries 261 remote computer support 103 removing 593594 site assignments 127 Terminal Services 380 unassigning from sites 587 updating 592 upgrading to 590 licensing requirements xxii, 334335 lifecycles, account 435441 load signatures 312313 local multiple instance accounts 443 local roaming boundaries 35 lockouts, account 165, 458 logging 349 logon discovery 421 logon installation 421 logon points 421 Logon Script-initiated Client Installation (Capinst.exe) 124125, 377378, 574578, 581 lower level sites 27 Help Viewer 598 MMC (Microsoft Management Console) 598600 SMS Administrator console 601 keys, exchanging among sites 141
K
keyboard shortcuts
L
lab environments 244245, 281285 Legacy Client Software Installation Account creating 452453 modifying 452453 overview 163 Legacy Clients advantages 102 assigning to sites 383, 586587
M
maintenance clients 129130 database maintenance and consistency checks 500 Hierarchy Maintenance Utility 20 scheduling site database maintenance 349 site tools 11 sites 177
Index 635 management points Advanced Clients 105 assigned management points 33 assigning site system roles 275277 clients 104106 communications 142 creating 447, 530531 files between management points and site servers 301 hardware requirements planning 319320 modifying 447 overview 19, 29 performance counters 298299 planning site configurations 353354 polling for new advertisements 301 polling for software metering rules 303 proxy management points 33, 308 requirements 277 resident management points 33 roaming and roaming boundaries 3334 secondary sites 275 SQL Server database replication 276, 510 system monitoring objects 298299 mandatory local multiple instance accounts 443 mandatory multiple instance accounts 442 manual Advanced Client installations 578 Manual Client Installation (SMSman.exe) client deployment 123, 126, 581583, 591 planning client deployments 378 manual removal of Legacy Clients 593 manually adding site system roles in WINS 532533 manually assigning Advanced Clients to sites 585586 manually starting client agents 131 mapping site server computer accounts to dbo users 153 membership rules 53, 63 memory recommendations for SQL Server 509 memory utilization thresholds 293 Microsoft documentation in alternative formats 604 Microsoft hardware compatibility list (HCL) 334 Microsoft Management Console (MMC) 550552, 598 600 Microsoft Office Inventory Tool for Updates 72 Microsoft Operations Framework 215 Microsoft Solutions Framework 215 migrating to advanced security 145146 migration planning 281 mixed-version hierarchies backup and recovery 206207 client discovery and installation 198200 collections 200 Courier Sender Manager 203 data flow 194195 designing sites and hierarchies 253, 280 hardware inventory 201202 overview 193194 planning upgrades to SMS 2003 414 product compliance 206 queries 200 Remote Tools 205 reporting 205 SMS Administrator console interoperability with SMS 2.0 sites 196197 software distribution 202203 software inventory 202 software metering 206 software update management 203205 unsigned data flow 195 MMC (Microsoft Management Console) 550552, 598 600 mobile computers Advanced Client support 100 Legacy Client support 103 overview 99 monitoring performance 294296 monitoring security 459 mouse shortcuts 599 multilanguage site hierarchies 280 multiple instance accounts 442443 multiple management points 275 multisite clients 418419
N
NetBIOS requirements for site deployments 346 NetWare 420
636 Index Network Discovery DHCP tab 560 discovery scope 117119, 559561 discovery types 113116, 557559 Domains tab 560 overview 112, 557 planning client deployments 373 Schedule tab 561 SNMP tab and SNMP Devices tab 560 Subnets tab 559 topology 113, 557 topology and client 114115, 558 topology, client, and client operating system 115 116, 558 Network Load Balancing 353 Network Monitor 291 network monitoring 92, 303 networks Active Directory authentication 308 client component installations 305 encryption 139141 file sizes 305 hashing 139141 package download for software distribution 307 performance considerations 304308 polling intervals for client agents 304 polling intervals for discovery methods 304 proxy management points 308 remote secondary site installations 307 remote SQL Server 307 security 139142 server locator point queries 307 signing 139141 slow links 577 software metering 308 SQL Server database replication 308 status messages and status filter rules 306 topology planning 222223 NOIDMIF collection 191 Novell NetWare 420
O
object classes 172 objects changing rights 178180 class level object security 173 instance level object security 173174 security overview 172 security planning 453455 security rights 174178 Online Library xvii operating systems replacing before upgrading to SMS 2003 399 security 135137 security best practices 458459 site servers xx site systems xx SMS Administrator console xxixxii unsupported xxivxxv optimizing management plans 265 optional accounts 433434 optional multiple instance accounts 443 orphaned clients, avoiding 166 overlapping site boundaries 409 overnight upgrades 406407 overview 1
P
package definition files 64 package distribution 64 package download for software distribution 307 package source files 64 packages 64, 189 parent sites 25 parent-child site relationships designing sites and hierarchies 265 SMS hierarchy and 2527 passwords changing account 437440 filters 166
Index 637 performance Active Directory authentication 308 Active Directory discovery 300 capacity planning and 294299 client communication with server locator points 303 client component installations 305 collecting status messages 302 communicating between sites 303 counters 294299 CPU utilization thresholds 292 designing sites and hierarchies 254, 266 disk utilization thresholds 293 distributing software from site servers to distribution points 301 downloading software from distribution points to clients 302 file sizes 305 maintaining databases 302 memory utilization thresholds 293 monitoring 294296 network considerations 304308 network monitoring 303 overview 287 package download for software distribution 307 Performance Logs and Alerts 349 performance objects 294299 polling CAPs and management points for new advertisements 301 polling CAPs and management points for software metering rules 303 polling intervals for client agents 304 polling intervals for discovery methods 304 propagating DDRs 300 propagating files between CAPs or management points and site servers 301 propagating inventory 300 proxy management points 308 remote secondary site installations 307 remote SQL Server 307 Remote Tools 303 server activities that affect 299303 server locator point queries 307 software metering 303, 308 performance (continued) SQL Server database replication 308 status messages and status filter rules 306 system monitoring objects 294299 updating client configurations 302 Performance Logs and Alerts 349 permissions 136 Permitted Viewers list 183184, 186 phased-site upgrades 407414 physical security 143 pilot projects creating 389390 design analyses and changes 392396 dismantling 396 overview 387 running 390392 understanding 388389 planning accounts Advanced Client Network Access Account 449450 advanced security 442 Client Connection Account 441, 450452 Client Push Installation Accounts 444445 creating accounts or groups 444 Legacy Client Software Installation Account 452453 lifecycles 435441 management points 447 mandatory local multiple instance accounts 443 mandatory multiple instance accounts 442 minimizing number of accounts used 442444 modifying accounts or groups 444 optional accounts 433434 optional multiple instance accounts 443 overview 433 passwords 437440 principles 434435 security See planning security Server Connection Account 440 server locator point database accounts 447 Site Address Accounts 445 Site System Connection Account 449 SMS Service Account 440, 447448 SQL Server Accounts 446447
638 Index planning accounts (continued) standard security 442 strategies for reducing number of multiple accounts 444 planning Active Directory migrations 281 planning archive strategy 475 planning backup and recovery See backup and recovery planning capacity See capacity planning planning client deployments Active Directory site membership 386 Active Directory System Discovery 371 Active Directory System Group Discovery 371 Active Directory User Discovery 370 Advanced Client deployments 375 Advanced Client installations on computer images 379 assigning Advanced Clients 382 assigning clients to sites 381387 assigning Legacy Clients 383 automatically discovering resources 367368 client installation strategies 364374 client installation techniques 374 Client Push Installation 376377 client types 363364 discovery strategies 364374 domain controllers 380 Forced Sites tool (Site4c.exe) 383 forcing client assignments 383 initiating program files at clients 377379 international clients 380 Legacy Client deployments 375 Legacy Client installations 380 Logon Script-initiated Client Installation (Capinst.exe) 377378 Manual Client Installation (SMSMan.exe) 378 Network Discovery 373 overview 363, 374375 SMS Administrator console 376377 software distribution of Advanced Clients 379 subnet membership 384 Terminal Services 380 planning collection security 454 planning configurations overview 325 pilot projects See pilot projects sites See planning site configurations planning deployments clients See planning client deployments high level planning 326327 key elements 327330 overview 325 pilot projects See pilot projects sample plan 330333 sites See planning site deployments strategies 326333 planning domain migrations 281 planning methodology analyzing needs 232234 assembling project plans 240242 assembling teams 234240 assessing time and budget allotments 234 assigning roles 237238 best practices for risk avoidance 216217 business needs 233 change control and change management 218 communication methods 239240 communication strategies 238239 education plans 242243 environment analyses See environment analyses identifying requirements 232234 Microsoft Operations Framework 215 Microsoft Solutions Framework 215 occupation taxonomy 235237 overview 211212 risk management 216218 support plans 238240 test lab environments 244245 training plans 242243 understanding methodology and risks 213218 planning recovery process simplification 479483 planning security account policies 459 accounts See planning accounts advanced technologies 460
Index 639 planning security (continued) auditing security 459 checklist 427429 collections 454 configurations 456457 considerations 429430 enabling account lockouts 458 features 455 hierarchy design considerations 430431 methodology 231 monitoring security 459 objects 453455 operating system best practices 458459 overview 425 Setup 431432 site design considerations 430431 site systems 432 task list 426427 testing security 460461 tightening security 457458 using 455 planning site boundaries and roaming boundaries Active Directory considerations 262263 Advanced Clients 259261 client management needs 259262 client roaming across Active Directory forests 263 client types 259 common client activity cycles 262 communications site-to-site 263 communications within sites 262 Legacy Clients 261 naming sites 264 number of clients assigned to sites 259 overview 256257 secure key exchange 263 site-wide settings 257 Windows NT domain requirements 264 Windows Server 2003 and site communications 263 planning site configurations assigning site system roles 357 attaching sites 362 BITS (Background Intelligent Transfer Service) 355 planning site configurations (continued) CAP (client access point) 355 configuring addresses 362 creating addresses 362 distribution points 355 hierarchies 358362 logging 349 management points 353354 Network Load Balancing 353 overview 347 Performance Logs and Alerts 349 preparing site system computers 352357 reporting points 356 roaming boundaries 350352 scheduling site database maintenance 349 security 348 senders 358362 server locator points 355 site boundaries 350352 site communications 358362 SQL Server alerts 350 status system 349 System Monitor 349 Windows Cluster service 355 Windows Event Viewer 349 Windows Server 2003 requirements 356 planning site deployments Active Directory considerations 335338 Active Directory schema extension 345 advanced vs. standard security 344 backup and recovery 342 central sites 338 configuring primary sites with clients 340 domain requirements 345 Express vs. Custom Setup 343344 extending Active Directory schema 345 hardware requirements 334335 HCL (hardware compatibility list) 334 licensing requirements 334335 NetBIOS requirements 346 overview 333 secondary sites 340
640 Index planning site deployments (continued) security requirements 345 Setup options 342345 site database server considerations 341342 site naming 347 site server deployment considerations 338340 SMS Administrator console 342 SQL Server licensing 334 planning upgrades to SMS 2003 Active Directory schema extension 422 Active Directory site boundaries 422 advanced security 422 Alpha-based systems 421 attrition, upgrading clients by 419 Client Upgrade Control tool (Cliupgrade.exe) 408409 Crystal Reports, removing 421 Deployment Readiness Wizard (DRW.exe) 399404 effects of upgrades 405406 example scenarios 410413 extending Active Directory schema 422 finalizing upgrade plans 420 hardware inventory customization 422 in-place hierarchy upgrades 406414 interoperability during upgrades 414 IPX site boundaries 421 logon discovery 421 logon installation 421 logon points 421 loss of redundancy 419 Novell NetWare 420 overlapping site boundaries 409 overnight upgrades 406407 overview 397398 phased-site upgrades 407414 post-upgrade migration planning 420423 preparing to upgrade 399404 reconsider SMS objectives 405 replacing hardware and operating systems before upgrading 399 replacing multisite clients 418419 replacing secondary sites with protected distribution points 417418 planning upgrades to SMS 2003 (continued) restricting client installations 415 secondary sites 417 side-by-side hierarchy upgrades 414420 site coexistence 419 SMS 2.0 Web reports 422 SMS 2003 features 421423 SNMP Event to Trap translator 421 software inventory customization 423 software metering, legacy 421 transition sites 415 unsupported SMS 2.0 features and platforms 420 421 upgrade strategies overview 404 upgrading flat hierarchies 416 user support from multiple help desks 419 Windows Networking Logon Discovery 421 polling CAPs and management points for new advertisements 301 polling CAPs and management points for software metering rules 303 polling intervals for client agents 304 polling intervals for discovery methods 304 post-upgrade migration planning 420423 PrefServ.exe (Set Preferred Distribution Point and CAP tool) 104 Preinst.exe 172 preparing to install SMS 2003 506511 pre-planning See planning methodology primary sites attaching 539 configuring with clients 340 designing sites and hierarchies 265 installing 512, 517522 overview 25 parent-child relationships and the SMS hierarchy 25 27 task list for upgrading to SMS 2003 490494 testing site databases 491 upgrading 494496 principles, security account 434435
Index 641 product compliance benefits 91 compliance level 91 compliance type 91 mixed-version hierarchies 206 overview 1213, 90 process 9091 product documentation xviii project plan See planning methodology propagating DDRs 300 files between CAPs or management points and site servers 301 inventory 300 protected distribution points 41, 274, 417418 Provider See SMS Provider proxy management points 33, 308 remote computers Advanced Client support 101 Legacy Client support 103 overview 99 remote control 187 remote roaming boundaries 35 remote secondary site installations 307 Remote Service Account 158 Remote Tools asking for user permission 185 benefits 87 client agent security settings 186 mixed-version hierarchies 205 overview 10, 84 performance 303 Permitted Viewers list 183184, 186 process 8587 Remote.exe 186 security 182187 sessions 185 site hierarchies 87 Remote Tools Client Agent 85 Remote.exe 186 removing Advanced Client assignments from sites 586 removing Advanced Clients 592 removing Legacy Client assignments from sites 587 removing Legacy Clients 593594 removing roles 531 removing SMS 2.0 software metering settings 494 Repair Wizard 20 repairing clients 594 replacing multisite clients 418419 replacing secondary sites with protected distribution points 417418 replacing software metering when upgrading to SMS 2003 421 replication Active Directory 336 assigning site system roles 272, 276 manual setup 510 Report Viewer 89
Q
queries benefits 5455 mixed-version hierarchies 200 overview 2, 53 security 177, 180182 site hierarchies 5354
R
RAS senders 49, 536 reassigning roles 531 Recording for the Blind & Dyslexic, Inc. 604 recovery See backup and recovery Recovery Expert allocating servers to set up the Recovery Expert Web site 481 installing 512 overview 20 Recovery Expert Web site 481 reference sites 479481 regional roaming 3638, 41 reinstalling clients 594
642 Index reporting benefits 8990 mixed-version hierarchies 205 overview 12, 88 process 89 site hierarchies 90 reporting points assigning site system roles 278 creating 530531 hardware requirements planning 322 overview 19, 30, 89 planning site configurations 356 reports, security 180182 resident management points 33 resources xviixix, 3031 restricting client installations 415 rights changing object rights 178180 object security rights 174178 risk management 216218 roaming and roaming boundaries Advanced Clients 257258 client roaming across Active Directory forests 263 configuring 35 designing sites and hierarchies 256 global roaming 3941 local roaming boundaries 35 management points and roaming Advanced Clients 3334 overview 32 planning site configurations 350352 protected distribution points 41 regional roaming 41 regional roaming scenario 3638 remote roaming boundaries 35 scenarios 3640 software distribution 34
S
scan component 73 scenarios planning upgrades to SMS 2003 410413 roaming and roaming boundaries 3640 scheduling site database maintenance 349 schema, extending Active Directory 336, 345, 422, 539 541 scripts, using for discovery 372 SCSI RAID disk controllers 314315 secondary sites assigning site system roles 275 deploying 340 designing sites and hierarchies 265 installing 512 management points 275 overview 25 planning upgrades to SMS 2003 417 remote installations 307 replacing with protected distribution points 417418 server sharing 266 SMS Administrator console 549 upgrading 497499 security access control 136 account principles 434435 accounts See accounts advanced security See advanced security advanced technologies 460 asking for user permission 185 auditing 459 authentication 137 changing object rights 178180 checklist 427429 class level objects 173 configurations 456457 configuring sites 528 credentials 136 designing sites and hierarchies 255 encryption 139141 environments 135
Index 643 security (continued) exchanging keys among sites 141 groups See groups hashing 139141 IIS (Internet Information Services) 138139 instance level objects 173174 inventory collection 191 management point communications 142 managing accounts overview 166 managing accounts through site reset 170172 managing accounts through site setup 166169 managing accounts, general guidelines 436437 modes 143147 monitoring 459 networks 139142 object classes 172 object rights 174178 objects overview 172 operating system best practices 458459 operating systems 135137 overview 14, 133 packages 189 password filters 166 permissions 136 Permitted Viewers list 183184, 186 physical 143 planning See planning security planning site configurations 348 planning site deployments 345 queries 180182 remote control 187 Remote Tools 182187 Remote.exe 186 reports 180182 signing 139141 site maintenance 177 SMB signing 141142 SMS Reports 181 software distribution 188190 software metering 178 SQL Server 137 standard security See standard security security (continued) Systems Management container 542 testing 460461 tightening 457458 viewing resources in collections and queries 177 WMI (Windows Management Instrumentation) 138 Security Update Inventory tool 72, 502 senders choosing 358360 configuring 535, 537 Courier Sender 44, 536 deleting 537 installing 535536 preparing servers for sender Installations 361 RAS 49, 536 site communications 4749 SNA RAS Sender 49, 536 type list 48 Server Connection Account managing 440 overview 158 server locator points assigning site system roles 277 client communication 303 clients 107 creating 530531 database accounts, creating or modifying 447 hardware requirements planning 321322 overview 19, 30 planning site configurations 355 queries 307 Server message block (SMB) signing 141142 server sizing CPU utilization thresholds 292 disk utilization thresholds 293 end-to-end response time 311312 load signatures 312313 memory utilization thresholds 293 modeling introduction 289293 modeling principles 292293 overview 287, 309
644 Index server sizing (continued) server capacity 309313 site server hardware requirements See site server hardware requirements SLA (service level agreement) 309 system capacity model 309311 server-level accounts 148149 service level agreement (SLA) 309 Service Manager 550 Set Client Travel Mode tool (CliTravl.exe) 103 Set Preferred Distribution Point and CAP tool (PrefServ.exe) 104 Setup command-line options 168 initialization files 169, 512517 installing secondary sites 523524 planning security 431432 planning site deployments 342345 running 512 site reset 170171 unattended setup 512517 sibling sites 26 side-by-side hierarchy upgrades 414420 signing 139141 single site configurations 528533 Site Address Accounts creating 445 modifying 445 overview 151 site boundaries Active Directory 422 IPX 421 overlapping 409 overview 17, 31 planning See planning site boundaries and roaming boundaries planning site configurations 350352 site configuration See configuring sites site control files 24 site database servers assigning site system roles 271 overview 29 planning site deployments 341342 site failure impact 467469 minimizing impact 472474 minimizing risk 470472 site hierarchies Active Directory schema extension 539541 collections 5354 configuring 534539 creating containers in Active Directory 542 ExtADSch.exe 540 extending Active Directory schema 539541 hardware inventory 60 multilanguage 280 queries 5354 Remote Tools 87 reporting 90 software distribution 69 software inventory 60 software metering 83 site licensing requirements xxii, 334335 site maintenance tools 11 site reset account passwords 439 managing accounts 170172 overview 439 Preinst.exe 172 Server Connection Account 440 SMS Service Account 448 SQL Server Accounts 447 site server hardware requirements database requirements 322324 estimating number of clients and objects 315317 initial hardware requirements 317 overview 313314 SCSI RAID disk controllers 314315 site system hardware requirements 317322
Index 645 site servers assigning site system roles 271 central sites 267 cost issues 266 deployment considerations 338340 distributing software to distribution points 301 flat vs. deep hierarchies 267 hardware requirements See site server hardware requirements limiting impact of site failures 267269 locations overview 264 management scope 265 number of child sites per parent 265 operating systems xx optimizing management plans 265 parent-child site relationships 265 performance 266 performance counters 296298 primary site decisions 265 propagating files between CAPs or management points and site servers 301 requirements xxxxiii roles 28 secondary site decisions 265 server sharing at secondary sites 266 server sizing 266 site communications 266 site system relocation and 270 SMS Executive 28 SMS Site Component Manager 28 system monitoring objects 296298 types overview 264 Site System Connection Account creating 449 modifying 449 overview 158 site system roles BITS-enabled distribution points 274 CAP (client access point) 29, 273 component servers 28 distribution points 29, 273 management point overview 29 site system roles (continued) management point requirements 277 management points at secondary sites 275 management points for Advanced Clients 275277 management points, multiple 275 manually adding in WINS 532533 overview 1819, 27, 270 planning site configurations 357 protected distribution points 274 reporting points 30, 278 server locator points 30, 277 site database servers 271 site servers 28 site system creation 529 SMS Administrator console 272 SMS Provider 271 SMS site database servers 29 SQL Server database replication 272, 276 site systems adding to advanced security sites 146 assigning roles 269 clients 104108 configuring 528 creating 529532 deleting 531 hardware requirements 317322 operating systems xx overview 27 planning security 432 relocation and site servers 270 roles See site system roles Site4c.exe (Forced Sites tool) 383 sites Active Directory site membership 386 adding site systems to advanced security sites 146 addresses 49 Advanced Client site assignments 127 advantages of multiple 279280 assigning Advanced Clients 584586 assigning clients 126128, 381387, 584587 assigning Legacy Clients 586587 attaching 362
646 Index sites (continued) central sites 26, 267, 474 child sites 26, 265 clients 3031 coexistence 419 communications site-to-site 4749, 263, 266, 303 communications within sites 4749, 262 configuring See configuring sites deploying 505 designing See designing sites and hierarchies discovery 31 elements 2731 exchanging keys 141 higher level sites 27 holding 406 impact of failure 467469 installation overview 15 Legacy Client site assignments 127 lower level sites 27 maintenance 177 managing accounts through setup 166169 minimizing impact of failure 472474 minimizing risk of failure 470472 naming 264, 347 overview 2324 parent sites 25 parent-child relationships and management scope 265 parent-child relationships and the SMS hierarchy 25 27 performing upgrades 488 planning configurations See planning site configurations planning deployments See planning site deployments planning security 430431 preparing for upgrades 488494 primary sites See primary sites reference sites 479481 resources 3031 roaming and roaming boundaries See roaming and roaming boundaries secondary sites See secondary sites senders 4749 sites (continued) sibling sites 26 SMS Administrator console 31 SMS hierarchy See SMS hierarchy SMS Provider 31 task list for upgrading to SMS 2003 490 testing site databases 491 transition 415 types 2425 unassigning Advanced Clients 586 unassigning Legacy Clients 587 Windows Server 2003 and site communications 263 site-wide settings 257 sizing servers See server sizing SLA (service level agreement) 309 slow network links 577 SMB (Server message block) signing 141142 SMS 2.0 Web reports 422 SMS 2003 Deployment Readiness Wizard See Deployment Readiness Wizard (DRW.exe) SMS Administrator console Action menu 548 administering SMS 2.0 sites 196 assigning site system roles 272 client version and type determination 132 connecting to SMS 2.0 sites 195196 console tree 545547 customizing 553554 details pane 547 Export Object Wizard 549 Import Object Wizard 549 installing 512, 526 installing Advanced Clients 571574 installing Legacy Clients 580 installing secondary sites 524526 interoperability with SMS 2.0 sites 196197 keyboard shortcuts 601 mixed-version hierarchies 195197 MMC (Microsoft Management Console) 550552 overview 13, 31, 543544 planning client deployments 376377 planning site deployments 342
Index 647 SMS Administrator console (continued) properties, viewing or modifying 548 requirements xxixxii secondary sites 549 security mode changing 145 shortcut menu 548 site reset 170 SMS Service Manager 550 toolbar buttons 547548 version support 544 SMS backup task backup destinations 477 overview 464 planning for archives 475 SMS Client Accounts 160163 SMS clients See clients SMS Executive 28 SMS features Active Directory schema extension 422 Active Directory site boundaries 422 advanced security 422 backup and recovery 92 collections See collections extending Active Directory schema 422 hardware inventory See hardware inventory Help Desk 95 integrating features 9395 IT asset management 93 network monitoring tools 92 overview 2, 5152 planning security 455 planning upgrades to SMS 2003 421423 product compliance See product compliance queries See queries Remote Tools See Remote Tools reporting See reporting security 180 software distribution See software distribution software inventory See software inventory software management 9395 software metering See software metering SMS features (continued) software update management See software update management status system 92 unsupported xxivxxv, 420421 SMS hierarchy attaching sites 47 building 47 configuring See configuring sites designing See designing sites and hierarchies flat vs. deep hierarchies 4445, 267 hierarchy branches 26 mixed-version hierarchies See mixed-version hierarchies modeling concepts 4344 overview 42 parent-child site relationships 2527 planning security 430431 tiers 26 SMS Installer 65 SMS objects See objects SMS Online Library xvii SMS Provider assigning site system roles 271 overview 31 SMS Reports 181 SMS Service Account creating 447448 managing 440 modifying 447448 overview 157 SMS Service Manager 550 SMS Setup See Setup SMS Site Component Manager 28 SMS site database servers See site database servers SMS User Wizard 179180 SMS Web site xix SMS_def.mof 56 SMSMan.exe See Manual Client Installation (SMSman.exe) SNA RAS Sender 49, 536 SNMP Event to Trap translator 421
648 Index software distribution accounts 190 Advanced Clients 68, 126, 379 benefits 7071 BITS (Background Intelligent Transfer Service) 101 collections 63 fan-out 69 installing Advanced Clients 578 mixed-version hierarchies 202203 objects 6364 overview 46, 62 package definition files 64 package download 307 package source files 64 process 6568 programs 63 roaming and roaming boundaries 34 security 188190 site hierarchies 69 SMS Installer 65 upgrading to Advanced Client 589590 Software Distribution Client Agent 65 software distribution package 64 Software Distribution Wizard 190 software inventory benefits 62 customization 423 mixed-version hierarchies 202 overview 34, 5560 site hierarchies 60 Software Inventory Agent 56 software metering benefits 83 mixed-version hierarchies 206 overview 910, 79 performance 303, 308 polling CAPs and management points for software metering rules 303 process 8083 replacing when upgrading to SMS 2003 421 security 178 software metering (continued) site hierarchies 83 upgrading to SMS 2003 494 Software Metering Client Agent 80 software update inventory tools 7273 software update management benefits 7879 Distribute Software Updates Wizard 74 enhancements 8 mixed-version hierarchies 203205 overview 6, 72 process 7478 reports 74 scan component 73 software update inventory tools 7273 Software Updates Installation Agent 73 synchronization component 73 tools 67 upgrading to SMS 2003 501503 Software Updates Installation Agent 73 specialized storage technology, support xxii SQL Server alerts 350 assigning site system roles 272 configuring 509 database replication 272, 276, 308, 510 hardware requirements planning 322324 licensing 334 memory recommendations 509 performance 307 preparations for installing SMS 2003 508511 security 137 testing site databases 491 tuning 509 SQL Server Accounts 446447 standard security accounts 442 Client Accounts 160163 creating addresses for other sites 445 overview 14, 146, 431 planning site deployments 344
Index 649 standard security (continued) server accounts and groups 156158 site system setup 432 Standard Sender 535 status filter rules status messages 306 upgrading to SMS 2003 500 status system overview 13, 92 planning site configurations 349 subnet membership 384 supplemental reports 88 support plan See planning methodology supported platforms xixxxiv synchronization component 73 system capacity model 309311 System Monitor objects and counters 294299 overview 291 planning site configurations 349 sizing component servers 309 system monitoring objects 294299 system requirements xixxxiv Systems Management container security 542 Systems Management Control Panel icon 131 Systems Management Installation Wizard 123 tools See also command-line options ACL Reset 20 capacity planning 291 Client Upgrade Control tool (Cliupgrade.exe) 408409 Forced Sites tool (Site4c.exe) 383 Hierarchy Maintenance Utility 20 Microsoft Office Inventory Tool for Updates 72 network monitoring 92 recovery 1920 Recovery Expert See Recovery Expert Remote Tools See Remote Tools Security Update Inventory tool 72, 502 Set Client Travel Mode tool (CliTravl.exe) 103 Set Preferred Distribution Point and CAP tool (PrefServ.exe) 104 site maintenance 11 SMS Installer 65 software update inventory tools 7273 software update management 67 upgrade 11 training plans for users and IT professionals 242243 transition sites 415 Travel Mode 103 tuning SQL Server 509
U
unassigned clients 128 unassigning Advanced Clients from sites 586 unassigning Legacy Clients from sites 587 unattended setup 512517 unsupported features xxivxxv, 420421 unsupported operating systems xxivxxv updating Advanced Clients 591592 updating Legacy Clients 592 upgrade tools 11 upgrading client software 588592 upgrading to Advanced Client 588590 upgrading to Legacy Client 590
T
target collections 63 team assembling See planning methodology technical assistance for accessibility 605 technical resources xviixix Terminal Services 380 terminology capacity planning 290291 glossary 607 test lab environments 244245, 281285 testing site databases 491 tiers, hierarchy 26 tightening security 457458
650 Index upgrading to SMS 2003 Crystal Reports, removing 493 database maintenance and consistency checks 500 Deployment Readiness Wizard See Deployment Readiness Wizard (DRW.exe) designing sites and hierarchies 280 installing SMS components 496497 overview 487 performing site upgrades 488 planning See planning upgrades to SMS 2003 post-upgrade tasks 499503 preparing sites for upgrades 488494 primary sites task list 490494 removing SMS 2.0 software metering settings 494 Security Update Inventory tool 502 site configuration 500 site task list 490 software update management 501503 status filter rules 500 testing site databases 491 upgrading primary sites 494496 upgrading secondary sites 497499 user control of clients 130132 users, cloning 180 utilities See tools Windows Cluster service 355 Windows Event Viewer 349 Windows Internet Name Service (WINS) 532533 Windows Management Instrumentation (WMI) 138 Windows Network Load Balancing 353 Windows Networking Logon Discovery 421 Windows NT accessibility for people with disabilities 602 domain models 225 domain requirements 264 Windows Server 2003 Active Directory domain models 226 planning site configurations 356 site communications 263 Windows User Account Discovery 112, 561 Windows User Group Discovery 112, 561 Windows XP accessibility for people with disabilities 601 WINS (Windows Internet Name Service) 532533 wizards Client Push Installation Wizard 124, 573, 589, 591 Create Package from Definition Wizard 190 Deployment Readiness Wizard See Deployment Readiness Wizard (DRW.exe) Distribute Software Updates Wizard 74 Export Object Wizard 549 Import Object Wizard 549 Repair Wizard 20 SMS User Wizard 179180 Software Distribution Wizard 190 Systems Management Installation Wizard 123 WMI (Windows Management Instrumentation) 138 accessibility for people with disabilities 602 Active Directory domain models 225 Windows 95 accessibility for people with disabilities 602 Windows 98 accessibility for people with disabilities 602
W
Windows 2000

SMSCPDG

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SMSCPDG

Diunggah oleh

Hak Cipta:

Format Tersedia

Concepts, Planning, and Deployment Guide

Microsoft Systems Management Server 2003

Scalable Management for Windows-based Systems

Document No. X09-75009 Printed in the United States of America.

xviii Getting Started

To run the SMS Online Library

Product Documentation Available for SMS

Microsoft Systems Management Server 2003 Operations Guide

Keeping Your Technical Knowledge Current

System Requirements and Supported Platforms xix

Indicates an unordered list of related information that is not a procedure.

System Requirements and Supported Platforms

Requirements for Site Servers and Other Site Systems

Supported platforms and prerequisites for site system roles

System Requirements and Supported Platforms xxi

Table 0.3 Prerequisites for Site Systems (continued)

Server locator point

Requirements for Site Servers and the SMS Administrator Console

Table 0.4 Requirements for SMS Site Servers

xxii Getting Started

Table 0.4 Requirements for SMS Site Servers (continued)

Remote SMS Administrator console

SQL Server 7.0

SQL Server 2000

Other SMS site system

Terminal Server session.

Site licensing and SQL Server licensing

Support for specialized storage technology

System Requirements and Supported Platforms xxiii

Requirements for SMS Clients

Table 0.6 Operating System Requirements for SMS 2003 Clients

xxiv Getting Started

Unsupported Operating Systems and Features

Unsupported Operating Systems and Features xxv

SNMP Event to Trap Translator

Introducing Systems Management Server 2003

2 Chapter 1 Introducing Systems Management Server 2003

SMS 2003 Features and Enhancements

Collections and Queries

SMS 2003 Features and Enhancements 3

Hardware and Software Inventory

Support for WMI 1.5 and later

Discovery-based software inventory

4 Chapter 1 Introducing Systems Management Server 2003

Add or Remove Programs search

SMS 2003 Features and Enhancements 5

Table 1.2 SMS 2003 Software Distribution Features (continued)

Download and run

Delta distribution between site servers

Convert older SMS packages to Windows Installer

Create packages from Windows Installer files

Add or Remove Programs integration

6 Chapter 1 Introducing Systems Management Server 2003

Table 1.2 SMS 2003 Software Distribution Features (continued)

Protected distribution point

Software Update Management

Tools for Managing Software Updates

SMS 2003 Features and Enhancements 7

Microsoft Office Inventory Tool for Updates

8 Chapter 1 Introducing Systems Management Server 2003

Enhancements to Software Update Management

Unattended software update installation

Firewall authentication support