Pro SMS 2003

CYAN MAGENTA YELLOW BLACK PANTONE 123 CV BOOKS FOR PROFESSIONALS BY PROFESSIONALS ® Companion eBook Available Pro SMS...

Author: Rod Kruetzfeld

104 downloads 852 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

CYAN MAGENTA

YELLOW BLACK PANTONE 123 CV

BOOKS FOR PROFESSIONALS BY PROFESSIONALS ® Companion eBook Available

Pro SMS 2003 Years of consulting experience have given me the opportunity to work with SMS implementations in a variety of environments, and I’ve seen more best practices and worst practices than you can imagine. I’ve seen brilliantly planned and executed configurations, as well as unplanned and hurried ones. Unsurprisingly, the bad ones outnumbered the good ones. I wrote this book so you don’t need to call someone like me to fix common and easily avoided problems. Here, I tell you up front and in detail how to quickly leverage SMS’s complex features. I reference community resources that are critical to efficient SMS administration, including free add-ons and commercial products that help fill feature gaps and extend your reach to remote systems. And I cover SMS 2003 Features Packs extensively, because the product has changed dramatically since its first release. Among the topics I cover in detail are: Planning successful upgrades or new installations Configuring SMS sites Managing SMS clients Delivering software and reporting Using SMS Feature Packs Taking advantage of the SMS community Customizing and extending SMS

Pro SMS 2003

Dear Reader,

• • • • • • •

THE EXPERT’S VOICE ® IN NETWORKING

Pro

SMS 2003

This is the book I wish someone had written for me when I first started working with the product. Rod Kruetzfeld

RELATED TITLES Companion eBook

See last page for details on $10 eBook version

ISBN 1-59059-698-6 53999

US $39.99

Kruetzfeld

SOURCE CODE ONLINE

www.apress.com

Rod Kruetzfeld

Shelve in Microsoft Servers User level: Intermediate–Advanced

6

89253 59698

2

9 781590 596982

this print for content only—size & color not accurate

spine = 0.584" 248 page count

Kruetzfeld_698-6FRONT.fm Page i Monday, November 6, 2006 4:14 PM

Pro SMS 2003

■■■

Rod Kruetzfeld

Kruetzfeld_698-6FRONT.fm Page ii Monday, November 6, 2006 4:14 PM

Pro SMS 2003 Copyright © 2006 by Rod Kruetzfeld All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 981-1-59059-698-2 ISBN-10 (pbk): 1-59059-698-6 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Jim Sumser Technical Reviewer: Judith Myerson Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jason Gilmore, Jonathan Gennick, Jonathan Hassell, James Huddleston, Chris Mills, Matthew Moodie, Dominic Shakeshaft, Jim Sumser, Keir Thomas, Matt Wade Project Manager: Elizabeth Seymour Copy Edit Manager: Nicole Flores Copy Editor: Marilyn Smith Assistant Production Director: Kari Brooks-Copony Production Editor: Ellie Fountain Compositor: Susan Glinert Proofreader: Nancy Sixsmith Indexer: Valerie Haynes Perry Artist: Kinetic Publishing Services, LLC Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected], or visit http://www.springeronline.com. For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley, CA 94710. Phone 510-549-5930, fax 510-549-5939, e-mail [email protected], or visit http://www.apress.com. The information in this book is distributed on an “as is” basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.

Kruetzfeld_698-6FRONT.fm Page iii Monday, November 6, 2006 4:14 PM

I would like to dedicate this book to my wife, Jodi, and two children, Erik and Abbey, for their unending support in achieving this accomplishment. They each served as my special motivator, and, at times, much-needed distraction. With their support and encouragement, they gave me the courage to start and keep going. I would also like to thank the many members of the myITforum community for all their support and knowledge over the years, enabling me to write the technical content for this book. Everyone who has helped me out over the years, Chapter 8 is for you!

Kruetzfeld_698-6FRONT.fm Page iv Monday, November 6, 2006 4:14 PM

Kruetzfeld_698-6FRONT.fm Page v Monday, November 6, 2006 4:14 PM

Contents at a Glance

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

■CHAPTER 1

Introducing SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

■CHAPTER 2

Planning Your SMS 2003 Implementation . . . . . . . . . . . . . . . . . . . . . . 9

■CHAPTER 3

Installing and Configuring SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . 35

■CHAPTER 4

SMS 2003 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

■CHAPTER 5

SMS 2003 Software Delivery and Reporting . . . . . . . . . . . . . . . . . . 115

■CHAPTER 6

SMS 2003 Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

■CHAPTER 7

SMS Feature Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

■CHAPTER 8

The SMS Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

■CHAPTER 9

Moving SMS into Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

v

Kruetzfeld_698-6FRONT.fm Page vi Monday, November 6, 2006 4:14 PM

Kruetzfeld_698-6FRONT.fm Page vii Monday, November 6, 2006 4:14 PM

Contents

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

■CHAPTER 1

Introducing SMS 2003

.....................................1

SMS 2003 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 SMS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SMS Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 WBEM and WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 SMS 2003 Project Planning Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 POC Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Pilot Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

■CHAPTER 2

Planning Your SMS 2003 Implementation . . . . . . . . . . . . . . . . . 9 Upgrade or New Installation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Side-by-Side Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 In-Place Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Installation Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 SMS Site Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Site Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Drive Array Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Server Memory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

vii

Kruetzfeld_698-6FRONT.fm Page viii Monday, November 6, 2006 4:14 PM

viii

■C O N T E N T S

Active Directory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Active Directory Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Active Directory Computer Account Cleanup . . . . . . . . . . . . . . . . . . . 20 SMS Schema Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Network Load Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Available Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Network Considerations for the Advanced Client and BITS . . . . . . . 24 SQL Server Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Client Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Multiple Site Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Primary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Proxy Management Points (PMPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 SMS Site Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 SMS Site Boundaries and Client Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 29 Roaming Clients and MPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Roaming for Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Local Roaming vs. Remote Roaming Boundaries . . . . . . . . . . . . . . . 31 Protected Distribution Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Regional and Global Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

■CHAPTER 3

Installing and Configuring SMS 2003

. . . . . . . . . . . . . . . . . . . . 35

Schema Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Meeting the Schema Extension Prerequisites . . . . . . . . . . . . . . . . . . 36 Updating the Schema on Windows 2000 Server . . . . . . . . . . . . . . . . 36 Updating the Schema on Windows Server 2003 . . . . . . . . . . . . . . . . 37 Verifying the Schema Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Configuring SMS 2003 Active Directory Data Publishing . . . . . . . . . 38 Security and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Choosing a Security Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Setting SMS Console Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Customizing the SMS Administrator Console . . . . . . . . . . . . . . . . . . 43 Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Configuring Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Configuring Senders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Configuring Client Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Configuring Connection Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuring Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Kruetzfeld_698-6FRONT.fm Page ix Monday, November 6, 2006 4:14 PM

■C O N T E N T S

Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Meeting the SMS 2003 Advanced Client Prerequisites . . . . . . . . . . 58 Using Client Push Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Installing a Client Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Installing a Client with a Machine Startup Script . . . . . . . . . . . . . . . 61 Imaging Computers with the SMS 2003 Advanced Client Preinstalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Resizing the Advanced Client Cache . . . . . . . . . . . . . . . . . . . . . . . . . 63 Troubleshooting Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Uninstalling SMS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Secondary and Child Primary Site Installation . . . . . . . . . . . . . . . . . . . . . . 70 Installing Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Installing Child Primary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Adding Site Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Site Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Removing Secondary Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Removing a Child Primary Site Server . . . . . . . . . . . . . . . . . . . . . . . . 84 Unlocking Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

■CHAPTER 4

SMS 2003 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . 89 Site Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 SMS Site Component Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 SMS Client Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Setting Up the Client Health Monitoring Tool . . . . . . . . . . . . . . . . . . . 94 SMS Client Health Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Creating Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Setting Up Security for Collections . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

■CHAPTER 5

SMS 2003 Software Delivery and Reporting

. . . . . . . . . . . . 115

Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Defining Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Checking the Status of Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Creating Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Monitoring Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Modifying Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

ix

Kruetzfeld_698-6FRONT.fm Page x Monday, November 6, 2006 4:14 PM

x

■C O N T E N T S

Software Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Defining Software Metering Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Scheduling Software Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Configuring Software Metering Tasks . . . . . . . . . . . . . . . . . . . . . . . 134 Using Software Metering Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Web Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Importing and Exporting Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Retrieving Converted WQL for a Web Report . . . . . . . . . . . . . . . . . . 141 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

■CHAPTER 6

SMS 2003 Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Patch Management Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 SMS 2003 Inventory Tool for Microsoft Updates (ITMU) . . . . . . . . . . . . . 146 Installing ITMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Setting Up ITMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Troubleshooting Update Deployment . . . . . . . . . . . . . . . . . . . . . . . . 159 Other Scanning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Patch Application Techniques and Tricks . . . . . . . . . . . . . . . . . . . . . . . . 161 Update Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 SMS Reporting on Patch Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

■CHAPTER 7

SMS Feature Packs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

SMS Operating System Deployment Feature Pack . . . . . . . . . . . . . . . . . 163 Installing the SMS OSD Feature Pack. . . . . . . . . . . . . . . . . . . . . . . . 164 Creating an OS Image Capture CD . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Capturing an OS Image Using the OS Image Capture CD . . . . . . . 165 Creating an OSD Image Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Deploying the Captured Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Solution Accelerator for BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Setting Up BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Configuring the Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Capturing the Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 SMS Device Management Feature Pack . . . . . . . . . . . . . . . . . . . . . . . . . 183 SMS Administration Feature Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Manage Site Accounts Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Elevated-Rights Deployment Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Transfer Site Settings Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Kruetzfeld_698-6FRONT.fm Page xi Monday, November 6, 2006 4:14 PM

■C O N T E N T S

■CHAPTER 8

The SMS Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 SMS Tools and Add-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Free Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Commercial Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Web-Based Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 myITforum.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Blogcast Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 AppDeploy.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 DesktopEngineer.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

■CHAPTER 9

Moving SMS into Operations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

MOM Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 MOM Alert on Program Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 System Center Product Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Backup and Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 SMS Backup Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Disaster Recovery Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 SMS Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Status Message Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Status Message Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 SMS Inventory Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 SMS MIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 SMS MOF Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Software Packaging and Scripting Products . . . . . . . . . . . . . . . . . . . . . . 209 SMS Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Wise Package Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 FLEXnet AdminStudio SMS Edition . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

xi

Kruetzfeld_698-6FRONT.fm Page xii Monday, November 6, 2006 4:14 PM

Kruetzfeld_698-6FRONT.fm Page xiii Monday, November 6, 2006 4:14 PM

About the Author

■ROD KRUETZFELD has been working in the IT industry for more than 12 years. Currently, he is a senior consultant for a national Canadian Microsoft Gold Partner. He specializes in Microsoft Systems Management Server (SMS) and Microsoft Operations Manager (MOM) implementations and operations, bringing success with these products to many clients. Rod holds a Certified Engineering Diploma in Computer Engineering Technology from SIAST Palliser Campus, as well as a number of certifications, including Microsoft Certified Technology Specialist in Business Desktop Deployment (BDD 2.5). Rod has been an active member of the SMS community for many years. Through his work and community activities, he has gained a lot of knowledge of SMS 2003 and its use in various corporate environments. He maintains a blog at http://myitforum.com/cs2/blogs/rkruetzfeld/ default.aspx, where he addresses issues related to SMS and MOM. Rod lives in beautiful Calgary, Alberta, Canada, where he spends his spare time with his family and pursuing various activities, including camping and photography.

xiii

Kruetzfeld_698-6FRONT.fm Page xiv Monday, November 6, 2006 4:14 PM

Kruetzfeld_698-6FRONT.fm Page xv Monday, November 6, 2006 4:14 PM

About the Technical Reviewer

■JUDITH M. MYERSON is a systems architect and engineer. Her areas of interest include middleware technologies, application development, web development, software engineering, network management, servers, security management, information assurance, standards, RFID technologies, and project management. Judith holds a Master of Science degree in engineering, and is a member of the IEEE organization. She has reviewed/edited a number of Apress books, including Hardening Linux, Creating Client Extranets with SharePoint 2003, and Microsoft SharePoint: Building Office 2003 Solutions.

xv

Kruetzfeld_698-6FRONT.fm Page xvi Monday, November 6, 2006 4:14 PM

Kruetzfeld_698-6FRONT.fm Page xvii Monday, November 6, 2006 4:14 PM

Introduction

S

ystems Management Server (SMS) is Microsoft’s change and configuration management solution. It allows network administrators to provide software, updates, and remote connectivity quickly and cost-effectively from a central location. SMS 2003, the fifth revision of Microsoft’s product, offers additional features, such as asset inventory and management, remote diagnosis and troubleshooting, and operating system deployment (using the SMS Operating System Deployment Feature Pack). The increasing complexity of Microsoft networks makes knowledge of SMS mandatory. The goal of Pro SMS 2003 is to arm administrators with that knowledge, so they can successfully design and implement SMS 2003 in their particular environments. Here is a quick rundown and what you’ll find in this book: Chapter 1, Introducing SMS 2003: I begin with an overview of SMS 2003 features and descriptions of the basic components of an SMS implementation. Here, I explain key terminology and concepts, and also outline SMS 2003 project planning approaches. In the companies where I implement SMS 2003 or work on their hierarchies, I frequently see a gap in associated documentation. Documenting your SMS 2003 systems is crucial to maintenance and troubleshooting. Hand-inhand with documentation are the proof-of-concept and pilot phases of a project. These areas are too frequently neglected, so I emphasize them here. Chapter 2, Planning Your SMS 2003 Implementation: Before you install SMS, you need to make some important preparations and choices, whether you’re implementing SMS in a small or large enterprise. These include designing your SMS 2003 hierarchy and performing capacity planning. Since not all the SMS 2003 infrastructures will be simple cut-and-dried hierarchies of a single server, I discuss the various decisions you may make in designing the overall layout of site systems. The topics range from server hardware to Active Directory issues and SMS client roaming. Chapter 3, Installing and Configuring SMS 2003: With your planning and preparations in place, SMS 2003 installation is a fairly straightforward procedure. In this chapter, I describe typical installation processes for a primary site and discuss the requirements for connecting sites together in your hierarchy. I’ll cover extending the Active Directory schema, security settings, and site configuration settings. Then I’ll describe how to install secondary sites and child primary sites, as well as how to configure specific SMS 2003 server roles. Chapter 4, SMS 2003 Resource Management: After SMS 2003 is up and running, you can get started managing your SMS clients. I’ll cover accounting, fixing client health issues, and grouping clients together based on common criteria. I’ll also explain how to secure resources to allow specific types of tasks to be accessed by certain groups within your organization. Chapter 5, SMS 2003 Software Delivery and Reporting: With SMS 2003, you can do more than just group, organize, and secure resources. In this chapter, I drill through the various aspects of software distribution with SMS 2003, truly empowering SMS 2003 administrators to extend their reach to remote systems to perform tasks, install software, and execute scripts. Reporting is a key strength of SMS 2003, and I’ll discuss the various options for producing reports with current and pertinent data, through both queries and the web console.

xvii

Kruetzfeld_698-6FRONT.fm Page xviii Monday, November 6, 2006 4:14 PM

xviii

■I N T R O D U C T I O N

Chapter 6, SMS 2003 Patch Management: Essentially an extension of software distribution and inventory, update or patch management is one of the hottest and perhaps hardest-to-understand processes within SMS 2003. I’ll begin by talking about the overall strategy for dealing with Microsoft updates. Obviously, I recommend a planned approach guided by Microsoft Operations Framework (MOF) principles. Then I’ll dive into the specifics of using the Inventory Tool for Microsoft Updates (ITMU). Finally, I’ll talk about some other update management systems available for SMS 2003, focusing on performing updates on third-party software and hardware. Chapter 7, SMS Feature Packs: Since this book is really about getting the most out of your investment in SMS 2003, this chapter focuses on the Microsoft Feature Packs for SMS 2003. These free feature extensions for SMS provide great value and functionality. I’ll explain how to use the Operating System Deployment (OSD) Feature Pack to perform operating system imaging and deploy those images to systems that you manage with SMS 2003. Then I’ll take this one step further and discuss the OSD Feature Pack’s link with the Microsoft Solution Accelerator for Business Desktop Deployment (BDD), to automate the build of your initial reference image while keeping the build process documented, manageable, and consistent. I’ll also give you an overview of the other Feature Packs that have been released for SMS 2003. Chapter 8, The SMS Community: We reach perhaps the most important part of this book. I’ll show you some of the key tools available for SMS 2003 that people just like you have developed and shared. This sharing builds a sense of a virtual community, where you can find help and assistance in the form of an e-mail list or web forum. The SMS community consists of myITforum, the Blogcast Repository, AppDeploy, and numerous individuals. I’ll end this chapter with a call to action to join and form user communities to further enhance the future of SMS 2003 and its successor, System Center Configuration Manager 2007. Chapter 9, Moving SMS into Operations: Up to this point, you may have been dealing with your SMS 2003 infrastructure in a proof-of-concept, lab, or other reduced environment. Here, I’ll discuss introducing SMS 2003 to the rest of your company and keeping it healthy and functional. I’ll cover associating SMS 2003 with Microsoft Operations Manager (MOM), managing backup and disaster recovery, customizing SMS status message features, and extending SMS 2003’s inventory features. I’ll also review a few software repackaging tools that you may find useful. I think SMS 2003 is one of the best systems management products available, and the SMS community is one of the reasons for its success. This book will provide the information you need to quickly take advantage of SMS’s features and support. Check out my blog on myITforum (http:// myitforum.com/cs2/blogs/rkruetzfeld/default.aspx) for a list of the URLs mentioned in this book.

Kruetzfeld_698-6C01.fm Page 1 Monday, October 23, 2006 12:08 PM

CHAPTER 1 ■■■

Introducing SMS 2003

S

ystems Management Server (SMS) 2003 is the fifth revision of Microsoft’s product. Since it first appeared, its function and form have undergone vast changes. The 1.2 version made a big impact in the industry. It became a somewhat usable and stable, though temperamental, product. Some enterprises that invested their time and effort in this product had great successes; others were not as fortunate. SMS’s evolution to the 2.0 version marked a change in its interface, arguably a less desirable one, as the drag-and-drop functionality was removed from the product. Around the release of Service Pack (SP) 5 for SMS 2.0, it seemed that Microsoft was revising its strategy around this product, and about to launch and heavily promote SMS in the mainstream marketplace. This approach centered on releasing a stable product and increasing its feature set by offering Feature Packs as they became available. Feature Packs are free SMS add-ins from Microsoft that provide vast feature enhancements and completely new product feature sets. For example, after installing the SMS 2003 Inventory Tool for Microsoft Updates, your desktop management world will be forever changed. Imagine the ability to remotely scan for Windows-based vulnerabilities and report them to a central database. But that’s not all. You can perform query operations against them and group desktop resources based on common patch status qualities. And it doesn’t end there. You’re able to download the patches from Microsoft through a GUI and remotely deploy them against those desktops identified earlier. That’s not bad for a free add-in. Where does SMS stand now? In this chapter, I’ll start by answering that question. Then I’ll describe the basic components of an SMS implementation. Finally, I’ll suggest project planning approaches for a successful SMS implementation.

SMS 2003 Features Currently, Service Pack 2 has been released for SMS 2003. It includes all the best pieces from previous versions: its asset inventory capabilities, granular grouping via collections, and queries based on collected inventory. Also available are the previous version’s Feature Packs, such as its simple, yet effective and extensible, web reporting mechanism and its standard patch management tool set. Enter the newest Feature Pack releases: Operating System Deployment and Device Management. These two Feature Packs mark the next evolutionary stage of SMS 2003 in the marketplace, allowing greater leverage of the product in the enterprise environment.

1


2

CHAPTER 1 ■ INTRODUCING SMS 2003

Here’s a summary of the key features of SMS 2003: Asset inventory and management: Remotely gather and report desktop and Pocket PC (PPC, Windows CE, and Windows Mobile) device software and hardware inventories. By centralizing this information in the SMS database, every attribute that is reported may be used in a query or in the creation of collections of clients. Remote diagnosis and troubleshooting: Remotely provide diagnosis and troubleshooting support for SMS clients. The Remote Tools set includes remote control, reboot, file transfer, chat, and remote execution capabilities. New for SMS 2003 is the ability to integrate Remote Desktop and Remote Assistance from Windows XP, 2003 Server, and Vista clients. Software distribution: Distribute software and remotely execute files on SMS clients. This provides the ability to install and uninstall software remotely on client Windows desktop and Pocket PC systems. These software distributions may happen in one of three user contexts to allow administrative-level installation with a domain account or using the local system context, or with user-level access. Software metering: Track application usage on SMS clients. This component has undergone a total code rewrite since its inception. Earlier versions were hardware-intensive and invasive to clients. Currently, it is lightweight and highly functional.

■Note The software metering function no longer has a feature to restrict software usage based on licensing. It is a feature missed by some, but not the majority of IT staffers who found the tasks of using this functionality daunting in previous versions. Security: Provide security around the SMS console, its reporting components, and its client-side components. You can specify highly granular role-based or user-based access. Significant changes have happened since SMS 2.0 in the way that SMS 2003 uses security accounts for its own internal operations. Use of the local system account has increased dramatically, as has the use of machine-based accounts. Web-based reporting: Access SMS inventory and operational information via Internet Information Services (IIS). This feature set is fully securable and scalable. New to SMS 2003 is the concept of dashboards, which incorporate multiple reports into a single screen that you may view. You can configure and apply permissions to these URL-based locations, and provide them to IT staff members who require specific information at a quick glance. Operating System Deployment Feature Pack: Use SMS to fully manage the life cycle of its clients. This Feature Pack allows you to capture a reference system and use Microsoft’s own imaging software from within SMS 2003 to redistribute the operating system (OS) image back to client systems. This can be done for any Windows 2000 or above OS, on desktops, laptops, and servers. Once the image is captured, it is treated like most any other SMS package, fully utilizing SMS 2003’s existing network infrastructure to transfer and redistribute the OS. Since its release, Microsoft has revised its Business Desktop Deployment (BDD) framework to include integration for this Feature Pack.

■Note The Operating System Deployment Feature Pack is fully integrated into Microsoft’s BDD Solution Accelerator. The Solution Accelerator combines a framework of best practices and scripts to enable a life cycle management program for desktop deployment within the enterprise. I will discuss these best practices within this Solution Accelerator in Chapter 7.



Device Management Feature Pack: Add many Pocket PC, Smartphone, and Windows CE–based devices to your SMS 2003 infrastructure. When you do so, you are able to perform inventory functions for both software and hardware, as well as distribute software to the devices, reflash their memory, and perform security operations on them. Being able to enforce security standards on these mobile devices is particularly important, as they often leave the safety of the enterprise environment and are susceptible to theft and loss.

SMS Components Your SMS implementation will consist of SMS sites and clients. Additionally, a key part of SMS 2003 is its use of Windows Management Interface (WMI) and the Web-Based Enterprise Management (WBEM) repository. Without these two technologies, SMS 2003 would lose much of its luster and capabilities. Let’s review these components.

SMS Sites When you hear the term sites, you may automatically think of Exchange sites or Active Directory sites, depending on your background. SMS offers yet another version of what is meant by the term. SMS sites are the definition of the resources that SMS manages. These resources may include computers, users, groups, and other network-based resources. You define an SMS site by using an Active Directory site, essentially a grouping of IP subnets and servers, or by manually defining the IP subnets for the perimeter or boundaries of the SMS site. Managing the resources inside an SMS site includes the capabilities to operate and report via remote control, distribute software, perform software and inventory operations, and track application usage by SMS clients. By being creative and planning effectively, you can set up SMS sites that allow you to effectively manage your enterprise. A minimal component that your organization will need is the primary site. A primary site is an SMS site that contains a SQL Server database. Client systems are assigned to be managed by a primary site. You may also set up one or more secondary sites. Unlike a primary site, a secondary site does not have a SQL Server database associated with it. A typical SMS site includes the site server and site systems, as described in the following sections.

SMS Site Server An SMS site server is the Windows-based server on which SMS 2003 resides. You will install SMS to a specific machine that will serve as the site server. The following are the prerequisites for a site server: • Windows 2000 Server SP2 or above • Either Windows NT 4 Domain or Active Directory 2000 or above

■Note

These site server prerequisites are accurate for the Release to Manufacturing (RTM) version of SMS 2003. SMS 2003 SP2 requires the use of Active Directory 2000 or above in your environment. The SMS site will require access to a SQL installation. Typical best practices dictate that the SQL database should reside on the same server as your SMS site server. Your SQL installation will typically be SQL Server 2000 SP4; SQL Server 2005 will also work with SMS 2003 SP2.

3


4


■Note There are only special cases where it is recommended to have your SQL installation on a separate server. These include when you have a high number of managed clients—typically in the 100,000 client range—and where access to the SQL server is served by a high-speed, low-latency link. SMS Site Systems and Roles An SMS site system is essentially a server that has an SMS service, referred to as a role, installed on it. You may add or remove these roles from any member server that meets the prerequisites. A variety of roles may be assigned to other member servers on the network. The assignment of these roles depends greatly on the overall architecture and total client workload of your SMS 2003 site. The SMS site server’s hardware must be capable of handling the load of the additional role being assigned to it. Most SMS site roles require IIS 5 or later as an OS component. The SMS site roles are as follows.

SMS Client Access Point (CAP) The role of the CAP is to provide an interface for SMS Legacy Clients to communicate with the SMS site server. The Legacy Client sends inventory, status, and discovery data to the site server via the CAP. The client receives SMS package and program information, along with a list of distribution points, and the scheduling, or advertisement, information needed to install or execute the package and program. The SMS Advanced Client does not interact with CAPs, nor does it require their existence. (Both the Legacy Client and Advanced Client are described in the “SMS Clients” section later in this chapter.) The CAP role does not have any special prerequisites other than the host OS. Note that your SMS 2003 infrastructure must contain at least one CAP, even if you do not intend to use the Legacy Client.

SMS Distribution Point (DP) The role of the DP is to provide the SMS clients with a location to receive SMS packages and programs. DPs are typically distributed throughout a network to move package data closer to clients, ideally to prevent the necessity of installing or executing installations or scripts over busy local area network (LAN) or wide area network (WAN) links. New to SMS 2003 is the implementation of Background Intelligent Transfer Service (BITS), a component of IIS, which allows the SMS Advanced Client to transfer data from the DP using the following specialized abilities: • Checkpoint/restart allows interrupted data transfers to resume where they left off, eliminating the need to completely restart the data transfer. • Idle bandwidth usage monitors the usage of the local network card and schedules data transfers accordingly during idle periods on the local network segment.

■Note Idle bandwidth usage is a commonly misunderstood feature. BITS will not determine the slowest bottleneck in a path between the client and DP server, nor will it throttle the data transfer to accommodate the slowest link in between those points. You may manually throttle BITS via a Registry entry or Group Policy. Take a look at the MaxInternetBandwidth policy. It will allow you to centrally manage the background bandwidth consumption to a specific kilobits per second value based on time of day. You can find more information about controlling BITS via Group Policy at http://windowssdk.msdn.microsoft.com/en-us/library/ms677342.aspx and http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mnginfra.mspx.



SMS Management Point (MP) and Proxy Management Point (PMP) MPs provide a point of communication for Advanced Clients. Advanced Clients receive their information from MPs in the form of XML policies that contain all relevant operational, configuration, package, and advertisement data. MPs require the presence of IIS in order to service Advanced Client requests for policy updates. MPs are supported only in primary sites, as they require access to the SMS database. Only one MP may exist in a primary site. A PMP may be assigned in a secondary SMS site. This PMP will support Advanced Clients that exist within the secondary site boundaries.

SMS Server Locator Point (SLP) An SLP is used during the client installation process. During installation of the client, it provides site assignment information to Advanced Clients, locates CAPs for Legacy Clients, and finds MPs for Advanced Clients. An SLP requires IIS to function correctly.

■Note

In SMS 2003, the Server Locator Point replaces the Login Point role from SMS 2.0. This greatly reduces the requirement of SMS-related network traffic to and from the domain controllers.

SMS Reporting Point (RP) The RP provides access to the SMS web reports. It communicates directly with the local SMS database. Since it requires access to an SMS database, a RP can exist only within a primary SMS site. Naturally, to support web reports, IIS is a required component.

SMS Clients An SMS client is any server or workstation that is managed by an SMS site. This would include any desktop, server, laptop, or other portable device. Two types of clients exist within SMS 2003: Legacy Client: The traditional SMS client that was used with SMS 2.0. The Legacy Client is typically used during migration scenarios, and/or for older Windows OSs that do not support the Advanced Client. Chances are that if you are setting up a new SMS 2003 environment, you will not use the Legacy Client. Advanced Client: The new SMS client with an advanced feature set. The Advanced Client leverages Active Directory and communicates with MPs, SLPs, RPs, and Active Directory. Table 1-1 shows which Windows OSs support the Advanced Client.

■Note

Microsoft’s initial intention with the Advanced Client was for it to be used primarily with mobile clients (and initially named it the Mobile Client). The Advanced Client worked so well for both mobile and stationary machines that it was chosen as the preferred SMS 2003 client by the time SMS 2003 was released.

■Note

With the release of SMS 2003 SP2, the support for Windows NT and lower was removed, as well as the support for the Legacy Client.

5


6


Table 1-1. Operating System Client Support

Operating System

Advanced Client

Legacy Client

Windows 2003 Server, all editions

Yes

Yes

Windows XP Professional

Yes

Yes

Windows 2000 Server, all editions

Yes

Yes

Windows 2000 Professional

Yes

Yes

Windows NT Terminal Server

No

Yes

Windows 4.0 Server, Windows NT 4.0 Workstation; SP6a or later

No

Yes

Windows 98

No

Yes

WBEM and WMI WBEM is a public initiative that unifies the standards of enterprise computing environments. WBEM delivers a set of standardized management tools that are related to XML. The Desktop Management Task Force organization has developed a code set of standards that make up the data model and Common Information Model (CIM) standard. So really, what is WBEM? It’s an open standard to allow vendors and manufacturers to work on a common basis for providing data about hardware and software. This information is kept in a database known as a repository. How does WMI fit into this? WMI is the technology that allows scripts to monitor and manage resources through the network and in the WBEM repository. Some resources may be hardware-related, but others may be event logs or event-based types of data. WMI is found on Windows 2000 and above, but it can be installed on any 32-bit Windows client. SMS 2003 is able to leverage these resources for its own operation and inventory purposes. Scripts are able to trigger SMS events via WMI, and SMS is able to pull inventory information from client systems’ WBEM repositories via WMI. These capabilities and close integration with these two related technologies empower SMS 2003’s management features greatly.

■Note For more information about WMI scripting, I recommend Windows Admin Scripting Little Black Book by Jesse M. Torres (ISBN 1-57610-881-3). It is a valuable resource in providing scripted solutions to various scenarios. Also see the WMI Scripting Primer from Microsoft at http://www.microsoft.com/technet/scriptcenter/ guide/sas_wmi_overview.mspx?mfr=true.

SMS 2003 Project Planning Approaches Before implementing SMS, you should determine the scope of what you are trying to achieve. This will allow you to set a goal, so you have a good indicator of your progress and success. Perhaps the most important piece in executing a successful implementation of SMS 2003 is planning. I advise that you “plan twice; implement once.” Plan twice you say? Yes, by this I mean that you should perform your planning in two phases: proof of concept (POC) and pilot. By planning twice, you should have anticipated most variables that will present themselves during implementation and developed recovery solutions for the issues you encountered.



Documentation As you work through your POC and pilot phases, you should be documenting your progress in several ways. You should be keeping an as-built document to track what you have installed, where you have installed it, and any other Windows OS-based configurations and additions you have made. You may later be able to use this document for disaster recovery planning activities. The as-built document typically contains screenshots, responses for prompts, installation locations, and hardware configuration information (disk sizes, partition allocation, RAID configurations, and general server sizing information). As you perform configuration operations on SMS 2003, you should be documenting these settings and alterations as you make them. This is particularly useful in diagnosing what you may have done to an SMS site to either improve its performance or to break it. I like to keep these types of changes documented in a spreadsheet with columns describing each change as it is performed. Other configuration changes that should be recorded are creating Active Directory user groups, setting permissions, and adding or removing user/service accounts. When creating and altering SMS packages, you should keep a log of these additions and changes to ensure that other staff members are able to understand their function and operation. When you create or edit SMS web reports, you should again document these changes, indicating which reports were affected and what was changed.

POC Phase First, perform a POC. This gives you some level of experience with the product and allows you to experiment. You can roll back the implementation and try it again until you have it installed and operating to your satisfaction. Perform your POC activities in a lab environment. Don’t be tempted to do this in production. SMS 2003 is a powerful product and can easily be set to assume that clients are live on your network. Unintentionally doing so can make you very unpopular. The POC will allow you to validate the operation and features of SMS 2003 to your satisfaction, and perhaps more important, demonstrate these to the management staff who are supporting your project financially. You have the opportunity to explore various configurations of the product and make some decisions on how it will be installed in your pilot. Remember to document your configurations at this point; doing so will provide some insight later as to how you arrived where you are. While you have a POC environment created, you should start creating a test plan. A test plan will allow you to validate that an SMS site is operating as expected, proving that your setup of a site is correct and as expected. You should choose operations that are key to SMS 2003, including the following: • Active Directory discovery cycles • Collection creation and population • Software package creation • Package advertisement and delivery to a client or small group of clients

Pilot Phase As the second stage of planning, set up a pilot implementation of SMS. This will give you the opportunity to apply what you learned in the POC in a real-world scenario. A key step in planning and implementing a good pilot is the choice of pilot candidates. Choosing clients that are understanding and have some level of technical knowledge or comfort is best. Depending on your corporate environment, you may choose to include or exclude individuals who may be hard

7


8


to win over. Include them to instill confidence; exclude them to reduce the opportunity of issues clouding their enthusiasm. Your target pilot environment should be based on about 10% of your environment. (For very large environments, adjust this number to suit your project planning office’s requirements.) This 10% should be an accurate cross-section of your intended deployment scope. Be sure to include all ages and types of systems into this pilot scope. These clients should be reflective of typical systems you will encounter during your deployment.

Summary This chapter provided an overview of SMS 2003 features, and then described the basic components of an SMS implementation. You learned about the roles that you may assign to systems in your environment to make up your SMS hierarchy, as well as the two types of SMS clients, the Legacy Client and the Advanced Clients. Finally, I suggested project planning approaches, including how best to plan POC and pilot phases in order to reduce the risk associated with change to your environment. The next chapter covers the details of planning your SMS 2003 implementation, including how to plan for capacity using Microsoft’s Capacity Planner for SMS 2003. Other topics include Active Directory factors, network considerations, server configurations, and client considerations.


CHAPTER 2 ■■■

Planning Your SMS 2003 Implementation

S

uccessfully implementing SMS 2003 requires careful planning and making several up-front design decisions. Before proceeding with your installation, you need to consider some important issues, make several design choices, and be able to answer a few key questions. Otherwise, you may be left mid-operation wanting to roll back your implementation. This chapter will help you answer the following questions: • Should I perform an upgrade or new installation? • How will I know if my design will handle the intended client load? • What server hardware do I need? • What Active Directory issues do I need to consider? • How will my network handle the load? • How should SQL Server be configured to work with SMS 2003? • Which method should I use for SMS client discovery? • What do I need to consider for multiple-site configuration? • How will I configure my SMS site boundaries and client roaming?

Upgrade or New Installation? One of the first questions you will be facing is whether to perform an upgrade or new installation of SMS 2003. Each method has its advantages and disadvantages. By performing an upgrade of your existing SMS infrastructure, you can easily transfer the entire site configuration to your new SMS 2003 site, retain and migrate the SMS clients at your leisure, and preserve your existing SMS database contents. However, with an upgrade, you may need to contend with SMS configuration issues that currently exist, SMS 2.0 clients that may not be responding, and potential database corruption issues that may be carried forward. You may mitigate those issues to some degree by being proactive in your management of your site, ensuring your SMS clients are healthy and responding correctly, verifying your SMS site configuration, ensuring you understand what settings you have and why, and performing database consistency checks on your existing SMS database. Typically, in practice, I have seen poorly implemented SMS 2.0 sites that are abandoned in favor of starting fresh with SMS 2003. Generally, this is a good idea.

9


10

CHAPTER 2 ■ PLANNING YOUR SMS 2003 IMPLEMENTATION

When performing an SMS 2003 upgrade, you typically start at the top level of your SMS hierarchy. If you have just a single site, this is easy. Multiple sites that have child sites are significantly more complex, but can be handled with the same approach. When you have a larger-sized SMS hierarchy, your design considerations are more likely to change when moving to SMS 2003 due to the software’s architectural changes. Before upgrading, you must first execute the Deployment Readiness Wizard on every site that you will be upgrading to SMS 2003. This wizard will assist in preparing your site for the upgrade process by checking for common errors and reporting them. If you have older clients that are not eligible to be upgraded to SMS Advanced Clients, you may want to consider a holding site as an option. A holding site is an SMS 2.0 site that will allow you to maintain older Windows clients until they are able to be upgraded to a Windows platform that will support the SMS 2003 client. If you choose to perform an upgrade and you have new hardware for your SMS site, you may be able to do a side-by-side upgrade. If you don’t have new hardware, you will need to perform an inplace upgrade. Let’s look at both types of upgrades, and then review the documentation you should maintain for SMS installation.

Side-by-Side Upgrade You may have new hardware available for your use in the new SMS 2003 site. An easy way to incorporate this into your upgrade process is by performing a side-by-side upgrade. The basic concept of this type of upgrade is that you will retain your existing SMS site, and build a new SMS 2003 site and assign it as a parent to the existing SMS 2.0 site. By adding it as a parent site, you can transfer clients and SMS database information to the new site. Note that you need to take a couple of precautions with this approach: • You will be assuming some additional complexity in handling two SMS sites. Any existing help desk or other staff members who are accessing clients via the SMS console will need to be aware of this change and locate clients accordingly at the new site. • When the connection is made between the two sites, the existing SMS site will be compelled to transfer its database contents upward to the parent primary SMS 2003 site you created. You may want to be sure that you create some restrictions on the senders (network links) when connecting to the new SMS 2003 site from the older SMS site, and/or perform this operation during off-peak hours. Needless to say, don’t do this to two sites across a small or saturated WAN link during peak business hours. Once the connection is made and you are able to access clients from the new SMS 2003 site, you can swing the site boundaries over to your new SMS 2003 site, effectively moving the clients from the old site to the new SMS 2003 site. At this point, you may start your SMS client upgrades from the Legacy Client to the new Advanced Client. I will discuss Advanced Client deployment options in Chapter 3. Once your clients have been moved to your new SMS 2003 site, and your database has pushed its data to the SMS 2003 database, you may decommission the old SMS site. Note that you need to do this correctly—it is not as simple as just turning off the old site. Chapter 3 covers removing SMS 2003 sites.

In-Place Upgrade If you do not have new hardware available, your options are significantly more limited. If you deem your existing hardware capable of operating the new SMS 2003 site, you may perform an in-place upgrade on it. By simply upgrading your existing SMS site to SMS 2003, you can preserve all settings and database contents.



This is a simple yet effective method. Unfortunately, it poses restrictions on incorporating new hardware for your SMS 2003 site. There is also a point of no return when you perform this type of upgrade. During the upgrade, significant portions of the SMS site code are altered or deleted, so it is difficult to roll back to the previous state gracefully. If you cancel the upgrade, your existing SMS site may be left in an unusable and unrecoverable state. If you have made any unique configurations, like customizing the SMS_def.mof file, you should preserve a copy of the affected files before performing the upgrade, as they will be replaced during that cycle. Also be aware that site settings such as status message rules, agent settings, tasks, and so on do not transfer their settings across to your new site, so you will need to make those alterations yourself. It may be a good time to examine some of those settings to make sure they make sense in your new environment. As always, perform adequate backup operations before proceeding with any type of upgrade or major change activity.

Installation Documentation A commonly overlooked area is the documentation of the installation process, including the settings that you may have configured. I recommend performing the operations in a lab environment that resembles your production model to the extent possible. By performing these actions in the lab first, you are able to validate your installation or upgrade process, ensuring it is producing the results you intended. While you are performing this mock installation or upgrade process, you can document the steps you are taking to get to your desired state. I am a big fan of screenshots. I snap screenshots and paste them into WordPad. It may seem pretty basic, but it gives you an idea of what was set and how it looked at each step. Other staff can also understand these types of documents.

■Tip

Several commercial tools make it easy to capture screenshots. One of my favorites is Screenshot Captor (http://www.donationcoder.com/Software/Mouser/screenshotcaptor/index.html). This product is free to use and has plenty of useful features, yet comes in a lightweight package. Pretty screenshots are not enough, though. You need to document which domain accounts are used, passwords, and relevant settings information. In a text document, I note any settings that I’ve changed from the default, if for no other reason than the document may be easier to read than a screenshot; for example, it’s easier to tell that O from a 0. I recommend creating a few different documents when performing an installation or upgrade. First, a design document will show you how the site should be laid out when you are finished. Document all the sites that are going to be affected, their network link details, and the numbers and types of clients at each site. Create a capacity planning document to document the planned capacity usage of various resources. You will need to include some base assumptions: hardware and software inventory intervals and details, frequency and size of software distributions, and other variables. When starting from scratch with a new installation, it is difficult to tell if you will need to vary from the default values for these options, plus changing them will affect your overall design considerations. For example, a higher frequency of inventory cycles has the potential to increase storage requirements, CPU requirements on the server, network traffic quantities, and client system CPU usage.

11


12


Capacity Planning Microsoft has been kind enough to create a tool, called the SMS 2003 Capacity Planner, that will assist you in designing and sizing your SMS 2003 site hierarchy. This tool is useful not only for large, complex environments, but also for simple single-site implementations. It produces trafficconsumption calculations based on many configurable variables. You can download the SMS 2003 Capacity Planner (did I mention it’s free?) from http://www.microsoft.com/downloads/ details.aspx?familyid=009e0c30-bded-4b95-a8f9-06037de85c57&displaylang=en.

■Note

The SMS 2003 Capacity Planner is written as a Microsoft Excel Workbook. You will need to enable macros to allow the tool to function correctly. The operation of the Capacity Planner can be broken down into four basic steps. Each of these represents a unique phase in the planning and layout of your SMS site and the operational assumptions: Topology: In the first step, you will break down your physical network layout and insert it into the worksheet. You input the number of clients and also the appropriate WAN/LAN information for the associated location. Each line will represent a separate location. Assumptions: In the second step, you check the assumptions that have been predefined by the Capacity Planner. Various features of SMS are represented here, with sizes and frequencies of these functions. Unless you know that you will be increasing the frequency of inventory cycles or performing larger software distributions, you may want to leave most of these values at their default settings. Analysis: In the third step, an Excel worksheet analyzes the topology and assumptions made in the model. After initiating this analysis process, you will be presented with a dialog box asking you to choose a configuration to represent the edge system, or SMS component, at this location. The edge system may range from none all the way up to a full SMS primary server. You will need to perform this operation for each location. Output: In the last step, the Capacity Planner will present you with the output of an analysis for your unique topology. It will present hardware suggestions and give you an estimate of the hardware configuration you may require to operate the given site topology. Since hardware performance is always evolving, I suggest using the suggestions and estimate as minimum standards. Before getting started with the Capacity Planner, consider using the preplanning worksheet from the Scenarios and Procedures for Systems Management Server 2003: Planning and Deployment document (available as a Microsoft download from http://www.microsoft.com/downloads/thankyou. aspx?familyId=E0644BB4-2336-4254-8A18-9BC180713F7E&displayLang=en&oRef=http%3a%2f%2fwww. microsoft.com%2fsmserver%2ftechinfo%2fproductdoc%2fdefault.mspx). This Excel worksheet helps you identify your physical sites and key configuration parameters for each. Once you’ve completed the preplanning worksheet, it’s fairly easy to transfer the data into the Capacity Planner. The following sections describe the Capacity Planner steps in more detail. I will assume that you have gone through the discovery steps of completing the preplanning worksheet, or at least have created a table of similar data about your organization.

■Note

The Capacity Planner comes with a nice user guide that you should read to fully understand its operation.



Topology Start the topology build process by clicking the Build Topology button in the Scenario Analysis worksheet of the Capacity Planner. You will be presented with a Topology Entry Form dialog box. When defining your physical layout, you should start at the center of your organization. This will be considered your central site and also your top tier. Figure 2-1 shows an example of a completed Topology Entry Form for a central site. Any site that connects directly to this site will be considered a tier below, or second tier.

Figure 2-1. Topology Entry Form for a central SMS site The key to successfully re-creating a topology is to preplan it for your site locations. This enables you to enter a valid value for the number of unique child location types. For example, in Figure 2-1, I’ve specified five unique child sites. This value gives the Capacity Planner an indication of how many sites you will be defining, and when to end the Topology Entry Form. You continue defining other locations and their configuration data. Each location that you define should represent a physical location in your organization. Each location is typically connected by network links and contains some number of clients. Figure 2-2 shows the last Topology Entry Form for the topology with five child sites I started in Figure 2-1. In some cases, large organizations may have thousands of locations to enter. In this case, the task of entering data manually would be overwhelming. To avoid this, you can assume generalized parameters about groups of locations, such as the network link size and number of clients to be serviced. By making these assumptions, you can create multiple sites by specifying the number of locations like this in the given tier level.

■Note You will likely not go further than third or fourth tiers in most large organizations, as SMS architecture is optimized for a flatter architecture. For more information on this topic, review the Systems Management Server Concepts, Planning, and Deployment Guide, available as a download from Microsoft (http://www.microsoft.com/ downloads/details.aspx?familyid=784838B3-34E0-4122-B3E2-17C5B4EEF8F4&displaylang=en).

13


14


Figure 2-2. Topology Entry Form for the final site An alternate strategy you may consider is to group your clients logically by service rather than by physical location. You still need to enter network link information, but the result will be an alternative logical SMS site configuration that may better serve your unique needs. After entering the values, you can go back and alter these values in the Capacity Planner to perform some what-if or growth scenarios.

■Tip

When I perform the topology step, I tend to do it in two phases: first to represent the existing WAN/LAN configuration and client numbers, then a second time in another sheet to represent aggressive growth for three years in the future. This gives me a better idea of what the existing capacity is and allows me to project growth. The Topology Entry Form has several fields. Some of the field labels are somewhat cryptic at first glance. Here’s a brief description of each field: Location Ref: An internally generated value that is used to keep track of your topology configuration. Don’t change this value. Parent Location Ref: Like the Location Ref field, an internally generated value that you shouldn’t change. Location name: A name for the physical or logical location you are defining. You can use any naming convention that makes sense in your environment. Number of Locations like this: If you have multiple locations in this tier that match this configuration, enter the number of them here. If there is only one location like this in the current tier, enter 1.



Link with Clients (Kbps): The speed of the LAN connection between clients and their potential site server. Typically, the value used here will be 10Mbps or 100Mbps (1024Kbps or 10240Kbps). If this represents a virtual private network (VPN) location or grouping, enter the estimated speed of the VPN link, using the lowest potential speed (56Kbps is likely). Link with Parent (Kbps): The speed of the link with the parent location, or WAN link speed. Again, these values are in Kbps. This value will be used with the calculation in the next field to calculate the available network bandwidth between SMS site locations within the topology. % of Parent Link allowed for Mgmt: Typically, the amount of bandwidth that is acceptable for SMS to use. You may think of it in two ways: either the WAN utilization that SMS is permitted or the amount of bandwidth available for SMS to use, calculated as the available bandwidth (with any line-of-business traffic subtracted). Local Admin Present: If you have IT staff at the location who may help maintain the potential SMS site, enter Yes in this field; otherwise, enter No. If you do not have IT staff resources at this location, you should consider not having a primary site located there, as all maintenance will need to be provided remotely. No. of Clients physically at this location: The number of SMS 2003 Advanced Clients that will be located in that physical or logical location. If you are defining a central site to be used strictly for management, enter a value of zero (0). No. of unique child location configurations: The number of sites you are considering. The Capacity Planner will require a Topology Entry Form to be filled out for each child location specified here. In the example in Figure 2-1, I entered a value of 5, for five unique sites to define and later analyze. After you fill in the last Topology Entry Form, you will be presented with an Excel worksheet with all the site configuration information compiled. You can make changes at this point. It is prudent to save a copy of the worksheet before making any further changes.

SMS Site Assumptions The Capacity Planner makes some assumptions about how you will use your SMS hierarchy. These base assumptions are a good starting point, but you can tailor them to suit your unique requirements. Click the Assumptions button to go to the Assumptions worksheet. You may toggle on and off features of SMS 2003. The assumptions are divided into two sections: basic and advanced. By default, the tool assumes Inventory, Software Metering, and Software Distribution are enabled in your environment. You may alter the size of your large application deployments and their frequency to suit your environment. One aspect that is not reflected in here is how to use the SMS Operating System Deployment Feature Pack. I tend to adjust the large application size upward to compensate for this.

■Note

If you feel that the use of the SMS Operating System Deployment Feature Pack is an important calculation, or would like to see any other feature enhancement, drop a note to [email protected]. Let’s look at few basic assumptions that are being made about the site and why you may want to alter their values.

15


16


Roaming Clients Percentage: Make sure that this value is truly reflective of your client environment, as roaming clients pose a significant impact on an incorrectly configured SMS hierarchy. (Roaming clients are discussed in the “SMS Advanced Client Roaming” section later in this chapter.) The default value is 10%. Your value may be significantly different. Policy Distribution Cycle: Be sure to adjust this value to suit your intended environment. The default is 60 minutes. If you use a higher value, it will increase the client’s network traffic and load on your Management Points (MPs). Adjust the percentage of the Clients Going Through Re-imaging/Redeployment setting to a value that suits your environment. If your environment experiences frequent rebuilds of desktop clients, those systems will be requesting policies and advertisements at a higher rate. Also consider the impact SMS Operating System Deployment Feature Pack imaging activities may have. Inventory: I typically leave the Inventory values alone, other than the Software Inventory File Collection values. If you are implementing the Microsoft Application Compatibility Toolkit 4.01, you should configure these values to reflect the fact that it uses file collection to perform its activities. If you have any other plans for file collection, be sure they are reflected here. Software Metering: I suggest leaving this value alone. How the default was calculated is not well documented. Adjusting it may cause unexpected results.

Site Analysis Clicking the Analysis button will take you to the analysis process. This task involves assigning site server roles to each location you defined earlier. (Server roles are described in Chapter 1.) You have multiple options, with representative bandwidth consumption details for each. In some instances, particular roles may not be suitable or available (such as a primary site where there is no IT staff to maintain it). If you click the Details link for a particular role, the calculated traffic summary is displayed, along with a breakdown of what type of traffic is being generated with the role selected for that location. By examining these values, you may find a different role may be more suitable for the given location. For example, an effective method to reduce software distribution traffic over a WAN link is to assign a Distribution Point (DP) role to that location. Not having a DP may result in a parent link usage of more than 18%. By adding a DP role to that location, you can reduce the parent link traffic to 0.94%. That’s a huge change, achieved just by dedicating a DP to that location. You may analyze all sites consecutively by clicking the Analyze All Locations button. To reanalyze a single site, click the Analyze a Single Location button.

■Note

You cannot perform analysis against an edge system, such as a top-tier central primary site.

Output The Output section of the Capacity Planner provides some basic insight into the level and configuration of the hardware required for your SMS 2003 hierarchy. This is pretty basic information, but it should give you some minimum requirements and confirmation that your specific hardware will be enough to support the intended client load and configuration. Here are a few key items you need to consider:



RAM: Make sure that the amount is enough for SQL Server to run comfortably along with the host OS and IIS. (RAM requirements for SQL Server are discussed in the “SQL Server Considerations” section later in this chapter.) Disks: Make sure that the disks are properly configured for use with SQL Server and for software package storage. (Disk requirements are covered in the next section.) Network card: Make sure that enough bandwidth is available to support client requests for software packages and policies. Backup media: Make sure that you have an appropriate mechanism in place to support the disk volumes that require backup. Depending on your environment, the backup requirements can be fairly large. OS images alone can consume considerable space, plus you need space for the existing SQL Server database and other software package requirements. Be sure to allow for future expansion and growth.

Server Hardware Before you proceed to order your server hardware based on the results of the SMS 2003 Capacity Planner, you should carefully consider what you are buying. As always, try to stay with your normal buying practices for hardware. Try to buy into the same model line as other servers that you support in your environment, staying within the sizing confines as outlined by the Capacity Planner. Key components of the server design are the physical disk array and partitioning layout. Memory and network connections are also important.

Drive Array Distribution By correctly configuring disks for use in your SMS server, you can optimize performance of SQL Server and SMS. Keep your OS on a separate logical drive; you may share this disk with other logical drives. When configuring drive arrays, be sure to account for an internal drive array and an external drive array. You have limited physical space within your internal array, so be sure to design your disk sizes accordingly. If I am designing a server for a mid-sized to large SMS site, I typically use the following design (assuming a six-disk internal array): • The first two disks are set up as a mirrored pair called array A containing the OS (C), and SMS/SQL Server application (D) installation volumes. • The remaining four drives are set up as a RAID 5 array B and will have several logical drives containing the backup OS (E), utilities (F), and SMS’s SQL database (G). This configuration allows for growth of SMS’s SQL database, plus it has the benefit of four spindles in rotation for fast random disk access to the SMS database files. Since this example is for a larger installation, I would use an external cabinet to house additional drives. The external cabinet would be physically set up as follows: • The first two disks as a mirrored pair, array B, containing the SQL database transaction logs • The remaining five drives as a RAID 5 set with a single logical drive, array C, containing the desktop OS images and SMS packages Of course, the size of the disks used and the exact parameters of the logical drive created depend on your specific needs and anticipated growth pattern. Be sure to size array C appropriately to allow for multiple OS images, along with a large selection of software packages.

17


18


Server Memory Configuration You should be sure to size the server’s memory configuration appropriately for the size of the SQL database that you expect to be using. Add an allowance for growth and some spare space. With the low cost of RAM, typically 2GB to 3GB is more than sufficient for most applications. A switch that you can use with systems that contain large amounts of RAM is /3GB. This switch changes the way that 4GB of virtual address space is split up. Normally, that address space is split into 2GB available as user mode virtual address space and 2GB available as kernel mode virtual mode address space. The /3G switch changes this allocation to 3GB to the user space and 1GB to the kernel space. If you system contains 4GB or more of RAM, I recommend using this switch, as it will increase the amount of user mode address space available. Normally, reducing the amount of space available to the kernel can seriously affect disk caching and the ability of various components to allocate memory, likely reducing the number of asynchronous I/O operations that can be pending. However, for the Microsoft Exchange Information Store service and SQL Server, making this change can be worthwhile because these applications do a lot of their own disk buffering and unbuffered I/O to their transaction logs (for example, Microsoft Exchange Server’s Store service writes the entire content of every message to the transaction log before storing it in the appropriate database). You can set the /3GB switch by editing the Boot.INI file and adding the /3GB switch to the end of the line: Multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=.../3GB

■Note For more information about configuring SQL Server and Windows Server for use with large memory configurations, see the Microsoft TechNet article “How to configure SQL Server to use more than 2GB of physical memory” at http://support.microsoft.com/default.aspx?scid=kb;en-us;274750&sd=tech#kb1.

Network Connections Since your SMS site server is likely to be talking to a wide variety and number of clients, it makes sense to place it where it is well connected to the bulk of your clients. Try to ensure its network connections are at a core switch or router. You may decide that network load balancing, rather than failover, is good strategy to follow for your server’s network links. As a minimum requirement, be sure to have two 100MB links available for your SMS site server. Gigabit network media are even more optimal, as many large data transfers between your SMS site server and clients may be in progress at any time. You may mitigate some of this loading effect by distributing the SMS site server roles to other servers in your organization. Be aware of the anticipated load on both the server and its network connections when doing so. Commonly, several DPs are configured for mid-sized environments. This is a convenient way of offloading some network traffic from your SMS site server and provides resiliency of key SMS services to your clients.

Active Directory Considerations One of the significant changes with SMS 2003 is its close tie to Microsoft’s Active Directory services. SMS is able to leverage Active Directory’s security, infrastructure, configuration, and publishing properties. But this also means that your Active Directory services must be in a good state of health before you proceed with an SMS 2003 implementation.

280aa1c0665713200c861a92cb98f9d2



Active Directory sites differ from SMS sites. An Active Directory site is essentially an area of a well-connected network, defined by subnet(s). There may be a single Active Directory site in a simple organization or multiple Active Directory sites in a more complex environment. SMS 2003 uses your Active Directory site names or subnets to determine its SMS site boundaries. Optimally, Active Directory site names are used because they will reduce administrative overhead in maintaining the Active Directory site/subnet/SMS site relationship. Clients are assigned to SMS sites based on their IP subnet or Active Directory site name. SMS 2003 will determine if a client is assigned to its site based on the client’s IP subnet and/or Active Directory site membership.

■Note

Often, I see Active Directory sites still named with their default name and obviously set up with no thought given to design and implementation requirements. These default sites typically don’t have replication set up correctly and may be experiencing degraded performance. If there is any doubt about the soundness of your Active Directory architecture, you are well advised to seek professional services to perform an evaluation. Before proceeding with the installation of your SMS 2003 hierarchy in your production environment, you should ensure your Active Directory services are in optimal condition. You may not be experiencing any apparent issues, but a health check may show some configurations that should be altered to optimize the performance of your Active Directory service.

Active Directory Health Check Microsoft provides some key tools that you can use to check the health of your Active Directory services: DCDiag, NetDiag, and ReplMon. These are available as free downloads from the Windows 2000 and 2003 Support Tools. Be sure to download the appropriate version for your Active Directory installation. For Windows 2000, get the tools from http://support.microsoft.com/kb/265706/EN-US. For Windows 2003, download the entire Windows 2003 SP1 Support Tools from http://www.microsoft.com/downloads/ details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en. DCDiag is a command-line tool that checks the state of your domain controllers. Table 2-1 lists some of the more commonly used DCDiag command-line switches.

Table 2-1. Some DCDiag Command-Line Switches

Switch

Description

/?

Displays additional help and command-line options.

/v

Produces verbose test results.

/q

Shows only errors resulting from the test. This may be useful if you use this tool as part of a scripted health check.

/s: servername

Allows you to specify a specific domain controller to test against.

/fix

Fixes server principal name (SPN) issues.

/f:logfile.txt

Similar to the fix option, but outputs the results to a file. Again, you may use this in a scripted health check.

/test:testname

Restricts the tests to the specified and mandatory required tests.

19


20


NetDiag, another command-line tool, gives you invaluable insight into the world of your network connectivity issues. Use it to ensure connectivity between servers, check VPN tunnels, and look for Domain Name Service (DNS) server connectivity issues. Table 2-2 lists some of the more commonly used NetDiag switches.

Table 2-2. Some NetDiag Command-Line Switches

Switch

Description

/?

Displays additional help and command-line options.

/v

Displays verbose results for the tests being run with details on the network cards and their bindings.

/Debug

Displays an even more verbose output than that produced by the /v switch.

/q

Displays a much smaller return of results while showing issues that were detected. You may want to use this switch after you are overwhelmed by the large amount of results from the /v and /Debug switches.

/test:testname

Restricts the tests to the mandatory tests.

Although Windows 2003 Active Directory has changed slightly from Windows 2000 in the areas of latency and replication performance, the principles of replication have been maintained. Using ReplMon, you can check the replication health for your Active Directory services, and you may be able to identify and resolve issues surrounding replication. You can force replication and observe the results, optimize replication links, and find trust relationship issues between domains or forests. Unlike the tools previously discussed, ReplMon provides a pleasant GUI. One of the unique aspects of ReplMon is that it illustrates how your directory replication works within the network and Active Directory topology.

Active Directory Computer Account Cleanup Another area of Active Directory health that tends to be neglected is computer accounts. Many organizations do not have formal policies regarding disabling and/or removing aged and old computer accounts that are no longer required. That’s too bad. It is a fairly easy process to implement, and really just boils down some level of housecleaning that should be taken care of by the appropriate staff. Once a system is decommissioned, the appropriate action should be taken to clean Active Directory of the newly decommissioned computer account from its organizational unit (OU) home. This decommissioning process can take several forms. In some organizations, it may involve disabling and moving the computer account to a specific OU to be deleted at a later date. Others choose to disable the account and leave it in place. Some organizations immediately remove the old computer account from their Active Directory. On the surface, computer account housecleaning may not seem to be an important issue. However, it will take on a more sinister look once you start leveraging SMS 2003’s Active Directory system discovery to find clients (client discovery methods are discussed later in this chapter). The tendency is for this discovery method to bring in old computer accounts that are no longer valid, presenting some unique cleanup issues when you push the Advanced Client out to systems that may or may not exist on the network. By cleaning up these machine accounts in Active Directory before you install SMS 2003, you can avoid this problem.



How can you identify these phantom machine accounts? One good utility that I have used successfully is called OldCmp, available from http://www.joeware.net (browse to the Windows Stuff/Free Tools section). OldCmp queries Active Directory machine accounts and identifies accounts for which the passwords have not changed in a number of days. The default assumption is that your machines registered in Active Directory will be required to change their password every 30 days. Those that have not done so may be offline or decommissioned. In your search, be sure to choose a password age value that works for your environment. If you are in an education or other seasonal business environment, for example, you may power down a large number of your desktop systems over the summer months, making them appear to not have changed their machine account passwords for 60 days. I suggest starting with a value of 90 days, which should allow for most situations. Table 2-3 lists some of the more commonly used OldCmp command-line switches.

■Caution

OldCmp can be a dangerous tool, and using it incorrectly could pose a threat to your longevity with your current employer. Be sure to choose your command-line properties correctly and perform test evaluations of your machine accounts report to ensure you are getting only machines that have been decommissioned. Test your implementation heavily,

Table 2-3. Common OldCmp Command-Line Switches

Switch/Option

Description/Parameters

Example

-b ""

Specify a start point within your domain structure.

-b "cn=users,dc=domain, dc=com"

-sort

Specify attribute that result set should be sorted by. Cn: Name pwage: Password age Age: Object age Os: Operating system Llts: Last logon timestamp

-sort pwage

-rsort

Specify attribute that result set should be reverse-sorted by. Same parameters as -sort.

-rsort pwage

-llts

In Windows 2003 Domain Functional mode domains, force OldCmp to use lastLogonTimestamp instead of pwdLastSet for aging of accounts.

-llts

-users

Work on user accounts instead of computer accounts.

-users

-report

Report on only accounts matching query criteria.

-report

-disable

Disable accounts matching query criteria.

-disable

21


22


Table 2-3. Common OldCmp Command-Line Switches (Continued)

Switch/Option

Description/Parameters

Example

-delete

Delete accounts matching query criteria; machines must already be disabled for the deletion to work.

-delete

-move

Move accounts within a domain. Used in conjunction with the newparent switch to specify where to move the accounts.

-move

-newparent "<parent dn>“

Specify the new location where accounts should be moved. This must be used with the move option and can optionally be used for the disable option if you would like to disable and move accounts.

-newparent "ou=disabled, dc=domain,dc=com"

-safety

Count how many objects to modify. The default is 10—after 10 objects, OldCmp will stop updating objects.

-safety 100

-unsafe

Perform action on all objects that match the filter.

-unsafe

-forreal

Unless this switch is specified, nothing will actually be modified in Active Directory.

-forreal

-onlydisabled

Look only for disabled objects.

-onlydisabled

-age

Specify how old the password should be for the filter to pick it up. If -llts is specified, this is how old lastLogonTimestamp should be. The default is 90 days.

-age 120

-maxage

Specify a maximum age for the password, in case you want to find password ages within a specific range.

-maxage 365

-format

Specify what output format you want to use. CSV: Delimited text HTML: Standard HTML (default) DHTML: Dynamic HTML

-format dhtml

-sh

Display the report after it is created.

-sh

-file

Name an output file to write to. The default is oldcmp-.htm.

-file old-computers

-append

Append a file.

-append



SMS Schema Extensions One of the key pieces during the installation of SMS 2003 is the extension of the schema. During the early days of Windows 2000 Active Directory services, the prospect of extending the schema was commonly perceived as a task best left to the discretion of Microsoft consulting staff. These days, extending the schema is not nearly such a serious task. It is well documented and commonly done. When you bring up the subject of extending the schema to the staff responsible for managing the Active Directory services in your organization, most likely you will be asked why you want to do this. Here are several key reasons: • If you do not extend the schema, you will require Windows Internet Naming Service (WINS) and the Computer Browser service. Most organizations are trying to remove the requirement for WINS on their network. • If you extend the schema, your Advanced Clients will support global roaming. • The schema extensions will allow for automatically updating and locating MPs and Server Locator Points (SLPs). Using WINS, only one SLP is supported. The process of extending the schema is not overly complex. The first step is the actual extension of the schema. This adds four classes and ten attributes into the schema. Following the extension of the schema is the publishing of SMS 2003 data into the attributes contained within the classes. Once published, the data is then available to any current or future SMS 2003 site in the hierarchy. Chapter 3 covers the schema extension process in more detail.

Network Load Considerations When you are designing an SMS 2003 hierarchy, you need to be aware of the network structure and its architecture. By knowing the details of the network’s performance characteristics, you will be able to make intelligent decisions regarding your SMS 2003 architecture. Your decisions will affect the overall structure, performance, and reliability of your SMS 2003 hierarchy.

Available Bandwidth Typically, one of the first items I request is a network map. This map should contain details of the physical locations, their associated network links (both internal and external facing), and the expected client numbers at these locations. If available, network bandwidth usage graphs are useful, too. These can allow you to perform some simple analysis to determine the high-consumption times and when to avoid placing additional load on the network from SMS-based activities. When requesting network bandwidth usage graphs, I suggest that you look for the following: • A graph for a day (perhaps 24 hours of a mid-week day) allows you to see spikes in utilization that may occur on a daily basis (you may be surprised at how busy your network is at night!). Inspecting your daily utilization levels will give you the most benefit in creating sender limits and schedules (senders are discussed in the “SMS Site Communications” section later in this chapter). • A weekly graph will give you further insight into any other activities that may take place and allow you to see some trends in evening/night bandwidth use. • A two-month graph will allow you to see any trends of month-end activities. By determining the available bandwidth, you can make comparisons against the loads calculated by the SMS 2003 Capacity Planner. These numbers will give you a fairly accurate estimate of the impact that you will see on the network once you are in full production.

23


24


Network Considerations for the Advanced Client and BITS You should be aware that you may see a load while rolling out the SMS Advanced Client to client machines on the network. You can manage this impact by rolling the client out in various ways: as a prestaged client on a new operating system image, through remote installation from SMS, by using a logon or machine startup script, or with another method. As noted in Chapter 1, the SMS 2003 Advanced Client uses BITS when performing data transfers. BITS is preinstalled on Windows XP and Server 2003 and is available as an installable service on Windows 2000 Professional and Server. BITS is a component of IIS. BITS utilizes IIS on the server side to perform some level of communication with the client on the other end of the data transfer. BITS allows for throttling and controlling bandwidth on the network. However, one shortcoming of BITS is that it is unable to effectively estimate the utilization on an end-to-end basis. It is only able to determine the network load at the local network adapter. It is unable tell if a low-speed WAN link is saturated or fully available. There are two types of BITS clients: a server version and a client version. The SMS 2003 Advanced Client installs the client version automatically during its installation process. However, the server version needs to be installed manually as a prerequisite of SMS 2003. You should be prepared to install the BITS component as required on your SMS 2003 primary and other component servers that will house SMS-based roles. Additionally, the BITS client will be installed on your client systems. When preparing any change-control-related documents that you may require in your environment, you should mention that this component is being installed along with the SMS Advanced Client. This is of particular note if you are installing the Advanced Client in a server farm environment. The BITS client is quite inert and generally of minimal concern in most environments. You may also consider implementing an Active Directory–based policy that allows you to perform bandwidth throttling via the BITS client. Using this approach, you can guarantee a set threshold on your SMS Advanced Clients. This is not commonly done, but is an option in bandwidth-restricted environments. Chapter 8 includes information about configuring the bandwidth used by BITS.

SQL Server Considerations Since SMS requires a database backend, we need to discuss some SQL Server considerations when implementing SMS 2003. SQL Server is your only database option for running SMS 2003. You may have purchased an associated license for SQL Server with SMS 2003 or a separate SQL Server license. As a general rule, if you purchase SMS 2003 with the SQL Server license, it is cheaper than a separate license for SQL Server. However, you are limited by the license agreement to use that SQL Server installation only for that SMS 2003 installation. Be sure to consider which approach is most cost-effective for your organization. To be sure you have configured SQL Server for optimum performance, consider the following settings in your SQL Server installation for SMS 2003: User connections: Ensure that there are enough user connections configured for use. While the default value is unlimited; you can reserve a specific number of connections during the setup process of SMS 2003. Be sure you do not have a finite value defined within SQL Server. Memory: Too little available memory will greatly hinder SQL Server’s performance. You can configure how SQL Server will use available memory or RAM. The default is set to dynamically configure SQL Server’s memory consumption, so that the amount of memory it uses is determined by its current demand. With this setting and a large database, SQL Server could easily consume most available RAM, thus hindering system performance. You may restrict the amount of memory available to a finite amount, eliminating this potential issue. The downside of this



approach is that it may limit the size of database that may be used, which could result in problems if misconfigured on larger databases. Table 2-4 shows the Microsoft-recommended memory configuration values for SQL Server with SMS 2003. Realistically, most servers will exceed these memory values and will likely not experience memory-related issues. Database location: With SQL Server, you have the option of not having the database reside on the same server as the SMS 2003 primary site server. If you use this model, you should ensure that the SMS Service account and either the SMS SQL Server login ID or the group account (used by SMS) have access to the SQL Server database via the network. SQL Server startup: Make sure to set SQL Server to start up at system startup time. To do this, run SQL Server Setup, select Set Server Options, and then check the Auto-start Server at Boot Time option.

Table 2-4. Recommended SQL Server Memory Configurations

Server Memory

OS and SMS Services

SQL Server

128MB

80MB

48MB

256MB

160MB

96MB

384MB

224MB

160MB

512MB and greater

256MB

256MB and greater

In some organizations, a database administrator (DBA) will be responsible for SQL Server installation. In this case, the SMS administrator should discuss these requirements with the DBA before proceeding with SMS installation, and be sure to document any required changes!

Client Discovery Methods SMS 2003 offers several ways of discovering clients that exist in your network environment. Most of the discovery methods find the same resources, but some discover unique resource types such as user accounts and Active Directory OU memberships. You can choose the discovery method that best suits your environment and configure the discovery schedule and other key elements, such as domains and Active Directory containers. You can choose from the following discovery method types (you may use any number of these methods): Network Discovery: This method allows your SMS 2003 infrastructure to perform scans of your network to find new client systems. You configure the discovery type and discovery scope to tell SMS how and where to operate this discovery type. Heartbeat Discovery: I have three simple words about the Heartbeat Discovery method: keep it enabled! This method is used to keep existing client discovery data records (DDRs) up-to-date so that they are not deleted from the SMS database. Windows User Account Discovery: This method discovers only user accounts. By discovering these types of resources, you can target software distribution based on specific user accounts. The disadvantage of this approach is that the software tends to follow users. If they log on to another machine that should not receive the software, it may be loaded there inadvertently.

25


26


Windows User Group Discovery: This method discovers only user account groups. For example, you could target a specific application to all Accounting users. As with the Windows User Account Discovery method, a potential problem with this approach is that the software is downloaded to the machine from which users log on. Active Directory System Discovery: This method discovers Active Directory computer accounts. This, and the following two types of Active Directory discovery methods, can be useful when forming collections or groups of systems and users to target for software distributions. Active Discovery User Discovery: This method discovers Active Directory user accounts. Active Discovery System Group Discovery: This method discovers Active Directory group memberships. The discovery methods are configurable on a site-wide basis, with the exception of the Network Discovery method, which allows you to discover resources that exist outside the SMS site boundaries. Chapter 3 provides details on configuring client discovery.

Multiple Site Considerations SMS 2003 is fairly easy to design and install in smaller environments that have a single location or very well-connected locations. However, there are some special considerations when your organization extends over larger areas, multiple branch offices, or smaller clients that do not have good connections. To configure SMS 2003 optimally for this environment, you need to consider the setup of your primary site, secondary sites, and possibly Proxy Management Points, as well as the communications between these sites.

Primary Sites As discussed earlier in this chapter, by using the SMS 2003 Capacity Planner, you are able to try out several variations of SMS 2003 configurations. Trying varied configurations can assist you in developing an optimal structure that will have the least impact on your network infrastructure. You may have multiple primary sites in an organization, but you must have SQL Server databases in place to support those. Each primary site will be configured with its own site code. The other primary sites, or child primary sites, may be connected to other parent primary sites or have secondary sites connected below them. The overall design forms a tree-type architecture. You should try to keep this tree structure as flat and simple as possible, as it introduces latency into the operations of the SMS 2003 hierarchy. Organizations tend to try to limit the number of primary sites, as each one requires a SMS 2003 Server license and also a SQL Server license. This can get expensive and should not be architected unless a need to do so is clearly demonstrated during capacity planning.

Secondary Sites As noted in Chapter 1, secondary sites do not have a SQL Server database associated with them. Secondary sites also have lower hardware requirements than primary sites. You can place these sites more liberally throughout your enterprise. Of course, you don’t want to add secondary sites unless you need them. You may decide to install a secondary site because you have a small or congested network link separating the branch or remote location from the remainder of the network. By placing a secondary site in this location, you can configure a sender to control the transfer of SMS 2003 data to that location, and you are able to perform bandwidth throttling and scheduling. (Senders are described in the



upcoming “Site Communications” section, and configuring them is discussed in Chapter 3.) This is of particular interest when you are placing a DP in this location. Typically if you have a smaller location, a congested location, or large number of clients at a remote location, you will place a DP there. The problem is that you don’t always want the contents of a SMS package to be replicated to that remote DP at full throttle, especially at a prime time of day during business hours. You may also choose to use a secondary site to reduce the amount of traffic between your clients and the primary site by using a Proxy Management Point (PMP), as described in the next section.

Proxy Management Points (PMPs) By placing a PMP at a secondary site, you can restrict or control the transfer of data from the clients to the primary site, typically at or near the top of your SMS 2003 hierarchy, and vice versa. A PMP can collect the communications from the clients, and queue and compress them in preparation for transfer to the primary site server.

■Note

An SMS Advanced Client can be assigned only to its primary site. This means that it will retain that site’s site code, even if the secondary site may have a PMP located within it. The PMP is able to receive inventory data from clients and convert it to XML. Once the data is converted, it transfers the newly formatted data to the secondary site to be compressed and transferred to the parent primary site. It performs this transfer using the specified scheduling and throttling from the configured sender. The secondary site is able to send this data to the parent primary site in batches, as many clients may be reporting inventory during the same interval. The PMP has certain advantages for software distribution requests, too. Although it will not cache policy requests for users and machines, it will cache the actual policy body containing the details of a particular advertisement. Requests to locate a DP for an advertised package are not cached, as they are unique to each client. Again, without trying different configurations in your capacity planning analyses, you don’t really know the cost or benefits in placing a PMP in your remote site. If you have a location with a small number of client systems, the PMP may actually cost more in transferring data than if you did not have one configured at that location. Once your client base grows, the benefit starts to outweigh the network traffic cost. If you really need to reduce the amount of network traffic flowing across the WAN link to your secondary site and PMP, you may look at another technique using SQL Server replication. In performing SQL Server replication to your secondary site, the PMP is able to route its queries against that replicated database. Of course, now you are replicating SQL Server tables and stored procedures across that WAN link. Again, you need to examine the costs and benefits of doing so. This may be a viable solution if you have a large number of clients across a saturated or small WAN link. To implement this specific configuration, you must be familiar with SQL Server replication. You need to configure the PMP to look at the replicated SQL database using the SMS Administrator console. It really boils down to doing your homework and working through several scenarios with the SMS 2003 Capacity Planner.

■Note For further information about using SQL Server replication, see the “Planning for SQL Server Database Replication” section in Appendix E of the Microsoft document “Scenarios and Procedures, SMS 2003 Planning and Deployment” (http://www.microsoft.com/technet/prodtechnol/sms/sms2003/deploy/spgsms03/ spsms01.mspx).

27


28


SMS Site Communications In order for SMS 2003 sites to communicate with each other, you need to define the mechanisms that will be used to perform the communications, as well as the parameters for the communications. Two key concepts to consider when designing the communications parameters for your sites are senders and addresses. Senders describe the network link or media that will be used. Addresses describe the location or destination of the data being sent. You can think of addresses as the path or trail that the communication follows, and the sender as the method of how that data is transferred through it.

Senders When you are designing an SMS 2003 hierarchy, you may have multiple sites. To facilitate the communications between multiple SMS sites, you define senders to describe the network media and bandwidth scheduling that should be conformed to by the SMS site. If you have a single SMS site, you do not need to worry about configuring senders, as there are no other destinations to receive data. All sites within a hierarchy use senders to transfer data. This data may be destined to parent site servers or child site servers. The data transferred includes configuration, collection, package, and advertisement information. By using a sender for this data, you can optimize the delivery and perform some bandwidth scheduling to conserve network bandwidth during certain time periods. Limiting and scheduling bandwidth provides one of the most compelling reasons to design your SMS 2003 implementation with multiple sites. You can configure the following types of senders in SMS 2003: • Standard Sender, for all LAN communications. A Standard Sender is also used for WAN communications when routers are connected with LAN segments. • Asynchronous RAS, for Remote Access Service (RAS) communications over an asynchronous line. • ISDN RAS, for RAS communications over an ISDN line. • SNA RAS, for Systems Network Architecture (SNA) communications over an RAS line. • X25 RAS, for RAS communications over an X.25 line. • Courier Sender, to send and receive SMS packages through CDs, floppy disks, or tapes. A Courier Sender is typically used to send large volumes of data when available bandwidth is insufficient to transport the data. The Standard Sender is the type you will likely use most often. When you use another sender type, be sure that it is configured correctly from the Windows server perspective. Chapter 3 describes how to configure senders using the SMS Administrative console.

■Note Not all types of site communications will use the senders or their configured scheduling. For example, senders will not be used when you send data using the SMS Administrator console or Remote Tool connectivity to SMS sites elsewhere in the hierarchy, or for SLP and MP communications by clients. Addresses In order for the senders that you define to operate correctly, you must define the route, or address, of locations for communications. You define these addresses to specific parent and child sites, and on occasion, across to another site that may be adjacent to the current site.



You need to define an address for each communication destination site. Addresses are senderspecific, meaning that for each communication destination, you must configure a different address for each sender that you will use in communicating with that site. You may configure multiple addresses, each with a different sender to provide some form of redundancy. If communications are lost between sites, and if all senders are unable to provide connections, the site will continue to collect all its data and wait to transfer it once connectivity is restored. You do not necessarily need to configure senders and addresses for both directions of communications. You can configure only one direction, which will allow data to flow only in that direction. This can be useful in some site-specific configurations, or it could be an issue if misconfigured. Chapter 3 describes how to configure addresses using the SMS Administrative console.

SMS Site Boundaries and Client Roaming Site boundaries define the logical area of your network where client systems may reside and be managed by SMS 2003. If a client machine exists outside these boundaries, it may be discovered, but it will not be subject to management by SMS 2003. SMS boundaries are defined by IP subnet and/or Active Directory site boundaries. When you set up your SMS clients and SMS site boundaries, keep the following points in mind: • Your SMS sites should be defined by Active Directory site boundaries. This means that your clients should be running Windows 2000 or later to take advantage of Active Directory/SMS site boundaries. • If you have any low-speed subnets such as wireless, dial-up, or VPN, they should be defined by their own subnets and site. • Ensure all your local site boundaries are included as local roaming boundaries. • Your Legacy Clients will be included in an SMS site if their IP address or Active Directory site name is within the defined SMS site boundaries. • Your Active Directory sites should not cause SMS site boundaries to overlap; this ensures clients are assigned to only one SMS site. When an Advanced Client moves from one IP subnet or Active Directory site within an SMS 2003 site to an IP subnet or Active Directory site within another SMS site, it is said to have roamed. Only SMS 2003 Advanced Clients may roam within the enterprise and still have effective connectivity. When you configure your SMS site boundaries, you have the opportunity to configure the roaming boundaries. These may be local roaming boundaries or remote roaming boundaries. By defining the type of roaming boundaries, you can control how the Advanced Clients will behave when locating and accessing DP resources from these locations. Laptop users are prime candidates for roaming due to their portable nature. Without the use of roaming boundaries, the roaming client would still access the same SMS 2003 site resources as it did when it originally connected to a site. When SMS 2003 roaming boundaries are configured correctly, an Advanced Client is able to move freely between IP subnets and Active Directory sites and have connectivity to whichever SMS 2003 site resource is closest to it. This optimizes bandwidth use for maximum responsiveness and efficiency. Even though an Advanced Client may roam from one site to another, its site assignment will remain the same. Once the Advanced Client is installed on a client system, it is typically configured for automatic assignment of its SMS site based on SMS site boundaries. Roaming boundaries can be configured by IP subnet, IP address, and/or Active Directory site name. You can also configure the client so its site assignment remains static, regardless of the IP subnet or Active Directory site from which it connects.

29


30


The concept of client roaming is illustrated in Figure 2-3. In this figure, Client 1 is located in site Secondary 1. With correctly defined site boundaries, Client 1 is able to access localized resources such as DPs and MPs in each of the primary sites above its current location. Since the Primary 3 site is connected by a low-bandwidth connection and is defined as a remote roaming site, you can change the behavior of the Advanced Client when it is located in that site.

Figure 2-3. Client roaming configuration

Roaming Clients and MPs Advanced Clients interact with MPs, but are assigned to a default MP. All policy information, such as inventory data, is always sent to this MP (unless a PMP has been configured and is available for that SMS site). This is called the assigned MP. The resident MP is the default MP of the SMS site in which the SMS Advanced Client is currently located. As a client roams, it will use the resident MP as its assigned MP, depending on the roaming boundary in which the client is currently located. If you have configured a secondary site, an additional MP can be configured and assigned to that secondary site. This additional MP is called a PMP, as described earlier in this chapter. The PMP services the Advanced Clients that are in its roaming boundaries and are assigned to its parent primary site. While roaming, an Advanced Client will send its package source location requests to its resident MP. However, all other policy information will be sent to either the PMP or to the assigned MP, if a PMP does not exist. All messages, except for Advanced Client policies, are compressed during transmission to the MPs. When roaming, an Advanced Client attempts to locate a resident MP through Active Directory. Active Directory will then provide the client its assigned MP if it is within an assigned site. Additionally, the assigned MP will be used for package source location requests, where information about the available DPs is then sent back to the client.



Roaming for Software Distribution A key factor in how Advanced Clients will access advertised programs on DPs in roaming boundaries is how the program advertisement properties are configured. Upon receiving an advertisement, the Advanced Client determines if the advertised package and program are available locally to the client within the local roaming boundary. One of two actions will take place: • The package will be executed directly from the DP location. • The package will be downloaded before it is executed. If the advertised package and program are both unavailable locally, and the Advanced Client is within a roaming boundary—one of three actions will take place: • The package will not run. • The package will be downloaded from the remote DP before being executed. • The package will be run directly from the remote DP. If the Advanced Client is unable to be located in the current site that it is contained within, the client will revert to its assigned site to make a package source location request to its assigned MP. That MP will then provide the location(s) of the DPs that are available to the client. If the Advanced Client finds that the package source files are available locally, but are not accessible (possibly due to the package being updated), the client will not revert to its assigned site to access another instance of the package. This is intentional, as it will protect the WAN links against undesired or unanticipated traffic, if a DP has failed or if the package contents are unavailable for other reasons. If all conditions are favorable—the package is available and the advertisement is configured to download before executing—the client will download the entire package, and then execute the package contents.

Local Roaming vs. Remote Roaming Boundaries Out of the box, all SMS site boundaries are set as local roaming boundaries. By configuring local roaming boundaries, you define that the portion of the network is well connected to the remainder of the network and thus able to access DPs safely across its WAN links. You are able to explicitly define how the packages are executed by configuring the package options as download and execute or execute from the DP location. By defining a boundary as remote, you can configure an additional set of parameters in the package properties, further defining how this package will be executed in these locations. For example, suppose that certain areas of your network are connected by low-bandwidth links, or maybe the clients are connected via a less reliable medium, such as a wireless protocol. This area of connectivity is separated by an Active Directory site, or at least defined as a separate SMS boundary. This boundary is a remote roaming candidate. By configuring it as a remote roaming boundary, you can specify that the package properties dictate how the client will handle the package—perhaps as download and execute, or maybe even not available, considering the low bandwidth available within that boundary. Continuing with the example, assume that a second area of your network consists of desktop computers with a 100MB wired connection. There is little expectation of anyone moving these machines around, and it’s unlikely that the connectivity will be interrupted. This area of your network may be another city location and have SMS 2003 resources located in it. You would likely define this as a local roaming boundary. You could then define that the packages could be executed directly from the DP in this area.

31


32


In summary, the Advanced Client roaming boundaries work as follows: Local roaming boundary: A roaming boundary in which the site DPs are locally available to the Advanced Client, and software packages are available to that client over a well-connected link. Advertisements sent to Advanced Clients specify whether the Advanced Client downloads the package source files from the locally available DP before running the program. Remote roaming boundary: A roaming boundary in which the site DPs are not locally available to the Advanced Client. Advertisements sent to Advanced Clients specify whether the client downloads the software program from a remote DP before running it, runs the package from a remote DP, or does nothing and waits until a DP becomes available locally. By deciding how you want the Advanced Clients to handle available packages, you can determine how to configure specific boundaries. Generally, you would define areas as remote roaming boundaries for two reasons: if you do want the Advanced Client to download and execute the package contents when its subnet is located in the boundary, or if you don’t want the Advanced Client to download and execute the package contents when its subnet is located within the boundary. Bear in mind that the package properties dictate how that package is handled. Defining the roaming boundary type dictates which set of package properties is used. If your Advanced Client is not located within any of the defined roaming boundaries, it will revert to its originally assigned site for policy and all other site-related communications. The client is still able to access its package files, but they will be received from a remote DP. Alternatively, if the DPs of the site are remote to the Advanced Client’s location, and a BITS-configured DP cannot be located, the package files will be downloaded using Server Message Block (SMB).

Protected Distribution Points Another configuration related to local and remote roaming boundaries is called protected DPs. By protecting a DP, you can limit or restrict the scope of clients that are able to access the specific DP resources. In a simple single-site configuration, you may have little or no use for this type of configuration. When your SMS 2003 hierarchy extends beyond its immediate LAN confines and traverses WAN links of varying utilization and bandwidth, the benefit of protecting DP resources becomes apparent. By default, an Advanced Client will choose a DP within its site boundaries at random. This will ensure some form of load-balancing between clients and local DPs. This does not present a problem, until a client attempts to access a DP that is located across a low-bandwidth link. That subnet may be included in the site boundaries, but it may not be desirable for clients to be accessing that distant resource across the low-speed link. You can protect that DP from being accessed by clients located outside the defined protection boundaries. For example, suppose you have a remote location with a small number of clients. The remote location is connected to the primary location by a low-speed WAN link. There is little justification traffic-wise to separate this site as an additional SMS 2003 site. You place a DP to bring package content closer to the clients in that remote location. By protecting this DP in this remote location, you limit the clients that are able to access it to the scope configured in the DP properties, thereby eliminating the possibility of incurring WAN traffic that you did not expect. The converse of this is also true—you may want to restrict the remote location clients from accessing the DP located in your primary location. Keep in mind that you are removing some forms of redundancy when you protect DPs. Since this protection is limited only to DPs, other forms of client-to-site communications are still allowed across the WAN link. To calculate the potential impact of these communications, be sure to run your site configuration through the SMS 2003 Capacity Planner, as explained earlier in this chapter.



■Tip

You may want to check out the new System Center Capacity Planner 2006 tool from Microsoft. It is available with your TechNet subscription. For more information, see http://www.microsoft.com/ windowsserversystem/systemcenter/evaluation/capacity/default.mspx. It currently only supports the capacity planning for Microsoft Operations Manager and Exchange. It is expected to support SMS in future releases.

Regional and Global Roaming If you chose not to extend the Active Directory schema, or if Active Directory is not available on your network (yes, contrary to some published articles, SMS 2003 does not require Active Directory), your Advanced Clients can still roam, but only to sites that are lower in your hierarchy than from where they originate. Roaming at these lower levels allows these clients to still receive packages and programs from DPs. This roaming to lower sites is called regional roaming. If you do have Active Directory available on your network and choose to extend the schema (as discussed in Chapter 3), another roaming feature exists for your clients. The schema extension allows for global roaming. This will allow the Advanced Client to roam to sites at higher levels than from where it originates. Additionally, the client may then roam down branches of these sibling sites and still receive software packages from those site’s associated DPs.

Summary We have covered a lot of ground in this chapter to help you plan for your SMS 2003 installation or upgrade. You learned that the SMS 2003 Capacity Planner provides capacity-planning calculations and allows you to investigate what-if scenarios. Using it, you can determine network consumption and some basic server hardware requirements. We also went through some basic Active Directory health checks that you can perform, and covered how to clean out your old computer accounts, too. Next, we looked at the various SMS client discovery methods, followed by the considerations for multiple-site configuration. Finally, you learned about SMS site boundaries and client roaming, including local and remote roaming for mobile users.

33



CHAPTER 3 ■■■

Installing and Configuring SMS 2003

D

uring the installation and setup of SMS 2003 Server, you will need to configure various items. The entry of these parameters is very straightforward, so this chapter does not walk you through step-bystep screenshots of the installation dialog boxes. Instead, it focuses on the following activities: • Extending the SMS schema • Setting a security mode • Assigning SMS console permissions • Configuring addresses and senders • Configuring client agents • Setting up connection accounts • Configuring client discovery methods • Installing SMS clients • Adding secondary and primary sites • Adding site systems • Removing sites

Schema Extension As discussed in the previous chapter, extending the SMS schema allows you to fully use all of SMS 2003’s features. You may perform the extension any time: before, during, or after the setup of SMS 2003. If you choose after the setup, be aware that the site may not work as expected until it is extended, depending on the exact configuration of the site. I would recommend extending the schema prior to installing SMS 2003 for these reasons: • It will allow you to use the appropriate account to perform the extension, without requiring that you install SMS using this account. Additionally, this will save any group membership changes that may be required if you use a unique account for installing SMS 2003. • It will enable you to validate the changes to the schema manually. • The schema extension process is quick and relatively easy. It is well suited as an after-hours task. The remainder of the SMS 2003 installation may then take place during normal hours, so no one will need to work evenings installing a new product.

35


36

CHAPTER 3 ■ INSTALLING AND CONFIGURING SMS 2003

The process of extending the Active Directory schema does not actually put any site-specific information into Active Directory, and no existing information in Active Directory is modified. The extension simply adds four classes and ten attributes that any SMS site in the SMS hierarchy can use at a later time. Since the classes and attributes are new, a full global catalog (GC) replication is triggered. If you have a Windows 2000 Active Directory forest, the entire GC will be replicated. If your Active Directory forest is Windows 2003-based, only the changed classes will be replicated throughout the GCs. You should plan to extend the schema during an off-peak time, or anticipate the additional replication traffic and the potential of interrupting normal GC activities. You should discuss the implications of the GC replication with your Active Directory management team members and work with them to create a plan.

■Note

For more details on what is being extended in the schema, refer to Appendix A of the SMS 2003 Toolkit, available at http://www.microsoft.com/smserver/downloads/2003/tools/toolkit.asp.

Meeting the Schema Extension Prerequisites You need to meet two requirements prior to performing the schema extension: • The Active Directory schema must allow schema updates to be performed. Some Active Directory schemas are locked down for security reasons. They must be unlocked to allow the extension to take place. Your Active Directory team should be able to tell you if this has been done to your Active Directory schema. • The account performing the schema extension must have the appropriate permissions to do so. Generally, the account being used to perform the schema extension should be a member of the Enterprise Administrators group or have equivalent permissions in the Active Directory forest. Once you have met these prerequisites, you may perform the extension during the SMS Setup Wizard process or by manually executing the ExtADSch.exe command-line tool, available on the SMS Setup CD. The procedure to extend the schema varies depending on the whether the Active Directory is based on Windows 2000 or Windows 2003.

Updating the Schema on Windows 2000 Server If you are using a Windows 2000 Active Directory, you need to first enable the schema to allow updates. Before you can do this, you must register the Schema Microsoft Management Console (MMC) snap-in, by typing the following at a command prompt: regsvr32 schmmgmt.dll When RegSvr32 has successfully registered the DLL, you will see this message:

DllRegisterServer in schmmgmt.dll succeeded



After registering the MMC, follow these steps to update the schema: 1. To start the MMC, select Start ➤ Run. Type MMC in the Open dialog box and press Enter. 2. In the MMC, select File ➤ Add/Remove Snap-in. 3. In the Add/Remove Snap-in dialog box, click the Add button on the Standalone tab. You will be presented with a list of snap-ins that are available for the console. 4. Click Active Directory Schema, and then click Add. 5. Click Close, and then click OK. 6. Expand the Active Directory Schema tree so that the Classes and Attributes sections are displayed on the right side. 7. Right-click the Active Directory Schema and select Operations Master. 8. Place a check mark in the Schema May Be Modified on This Domain Controller check box. 9. Click OK, and then exit the MMC. After completing this process, the schema may now be updated on the domain controller that holds the schema Flexible Single Master Operations (FSMO) role. Alternatively, you may enable schema updates by editing the Registry. For details on the Registry modifications, refer to the Microsoft Knowledge Base article “Registry modification required to allow write operations to schema” (http://support.microsoft.com/kb/216060/EN-US).

Updating the Schema on Windows Server 2003 If you have already upgraded your Active Directory, or started fresh with a Windows 2003 Active Directory, the schema is already enabled for updates. Nothing else needs to be done to allow schema updates unless your Active Directory has been locked down for security reasons. If this is the case, you will need to edit the Registry to unlock the schema update ability. Perform the following steps to remove the security restriction: 1. Select Start ➤ Run. In the Open box, type regedit, and then press Enter. 2. Locate and select the following Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 3. In the Registry Editor, select Edit ➤ New ➤ DWORD Value. 4. Enter the following Registry entry: • Name: Schema Update Allowed • Data Type: REG_DWORD • Base: Binary • Data: 1 5. Close the Registry Editor. Now that you have made this change, you can make updates to the Active Directory schema. You may want to reverse this change to again disallow schema updates after you have made your updates for SMS 2003. Simply change the data value to 0 (zero) to disallow schema updates.

37


38


Verifying the Schema Extension When you have completed the schema extension process, you should confirm that it completed as expected. You will notice (or perhaps not) that the ExtADSch.exe tool does not produce any visible output. Fortunately, you can check the ExtADSch.log file to make sure that the extension was performed successfully.

■Note

You can find the ExtADSch.log file in the root of the system drive on the system where it was executed. This is always the location, no matter where the executable was initiated. If necessary, you can use the ADSIEdit MMC snap-in to view and verify the schema classes and attributes. I usually use this tool after SMS 2003 is installed and configured. It will confirm that SMS is able to publish its data successfully into the appropriate containers and attributes.

Configuring SMS 2003 Active Directory Data Publishing Several SMS components publish data to Active Directory as needed. Each site server will attempt to publish its data in Active Directory, but without appropriate permissions, the MPs can’t be published and clients will not be able to install their Advanced Client components. You must meet two conditions to publish site-specific information: • The Active Directory schema must be already extended, as described in the previous section. • The account performing the publishing to Active Directory must have permissions to perform the tasks. By default, SMS is installed with the site property enabled to allow publishing. You can check this by opening the Sites Properties dialog box (right-click your site name and choose Properties), clicking the Advanced tab, and verifying that the Publish Identity Data to Active Directory check box has a check. You must set the proper permissions for the SMS account responsible for updating the schema extensions. Follow these steps to set permissions on the System container: 1. Open the Active Directory Users and Computers administrative tool. 2. Select View ➤ Advanced Features. 3. You should see a System container for the domain. Click the folder, and then right-click and choose Properties. 4. Select the Security tab, click the Advanced button, and then click the Add button. 5. Click the Object Types button and enable the Computers type (this applies only if your SMS site is using advanced security). Click OK. 6. Enter the name of the site server or SMS service account that needs permissions to perform the publishing. 7. In the Apply To list, choose This Object and All Child Objects. 8. Enable Full Control. 9. Click OK, and then close all dialog boxes. Once you have set the permissions correctly, the SMS site will create the System Management container after the next Hierarchy Manager and/or Site Component Manager cycle executes. After this new container is created, SMS will add the site-specific information under the System Manage-



ment container. Discovered clients will become managed clients if the IP subnets and/or Active Directory site boundaries have been previously defined.

■Note You can create the System Management container object manually if necessary by using ADSIEdit. This object must be named System Management and must be a container object type. Pay close attention to spelling (for example, make sure you don’t enter “Systems” Instead of “System”). Once you have created the System Management container under the System folder, the SMS site server’s machine account or the SMS service account does not require permissions to the System folder. If you remove the permissions from the System folder, the Full Control permissions must be set for all SMS service accounts or SMS site server machine accounts (this could be done through the use of a group) and be enabled for This Object and All Child Objects on the Systems Management folder. If you have any problems, check the ExtADSch.log file located in the %system% folder for error/ success messages. Two other processes are responsible for publishing information into Active Directory: the Hierarchy Manager (a thread of the SMS_EXECUTIVE process) and the Site Component Manager process. These processes create the Hman.log and Sitecomp.log files, located in the \sms\logs\ folder. You can check these files for additional messages that may assist in resolving problems.

Security and Permissions SMS 2003 offers two security modes: standard and advanced. Also related to security are the permissions that you can set on the SMS console.

Choosing a Security Mode SMS standard security mode is useful when your Windows server network still contains some NT 4.0 servers. Installing and operating in this mode will result in the creation of many security accounts that are required to operate your SMS sites. When your environment has Active Directory running in native mode (as is typical nowadays), you can choose the advanced security mode. This mode has the benefits of creating fewer security accounts, using the local system context, and providing the ability to use machine accounts in Active Directory for increased security protection. The SMS security mode is defined during the setup of SMS 2003. It is simply a check box that allows you to enable the Advanced Security model. You may move your site to advanced security after installation by modifying the site properties from within the SMS Administrator console. This is a one-way operation. The only way back to standard security is via your backup/restore process. Be sure to back up your SMS sites prior to performing this operation. To switch to advanced security, right-click the site name, and select Properties. On the General tab, click the Set Security button, and then confirm your intentions. When you do this, Windows Management Interface (WMI) is restarted. You must restart your SMS Administrator console for the change to take effect.

Setting SMS Console Permissions When installing SMS 2003 into your environment, you need to consider the access required by others. You likely will have help desk staff members that require access to the SMS console. Additionally, other people, such as your peers and managers, will require access. You can use permissions to allow and restrict access to each area of the SMS console. (Similar permissions exist for SMS web reports, but they are narrower in scope.)

39


40


You grant permissions to security objects. Essentially, everything in SMS 2003 has an associated security object. SMS has a total of eight security object types: • Site • Collection • Advertisement • Package • Report • Query • Software Rule Metering • Status Message Each object tends to have two security configurations: Instance security: Deals with assigning permissions based on specific area content, similar to assigning permissions to a file inside a folder. Class security: Allows permissions to be assigned to all the objects within that class. Again using the folder analogy, think of the class as the folder. You may apply class permissions against each of the eight security objects or apply instance security permissions against their contents. These permissions can be assigned to local or domain accounts or groups. By default, the account used to install SMS 2003 has Administer permissions to all security objects in the SMS 2003 console.

Assigning Permissions You can use several basic methods to assign permissions: Assign permissions to a class: In the SMS Administrator console, right-click a specific object, choose Properties, and select the Security tab. You can add, modify, and remove security rights as needed. I don’t prefer this method because it is time-consuming and leaves a large margin of error when performing many configurations to achieve the end goal. Assign permissions via the Security Rights node: Click the Security Rights node in the SMS Administrator console to see all the configured security rights, as shown in Figure 3-1. You may add, remove, and modify the rights as needed. Additionally, you can clone or copy an existing user’s or group’s permission assignments to a new or existing user or group. You are not limited to assigning permissions to classes, but also may assign instance-based permissions as needed by browsing objects within the chosen class. I prefer this method, as it allows me to perform mass configurations quickly and easily. Assign permissions to an instance: In the SMS Administrator console, right-click a specific instance, choose Properties, and select the Security tab. You can add, modify, and remove security rights as needed. I don’t like this method for the same reasons that I don’t like assigning permissions to a class.

■Note A benefit of assigning permissions to an instance is that you can apply highly granular permissions to SMS 2003 console objects. However, before creating this level of complex permissions, you may want to stop and think whether there is a better method of organizing roles or SMS console objects to achieve the same result but avoid the complex security configurations.



Figure 3-1. Security Rights node Use the SMS User Wizard: To run the SMS User Wizard, right-click the Security Rights node and choose All-Tasks, Manage SMS Users. This wizard allows you to add new users and assign class and instance permissions to the new users. It also lets you modify and copy the permissions of an existing user. Since it is a wizard, it is easy to use, as long as you have a basic understanding of SMS 2003 security.

Putting Security Permissions to Work Now that you understand how to assign specific security permissions to classes and instances, let’s take a closer look at how you would really apply these in your environment. In a mid-sized organization, you may have several groups charged with the care of your desktop assets. Typical roles include help desk, software specialists, server administrators, and IT management. You could just add everyone to the required group to access the SMS console and Remote Control agent. However, allowing staff members who are not familiar with the use of SMS 2003 could result in unintended actions—software may be deployed, systems rebooted, or worse, reimaged. This is far from ideal. Here is how you might want to assign permissions to the typically used objects: Help desk: Allow the help desk staff to view the collections, advertisements, and packages, and allow remote tool operations against the collections and their members. This lets them perform their daily work as needed, without giving them the opportunity to inadvertently change a site configuration or software deployment schedule. Software specialists: Your software specialists are typically charged with designing software installations, testing software configurations, building OS images, and such. You may trust that they are able to manage software deployments and their scheduling appropriately. They probably will not require access to changing the site configurations, but would need the ability to build collections, queries, packages, and advertisements.

41


42


Server administrators: Your server administrators may not need to change advertisement schedules or add packages, but they definitely require access to the site configuration. They should be highly educated, and you should be able to trust their ability to manage their activities within the SMS 2003 console so that no inadvertent actions take place. You would probably assign them full or Administer permissions to the entire console contents. Possibly, you may not want them to perform remote control actions against clients, leaving their remote console tasks on servers to other technologies, such as Remote Desktop Protocol (RDP) or IP keyboard, video, mouse (KVM) switches. IT management: By all means, allow your IT management access into your SMS 2003 environment. They can be your best proponents for such tools, especially when supplied with the ability to view queries and web reports. Create some customized reports that suit their specific needs, permit them access, and educate them on how to access these reports. I doubt very much that they will need to view anything else inside the SMS console. Now that you have defined the roles in your environment and determined the level of access that they require, I would strongly suggest creating a permissions matrix in Excel. This will assist you in your documentation efforts and make the overall interpretation easier. Table 3-1 shows possible permissions that you may apply to various areas of the SMS console.

Table 3-1. SMS 2003 Console Object Permissions

Permission Name

Object Type

Description of Object

Administer

All security objects

Administer all object classes.

Advertise

Collections

Advertise existing software packages to collections.

Create

All security objects

Create new instances of objects.

Delegate

All security objects except Status Messages

Grant given rights to other users.

Delete


Delete instances of objects.

Delete Resource

Collections

Delete instances of collection objects.

Distribute

Packages

Deploy software packages to a DP.

Manage SQL Commands

Sites

Create and modify SQL commands via the SMS console.

Manage Status Filters

Sites

Create and modify status message filters via the SMS console.

Meter

Sites

Apply software metering rules to a site.

Modify


Modify or edit an object.

Modify Resources

Collections

Modify the contents of a collection.

Read


View an instance of an object or class.

Read Resources

Collections

View the resources in a collection.



Table 3-1. SMS 2003 Console Object Permissions

Permission Name

Object Type

Description of Object

Use Remote Tools

Collections

Initiate the Remote Tools agent against a client.

View Collected Files

Collections

View collected files for a client.

Permitted Viewers*

Collections

Operate the Remote Control agent against a client.

* This is a list of users or groups that are allowed to operate the Remote Control agent found within Remote Tools. By default, the Administrators group is added to this list. The permitted viewers list is language-specific, so ensure that if your administrator’s group name is in another language, it is listed explicitly for each language needed.

Customizing the SMS Administrator Console With SMS 2003, you have the option of creating a customized console for use by specific staff groups. Continuing with the example in the previous section, the help desk staff will require access to the SMS console, but only to specific areas. You want to allow them Read access to the Collection, Advertisement, and Package objects. You will also give them Remote Control permissions to the contents of the Collection objects, allowing them to assist the general user population. First, you need to make sure that you have a domain group of the help desk staff accounts. Let’s say the group is named CORP\Helpdesk. You will apply permissions from within the SMS console to the Collection objects, specifying Read, Read Resources, and Use Remote Tools, and add their domain group to the SMS server’s local group, Additionally, you must specify their membership in the Permitted Viewers list. The Permitted Viewers list is configured through the Remote Tools Client Agent Properties dialog box, as described in the “Configuring Client Agents” section later in this chapter. To deploy a customized SMS console to the help desk staff, you need to add the Collection object to the MMC. Creating a custom console is fairly simple. You just open the MMC, add the SMS snap-in, and follow a simple wizard-driven configuration process.

■Note An alternative solution may be to enable access to the Remote Tools via the SMS 2003 Web Reporting Remote Tools Page add-in. This is a free and downloadable modification that you can apply to SMS 2003 web reports. At the time of writing, the current version is 3.21. You may download this SMS add-in from http:// myitforum.com/articles/19/view.asp?id=8662. To create a custom console, follow these steps: 1. At your desktop or server that has an existing SMS 2003 console, execute MMC.exe from the command line or by selecting Start ➤ Run. 2. In the MMC, select File ➤ Add/Remove Snap-in. 3. In the Add/Remove Snap-in dialog box, click the Add button on the Standalone tab. You will be presented with a list of snap-ins that are available for the console. 4. Select the Systems Management Server snap-in, and then click the Add button. 5. The Site Database Connection Wizard starts. Click Next to continue. 6. On the Locate Site Database page, enter the name of the site server to which this console should connect. Click Next.

43


44


7. You will be presented with a list of items that may be checked and added into the console. In the example of creating a tailored console for the help desk, select the SMS Collections, Advertisements, and Packages items. 8. Click Next to continue, and then click Close to finish the console-creation process. 9. Click OK in the Add Standalone Snap-in dialog box. 10. Select Console ➤ Options. 11. Select User Mode – Limited Access, Single Window. These options will ensure the MMC menus are not displayed when being used by your intended users. Be sure to select the Do Not Save Changes to This Console option. It will prevent users from making any changes to the console that you set up. Complete your configured console by clicking OK. 12. Save the console by selecting Console ➤ Save As. 13. Close the MMC. You may distribute the customized SMS console as desired to your staff. It is not just as simple as sending the saved file (an MSC file), however. The SMS 2003 console components must be installed first, and then the MMC used to open the customized MSC file. Typically, the SMS console may be loaded manually and the newly created MSC file transferred to the staff desktop.

■Note

Remember that the users who you are giving the customized console will require access to the SMS database. Be sure to add their domain group to the SMS database server’s local SMS Administrators group. When the users open their customized console, they will be able to see and access only the components that were specified during the console creation and for which they were granted access permissions from within the SMS console. You can create separate customized consoles to allow appropriate access to the various groups in your organization.

Site Configuration In Chapter 2, I described the site configuration considerations that you need to be aware of when setting up or altering an SMS 2003 hierarchy. Now, I’ll cover how to actually configure these settings. The SMS site configuration options are available through the SMS Administrator console. As shown in Figure 3-2, drill down through the Site Database and Site Hierarchy nodes to the site that you wish to configure, and expand the Site Settings node. From here, you can configure all the key settings required to first set up the SMS 2003 site(s), and then add sites to the existing hierarchy.



Figure 3-2. Site Settings node

Configuring Addresses As explained in Chapter 2, a sender allows you to represent how a SMS 2003 site will communicate with another site. An address needs to be defined for each site with which the current site being configured will communicate. If you fail to configure addresses correctly on each site, you could end up crippling one or more sites by preventing communications between them. For example, suppose you have a simple three-site architecture, where two child primary sites report to a top-level or central site. You would define the following addresses on the respective sites:

Central Site

Child 1

Child 2

Address to Central

Address to Central

Address to Child 1 Address to Child 2

Each child site does not need the address of the other child sites. It just needs the address of the central site that resides above it. In the example, the central site has the addresses of the child sites, so you can perform reporting and administrative tasks that would flow down to the child sites.

45


46


Alternatively, you could omit the child site addresses from the central site configuration, using only addresses at the child site level. This would direct the flow of data one way to the central site. With this type of alternate configuration, you use the central site only for reporting purposes. Separating this data from your normal production site can reduce the chance that the reporting efforts of other groups within your organization will disrupt your regular site performance. To configure addresses, under the Site Settings node for your site, right-click the Addresses node, choose New, and then select the type of sender address you wish to create. As described in Chapter 2, the sender types are Standard Sender, Asynchronous RAS, ISDN RAS, SNA RAS, X25 RAS, and Courier Sender. Typically, you will use the Standard Sender.

Standard Sender Addresses In the Standard Sender Address Properties dialog box, shown in Figure 3-3, you must specify the destination site code to which the sender will send SMS data. You also configure the destination site server’s name, which is the NetBIOS name. If you configured your SMS site to use advanced security, you will not be able to configure the account that the sender uses; it defaults to using the local system account. If you are using the standard security mode, you need to specify a domain account that has access to the SMS_Site share on the destination site server.

Figure 3-3. Standard Sender Address Properties dialog box

Asynchronous RAS Sender Addresses The Asynchronous RAS Sender Address Properties dialog box looks slightly different from the Standard Senders Address Properties dialog box. You must specify the following: • A phone book entry, along with an account that has permission to use the phone book entry • The correct entry that contains dial-up information to access the destination site server • The server name • The domain of the destination server



As with the Standard Sender, if you are using advanced security, the sender will use the local system account. If you are using standard security, you must specify a domain account that has access to the SMS_Site share on the destination site server.

ISDN and X.25 Sender Addresses The ISDN and X.25 Sender Address Properties dialog boxes both look similar to the Asynchronous RAS Sender Address Properties dialog box. The only differences are the configured phone book entry and which protocol the sender uses to communicate with the destination site.

Courier Sender Addresses The Courier Sender offers an alternative way of sending package information to another site server. It can transport only SMS packages, not any other type of database information, as the other senders are able to transfer. This type of sender allows external media to be used and physically transported to a remote site. Once mounted, whether by CD/DVD, tape backup, USB, or other media, the destination server is able to access the packaged data. The Courier Sender Address Properties dialog box is simpler than those for the other sender types. It contains only a field to set the destination site code. After being configured, the Courier Sender is used to start the Courier Sender Manager. The process for using the Courier Sender is fairly simple. It just takes a few manual steps to create the package that you can copy and transport. Transfer the package to your media and dismount it for transportation. Here are the steps for creating a package for transportation: 1. Open the Courier Sender Manager from the Start ➤ Systems Management menu. 2. Select File ➤ Create Outgoing Parcel. 3. Choose your package from the list. 4. In the Parcel Properties dialog box, enter a name for the package. Then enter your tracking name and a physical transportation description. Also enter a path to where you want to save the parcel; by default, .\SMS\Inboxes\Coursend.box\Out is used. Click Next to proceed to the final screen. 5. Click Finish to complete the process. 6. Transfer the parcel file to another media type, such as CD\DVD. Send this to your destination site. 7. Once the package is received at the destination site, have it physically mounted in the site server, insert the CD or DVD, and copy the parcel file over to the .\SMS\Inboxes\ Coursend.box\In location. 8. Launch the Courier Sender Manager application at the destination location. 9. Select File ➤ Receive Incoming Parcel. 10. Browse to the correct location. It should start at its default location where you previously copied the parcel. Click Open. 11. Click the Next button, and then click Finish to complete the process. Once this process has been completed, the received package will be treated just as if it were transferred electronically. It will be processed and copied to the correct location.

47


48


Sender Schedule and Rate Limits Properties All the Sender Address Properties dialog boxes have Schedule and Rate Limits tabs. The Schedule tab allows you to configure the time periods during which you want the sender to operate, plus allow specific priority traffic to use the sender at specific times. Commonly, these schedules are optimized to allow only high-priority traffic during peak network utilization time. Here is where it pays to have done some research on the characteristics of your network utilization. You may completely close the sender for specific time periods and allow all traffic types through during other periods. The benefit of this approach is that it allows some form of bandwidth control across remote WAN links. Unfortunately, the usage of a sender is restricted to secondary and primary sites, not to DPs. If you need to restrict or close communications to a remote site during specific times, be sure to create a secondary or primary site at that location. Its DPs will still be able to receive the packages as desired, but will fall under the restrictions of the schedule you configured. The Rate Limits tab allows you to specify times of the day to restrict bandwidth usage based on a percentage of available bandwidth. This is not always the most effective method of performing bandwidth throttling, but it will allow you to decrease the rate at which data is placed onto your network link. By default, this is configured as unlimited.

Configuring Senders By default, one Standard Sender is preconfigured. You can create additional senders by right-clicking the Senders under the Site Settings node, selecting New, and choosing the type that you wish to create. The Standard Sender Properties dialog box contains two tabs. The General tab allows you to specify the server name that you wish to configure this sender to send data to as a destination or location. Enter the NetBIOS name of the server in the Server field. The Advanced tab allows you to configure several parameters that alter the way the sender transfers data. Since senders can be used to transfer data to multiple sites simultaneously, you can place some thresholds on how many instances of the sender may be operating at the same time. Using the Maximum Concurrent Sendings setting, you can specify a numeric value for all sites and on a per-site basis. The default is set to 5 senders operating to separate sites, using 3 instances of the sender to each site, for a total of 15 senders. The Number of Retries setting configures how many times the sender will attempt to send data to a site before generating a failure status message. The default is 2 retries. You may wish to increase this value if your network is quite busy. The delay before retrying is set to a default of 1 minute. Again, you may wish to increase this value to perhaps a maximum of 5 minutes, although a higher setting is acceptable—it just adds delay to the communications if a failure is encountered. The other sender type Properties dialog boxes have the same settings as those for the Standard Sender, except that you cannot control the number of concurrent sendings on a per-site basis. These senders are restricted to one sending stream per site, due to the nature of their protocols.

Configuring Client Agents When setting up your SMS 2003 site, you can configure five client agents: Hardware Inventory, Software Inventory, Remote Tools, Advertised Programs, and Software Metering. You may leave some, none, or all agents disabled or enabled as you desire. These do not need to be set up right away, but by preconfiguring them, you will not need to wait for your clients to receive the new policy containing the updated settings.



If you are using the Legacy Client, the files required by the configured agent will be transferred to the client, along with its configured settings, at every component update cycle. By default, that happens every 25 hours. If you are using the preferred Advanced Client, you can expect the agent to start responding at the next policy refresh cycle, which is every hour or at the next bootup cycle of the client machine, by default. Each client agent is listed in the Site Settings tree under Client Agents. To configure an agent, right-click it and select Properties to open its Properties dialog box. These settings are applied to all clients in that site—they are site-wide settings.

Hardware Inventory Agent SMS 2003’s hardware inventory collection component is widely used by other features of SMS. You may require it to build custom collections based on queries for hardware configurations, network addresses, and subnets. Patch management relies on hardware inventory for the delivery of vulnerability information. It is indeed an integral part of the SMS 2003 hierarchy. Various types of inventory are reported through this communications channel, including Registry settings (such as Add/Remove Program data), and WMI-based data (such as hardware and BIOS-level data). The Hardware Inventory Agent is quite efficient. It is quick and is able to report only delta information to the SMS site about what has changed on the client. This delta inventory is generated only after the hardware inventory client has performed and reported a full inventory to the SMS site. This report of full inventory information is known as a resync. This can happen if the inventory is detected as corrupted, if the SMS_def.mof file has been altered at the MP, the inventory delta contains database record updates for a table that does not exist, the SMS client has moved to a new SMS site, or the client has been upgraded from the Legacy Client to the Advanced Client. Hardware inventory collection configuration is simple, and its impact on the client and network is quite small for such a rich and enabling feature. In the Hardware Inventory Client Agent Properties dialog box, the General tab includes options for enabling the agent and for configuring specific schedules for when you want the Hardware Inventory Agent to run its job on the client. You can choose from two main scheduling methods: Simple Schedule: Executes the cycle once every interval. If the machine is off, the interval just gets bumped ahead. For example, if you set the cycle to run every five days and the machine is powered off just after it completes its last cycle and is not turned on again for six additional days, effectively it has missed its five-day schedule. It will restart the five-day interval from the day it is powered on. This has the effect of randomizing the execution of the inventory cycles, allowing for the load to be spread across a time period rather than happen all at once. Full Schedule: Allows you to specify a start time and date, and a reoccurrence pattern. It will not accept a start date/time that does not match the reoccurrence pattern that you specify. The reoccurrence pattern is the interval—day of week or month of year—for the cycle. If you specify an interval reoccurrence pattern, you can choose the specific number of days, hours, or minutes. A more typical configuration is to use the weekly reoccurrence pattern, for which you can set the number of weeks and the day for the cycle to begin. If you choose a monthly reoccurrence pattern, you can select the number of months to reoccur, as well as the number of days, the last day of the month or the first, second, third, or fourth occurrence of a day of the week during a month. Unlike the simple schedule, the full schedule will not kick off the inventory cycle as soon as a machine comes back online from a powered-off state. It will wait until that interval is reached again. This has the effect of ensuring all machines perform the operation in sync.

49


50


These are complex options, so consider them carefully and be mindful of the possible impact on your network and overall inventory reporting requirements. If you need to have an inventory as up-to-date as possible on a regular basis, the full schedule may be your best choice. If you don’t have that concern, and would like to benefit from spreading the inventory load across time, the simple schedule should suffice. Keep in mind that all of the inventory operations are easily scripted and executed by an SMS 2003 advertisement to all or selected clients. This presents a good option for those who require the best of both scheduling options.

■Tip Starting SMS inventory cycles by advertising a script to SMS clients is quite straightforward and allows you to be able to stagger your client inventory cycles among various collections. This is an excellent strategy if your network is normally quite busy and you would like to execute inventory scans at specific times. The Full Schedule option provides this ability, but it is site-wide. Advertising a script to perform the same action gives you greater control. For more information, see the Microsoft TechNet article, “Software Inventory Scripts for SMS” (http:// www.microsoft.com/technet/prodtechnol/sms/sms2003/maintain/smsscript/script29. mspx?mfr=true). The General tab also has an option related to Management Information Format (MIF) file collection. An MIF file contains custom information to be reported to the SMS database via the Hardware Inventory Agent. For example, it may contain employee names and phone numbers and allow them to be reported back to the database and associated with the client machine name. Once in the database, this data is fair game for reporting and queries. The information in the MIFs may be entered by hand through a user interface or generated automatically through a script. A common use is to enhance the generation of specific inventory information about an SMS client hardware platform. Chapter 8 contains more information about MIFs and their uses. The setting at the bottom of the General tab allows you to configure the maximum size of a custom MIF file to be collected. The default maximum size for the MIF file is 250KB. If you have extended use of MIF files in your organization from previous SMS instances, you may need to configure this higher. The MIF Collection tab has options for enabling the collection of IDMIFs and NOIDMIFs for both the Legacy Client and Advanced Client. By default, the collection of both MIF forms is disabled for these clients.

■Caution By creating an MIF, otherwise known as an IDMIF, you are in effect altering the SMS database, creating new tables and populating them with data. Be careful with this! Always test this extensively in the lab. An NOIDMIF allows the population of the created table with data and has a similar format to an MIF. You have better ways to enhance the SMS inventory by modifying the SMS_Def.mof, which is a framework outlining what inventory items to collect and report. Software Inventory Agent The software inventory function scans files located on the client’s local disk and reports the findings to the site server. As with the Hardware Inventory Client Agent Properties dialog box, the General tab of the Software Inventory Client Agent Properties dialog box has options for enabling the Software Inventory Agent and configuring its schedule. The schedule options are identical to those of the Hardware Inventory Agent. The other tabs in this dialog box have the following settings:



Inventory Collection: Allows you to configure the file types to be inventoried. By default, the only type is the .exe file extension. You may choose to inventory by extension or by full filename, and you can use wildcards. You may add any file type here, but use some caution. For example, you likely don’t want to inventory all .dll files across the system disk, since that would expand the SMS 2003 database significantly. You may want .dll information for some files, located in a specific folder location. You may add the .dll file type and specify the specific path and whether the agent should search subdirectories. The Global options allow you to exclude encrypted and compressed files and/or exclude files in the Windows directory from being inventoried. File Collection: Allows you to specify files that should be collected and sent to the SMS site server by the File Collection Agent. These files can then be reported on, examined, and so on. By default, no files are collected, but some applications like the Microsoft Application Compatibility Toolkit use this mechanism to transfer their report files up to the SMS site server, where they are used by another application. They just piggyback on the existing SMS infrastructure. As with file type specification, you may be quite general or specific in specifying the files and locations to be collected by the agent. Additionally, you may place size restrictions on those collected files. Inventory Names: Allows you to consolidate the inventoried manufacturer names to a master name that applies to all the names found. For example, you could consolidate all inventoried files that report Microsoft, Microsoft Corp, or Microsoft Corporation into a single manufacturer, such as Microsoft Corporation. This reduces the total number of software manufacturers and makes your software inventory more accurate and readable. You may add and remove names.

Remote Tools Agent Another key feature of SMS 2003 is Remote Tools, which allows remote control of the client’s desktop. This can be useful to allow help desk staff to demonstrate a technical process or to fix an issue.

■Note SMS Remote Tools is not loaded by default when installing an SMS 2003 site. You must explicitly check the option box to install that component. If you don’t see it in the Site Settings tree in the SMS Administrator console, check that it was selected during installation of SMS 2003. The General tab of the Remote Tools Client Agent Properties dialog box has a few key options. You must place a check mark in the Enable Remote Tools box so you can use this agent. Placing a check mark in the “Users cannot change policy or notification settings for SMS Remote Tools” box will essentially lock down your settings as you define them in the console. This is generally a good idea. You can also choose to not install Remote Control components for Advanced Clients running Windows XP, Windows Server 2003, or later, which would force the use of Windows Remote Assistance and Remote Desktop. Microsoft recommends that you do not install Remote Tools on Windows XP and higher OSs. However, this is not always desirable, as you may have a highly mixed environment and it would be a time-consuming task for your help desk staff members to ensure they are firing the right remote control tool option to gain access to their client. There is seldom a technical issue in using both types of remote tools on Windows XP and above platforms. The last two options on the General tab pertain to the Windows XP/2003 Remote Assistance application. You may allow SMS to manage or override Remote Assistance settings found on a client machine. The exact usage of these two settings is somewhat ambiguous and poorly defined in any Microsoft documentation. I typically leave them unchecked. The other tabs in this dialog box have the following settings:

51


52


Securities: Allows you to define a list of users and groups that you permit to use Remote Tools on clients. By default, the list contains only the Administrators group. Be sure to add the appropriate groups to this list to allow their access to Remote Tools. Policy: Allows you to define the level and type of access your Remote Tools may have on your clients. Your choices for level are Full, Limited, and None. Full access is just that: no restrictions. None disallows the use of Remote Tools against a client. Limited, the most common choice, lets you select options to allow and disallow types of access. You can remove some of the more dangerous actions that may be taken on a client, such as restarting the client computer. Another option on this tab is whether to display a message asking for permission to operate Remote Tools on the client. The last option allows you to define the level of access for Windows XP/2003 Remote Assistance. Your choices are Full, View Only, or None. By default, the user must be present to allow full control to the viewer; this is by design in Windows XP/2003 and cannot be overridden. If you select None, only other types of remote access may be used.

■Note I feel that requiring permission before taking control of a client is an unnecessary requirement and hinders what the help desk workers can do. Often, people who require assistance are already on the phone with their help desk and can verbally give permission. If permission is required via a dialog box, and the user is not at the machine, help desk workers may be unable to complete an action that they need to take. This can be a hot subject during the configuration of SMS 2003 and is best thoroughly discussed and approved by the appropriate level of management in your organization. Notification: Allows you to configure the visual notification that someone is operating Remote Tools against the system. I typically enable the Display a Visual Indicator and select Show Status Icon on the Desktop. I leave the Also Show When No Session Is Active option unchecked, to avoid cluttering the client desktop. I also enable Play a Sound, and then select to Play a Sound When Session Begins and Ends.

■Caution

The notification sounds may not operate correctly on Windows XP and above. When the sounds are played repeatedly during the session, they become irritating to the user and his cubicle neighbors. Advanced: Includes options that are automatically selected and rarely changed. You may adjust the level of compression used for the transfer of screen data across the network. By default, it is set to Auto. I recommend leaving it there; it will adjust itself according to the CPU speed of its client. You can’t change the default remote-access protocol, because it has been hard-wired in SMS 2003. The Install Accelerated Screen Transfer on Windows-based Systems option applies to Window NT 4.0 clients. If you still have such clients, make sure your video card manufacturer’s name is listed. Adding a name to this list indicates that you have tested the accelerated transfer on those clients’ video cards.

Advertised Programs Agent The advertised programs function provides the most powerful service to SMS 2003. In order for software distribution to operate within the SMS 2003 environment, it needs a mechanism to deliver advertisements to the clients. The Advertised Programs Agent provides just that mechanism. When designing your SMS hierarchy, you should always take into consideration that you will want the infrastructure to support software distribution. Most additional features of SMS 2003 require its use. Patch management, OS deployment, and software installation are prime examples.



In the Advertised Programs Client Agent Properties dialog box, choose to enable this agent. The section for the Legacy Client contains two settings. The first allows the clients to alter their agent settings. If you allow the clients to alter these settings, they may specify alternate intervals for the program-polling interval. This may be insignificant, but a long interval will reduce the response time in getting software out to your clients, and a shorter interval will place additional load on your site server, network, and client machine. Typically, SMS administrators deselect this option. The Advanced Client settings section allows you to configure the polling cycle time; by default, it is 60 minutes. The bottom check box enables the display of new program notification in the Add/Remove Programs applet in the Control Panel. The Notification tab configures how the client will be notified of newly available advertised programs. I try to streamline the notification processes, only bothering the user with notifications and sounds when really necessary, such as when a patching activity needs to take place or the computer needs to be rebooted. Keep in mind that if you do not notify the users of such installation activities, they may shut down, restart, or otherwise interrupt the processes. These notification options are fairly self-explanatory. The Display a Notification option pops up a message stating that a newly advertised program is available. The Play a Sound option provides a beep to notify users. When used frequently, beeps can be annoying. The next section in the Notification tab allows you to configure how the scheduled program behaves just before it is about to run on the client machine. You can provide a countdown of a specific length of time, which is 5 minutes by default. Adjust this to suit your users. You can also choose when countdown sounds are played. I suggest setting such sounds for only at the beginning and end, to avoid annoying the user. If you choose none of these options, the user experience is streamlined, since less information on the activity is passed to the user.

Legacy Client Advertised Programs When you enable the Advertised Programs Agent on a Legacy Client, it places the Advertised Programs Wizard and the Advertised Programs Download Monitor in the client’s Control Panel. Opening the Advertised Programs Wizard triggers a check with the Client Access Point (CAP) for new advertisements and displays the available advertisements for that client. The Advertised Programs Monitor provides the ability to view the progress and status of existing advertisements that are available to the client. If you enabled the client to have permission to alter the polling cycle, the user may do so from this applet.

Advanced Client Advertised Programs When you enable the Advertised Programs Client Agent, it adds the Run Advertised Programs and Program Download Monitor applets for Advanced Client systems. Users should also see a new section in the Control Panel’s Add/Remove Programs applet: Add New Programs/Add New Programs from Your Network. SMS 2003 directly integrates with the Add/Remove Programs applet to show programs that it has available for installation. The Run Advertised Programs applet allows users to view and run the available advertised programs for the client. The users cannot refresh the policy from here, although they can use F5 to refresh the list of available programs. Users may click the Properties button to view some of the detailed information that may have been entered about the package and advertisement. If the selected program requires users to download the package prior to installation, a Program Download Required dialog box appears. This allows the users to view the details of how long the download will take, start the download process, and select whether or not it should start executing the program immediately after the download completes. If the advertisement comes with a mandatory schedule with a finite date and time for the installation, the dialog box may not be presented. In this case, the download takes place automatically in the background without any user intervention.

53


54


The Program Download Monitor allows users to view the progress of the package download. It shows the name and size of the package being downloaded. This is particularly effective when performing OS upgrades using the SMS Operating System Deployment Feature Pack. By doubleclicking the program being downloaded, users can see further details of its progress.

Software Metering Agent Software metering is an effective tool to determine usage patterns for specific applications. Typically, this information is used to evaluate licensing requirements, allowing to you to see which users are using an application on a regular basis. The software metering function has changed significantly since previous versions of SMS. It has had an entire code rewrite, complete with changes in functionality. No longer is there an option to perform restrictive software metering. It is a real pleasure to use this revision of the Software Metering Agent in comparison to previous versions, where hardware requirements made it almost prohibitive to operate. There is not too much to configure for the Software Metering Agent. The real magic of the software metering happens as you define rules to describe the software that you wish to meter.

■Tip One drawback to using software metering is the task of creating rules for various software packages. This is another example of where the SMS community has stepped up and provided a solution. The Code Repository from Ron Crumbaker (http://www.myitforum.com/articles/1/view.asp?id=8645) provides a massive library of scripts. A specific script set automates the creation of software metering rules for you. The Software Metering Client Agent Properties dialog box has two tabs. The General tab contains only a check box to enable it. The Schedule tab allows you to configure two separate schedules: Data collection cycle: This cycle controls how often the client will send its collected softwaremetering information to the site server. By default, it performs this operation weekly. The default is typically adequate; however, your business needs may dictate a different schedule. Metering rules download: This schedule controls how often the client will download the defined rules list. This list contains the parameters of the applications that are to be monitored. The default value of 7 days is usually acceptable, unless you are likely to be making many adjustments to the rules.

Configuring Connection Accounts SMS 2003 has greatly reduced the need for domain-wide use of accounts for both the site systems and clients. This leads to a more secure computing environment and, overall, a simpler configuration process with fewer “moving parts” to break. SMS 2.0 always seemed to have a locked-out account of some sort. The elimination of these accounts has greatly enhanced the stability of the product. However, you still need to configure a few connection accounts. The Connection Accounts node under Site Settings contains Client and Site System branches. You may add a new client account by right-clicking Client and choosing New. Adding an account here will allow you to specify which account to use when accessing DPs and CAPs. You may add tighter permissions for your DP shares by specifying this account to have access to them. I recommend that you specify two accounts in case one is locked out. Also make sure that these accounts are not configured to require password changes on any basis.



The Site System account is needed only if your SMS 2003 site is running in standard security mode rather than the preferred advanced security mode. If you are in standard mode for any reason, be sure to configure the account that SMS will use.

Configuring Discovery Methods As discussed in Chapter 2, you can choose from the following client discovery method types: • 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 To enable and configure a discovery method, expand the Discovery Methods node under Site Settings, right-click the discovery method you wish to use, and select Properties.

Network Discovery In the Network Discovery Properties dialog box, select from three types of discovery options: Topology: Allows you to discover subnets and network devices that have a Simple Network Management Protocol (SNMP) agent. The subnets that Network Discovery scans are listed on the Subnets tab on the Network Discovery Properties dialog box. The padlock symbol next to each of the subnets indicates that SMS has found this subnet already. Topology and Client: Allows you to discover other IP devices within the subnets and domains that you specified. After the device is discovered, it is displayed under Collections in the SMS Administrator console, with its IP address as its name. You can configure the topology and client for Network Discovery by using the following tabs in the Network Discovery Properties dialog box: Subnets, DHCP (available only if your SMS 2003 site is operating in Standard security mode), SNMP, SNMP Devices, and Domains. Topology, Client, and Client Operating System: Allows you to discover subnets, IP devices, and client OSs within the defined subnets and domain names that you specified earlier. You can configure the topology, client, and client OS for Network Discovery by using the following tabs in the Network Discovery Properties dialog box: Subnets, DHCP (available only if your SMS 2003 site is operating in standard security mode), SNMP, SNMP Devices, and Domains.

■Note Windows 95, 98, and Millennium systems are displayed as Windows 9x after the Network Discovery method runs. This is due to a limitation of the LAN Manager that is running on those systems. After the SMS client is installed, the full and correct version of Windows will be displayed. You can specify the discovery scope, and enable and configure a combination of discovery options by using the tabs in the Network Discovery Properties dialog box, as follows:

55


56


Subnets: You will see a list of subnets on the Subnets tab. Network Discovery lists the subnets that it found during each previous discovery and tags them with a padlock icon, which indicates that they cannot be modified or deleted. In this list, you can enable and disable the subnets that you want discovered during the next discovery cycle. Note that you cannot delete or modify the subnets once Network Discovery finds and lists them. You can add other subnets for discovery by clicking the Add button and specifying the desired subnet IP and mask. By default, the Network Discovery method attempts to discover the local subnet of the SMS site server. You can disable this by deselecting the Search Local Subnets check box on the Subnets tab. Domains: This tab is used to configure the Network Discovery method to discover computer systems in the current and specified domains. You can specify additional domains by clicking the Add button and typing in the domain name that you want to discover. By default, the Network Discovery method attempts to discover the computer systems in the local domain by using the Windows Computer Network Browser service. You can disable this by clearing the Search Local Domain check box on the Domains tab.

■Note

If you run the Network Discovery method with all the options disabled except options on the Domains tab, Network Discovery will not create a discovery data record for the computer systems it finds. Without a discovery data record having been created, the Client Push Installation feature cannot be used to install the client. To use both Network Discovery and Client Push Installation to install your SMS clients, you must configure options on one or more of the DHCP, SNMP, and Subnet tabs. SNMP and SNMP Devices: In order to gather data from SNMP devices, you must specify the SNMP community names that Network Discovery will use to access SNMP-enabled devices. The Network Discovery method will cycle through all of the listed names you entered as community names until it finds a name that can be used successfully. If none is successful, it will stop the discovery attempt on that device. If you remove the public community name and have no other community names configured, SNMP is not used for network discovery. DHCP: You will see this tab only if your SMS 2003 site is running in standard security mode. You can configure which Microsoft Dynamic Host Configuration Protocol (DHCP) servers the Network Discovery method will gather data from by typing their IP addresses on the DHCP tab. If you want to prevent Network Discovery from discovering your own site server’s DHCP server, simply disable the Use Local DHCP Servers option or just ensure that your site server is not also a DHCP client. It is prudent not to use DHCP assignment of an IP address for SMS servers, unless you use DHCP reservations.

■Caution

A hard lesson learned: SMS 2003 will gather data only from Microsoft DHCP servers, not from any third-party DHCP servers such as a UNIX- or Linux-based DHCP server. Schedule: You can use the Add button on the Schedule tab to create a scheduled time that specifies the discovery duration and date/time to start Network Discovery. When you select a start time, Network Discovery begins at the scheduled time. When the scheduled discovery time arrives, the Network Discovery method uses the configuration that is currently specified. You can specify how long the discovery method operates by entering a duration value. This is of value if you run Network Discovery on a larger network and risk that the discovery may extend into protected production hours. You can make sure it stops at a specific time, even though it may not have completely finished.



Heartbeat Discovery You can configure the scheduled time for SMS to generate updated discovery data records (DDRs) in the Heartbeat Discovery Properties dialog box. On the General tab, you can configure the discovery schedule. You can set a full schedule so that all clients report their discovery data at a specific time on a regular basis. A full schedule specifies that all clients should execute the process or method at the same time, simultaneously. If you have a large SMS site, you should avoid this full schedule, as there will be a heavier than normal load at a particular time. You should make sure that you do not configure the Heartbeat Discovery schedule for a frequency that is less than the frequency at of the client refresh cycle runs (by default, every 25 hours); otherwise, the SMS site will receive Heartbeat Discovery DDRs at a lower-than-expected rate. You should keep the Heartbeat DDRs coming in a longer cycle than the client refresh cycle operates—longer than every 25 hours. One week is more than sufficient for most organizations.

■Note

The Heartbeat Discovery method does not generate new DDRs; it only updates existing client DDRs.

Windows User Account Discovery and Windows User Group Discovery In the Windows User Account Discovery Properties dialog box or the Windows User Group Discovery Properties dialog box, you can specify the domains that the discovery methods will scan for domain users and groups. You can configure the frequency at which the method scans by clicking the Schedule button on the Polling Schedule tab. These methods generate a new DDR for all user or group accounts in each domain as they are scanned. If you select Run Discovery As Soon As Possible on the Polling Schedule tab, the discovery method will execute immediately after the change is applied.

Active Directory Discovery Methods When configuring the Active Directory System Discovery, Active Directory User Discovery, or Active Directory System Group Discovery method, you must specify at least one Active Directory container name for the discovery method you have enabled. When the scheduled Active Directory discovery method executes, it polls the closest Active Directory resource to discover the systems, users, or system groups in the container that you specified. After you have specified which Active Directory containers to scan, you must specify whether to scan recursively. When scanning recursively (the default), the method will find objects that are stored in the Active Directory containers that you specified, and it finds any subcontainers. You may specify a specific domain controller by identifying the Active Directory container using a query with the following syntax: LDAP://<servername>/DC=<domainname>,DC=,DC=<second tier DNS name>,DC= Similarly, you may want to ensure that the Active Directory discovery method uses the Active Directory GC. To do this, specify the Active Directory container by using a query with the following syntax: GC://DC=<domainname>,DC=,DC=<second tier DNS name>, DC=

57


58


Client Installation One area that has changed greatly in SMS 2003 in comparison to previous versions is in the area of client distribution and installation. SMS 2003 has made great steps forward by making the whole process easier and quicker.

Meeting the SMS 2003 Advanced Client Prerequisites As with any software, the SMS 2003 Advanced Client has a list of prerequisites that need to be met for optimal functionality. Some of these prerequisites boil down to common sense, but need to be addressed regardless. Most of these prerequisites are easily met when an OS is installed with the default settings. However, locked-down systems, such as those where the default shares have been removed, may need some reconfiguration before installing the Advanced Client. The following are the prerequisites for Advanced Client installation: • Any machine being targeted for client installation must be powered on and attached to the network. • Your DNS must be healthy and operational, assuming that the Active Directory schema is being extended for SMS 2003. • The minimum Windows OS is Windows 2000 SP2. Older OSs must use the Legacy Client.

■Note

SMS 2003 SP2 has changed the minimum requirement for the Advanced Client. The minimum for SP2 is Windows 2000 SP4. • The Client Push Installation properties must be populated with the account that you want to use to perform the initial connection to push the client. This account must be a member of the Local Administrator group on the client machine. • The default shares, specifically the ADMIN$ share (x:\windows or x:\winnt, where x: is the drive where the OS been installed) must exist. The SMS site server machine account specified earlier must have access to the ADMIN$ share in order for CCMSetup.exe to bootstrap Client.MSI down to the Advanced Client. There should be a minimum of 100MB on the ADMIN$ share (formatted with NTFS) in order for the SMS Advanced Client to install and operate correctly.

■Note

The ADMIN$ share is a default Windows share that is hidden from view. The dollar sign ($) indicates that a share is hidden. • The IPC$ share must be enabled. The IPC$ share is used for temporary connections between the clients and the servers by using named pipes for communications. • To support file, print sharing, and named pipe communications via SMB, the Server service must be enabled and started. • In order for the Client Configuration Manager (CCM) process to work correctly, the Remote Registry Service must be enabled and running as the NT Authority\LocalService. • The WMI and BITS services must be enabled and running using the local system context.



• If any of the machines are multi-homed, they cannot exist on different IP subnets. 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. If they are multi-homed onto different IP subnets, the SMS Advanced Client will not obtain consistent policy downloads, including new software applications. • Since Advanced Clients cannot roam to other forests, the client machine must be a member of the forest in which its primary site and resident MP resides. • Ensure there are no conflicting Group Policy objects (GPOs) in place that may impair any of the previous prerequisites.

■Note

If you already have SMS 2.0 installed, you can also install the Advanced Client through advertised software distribution. You might also use this method to replace an existing tool set that has software distribution features. You will use this method when upgrading the SMS Advanced Client to a newer version, such as upgrading it from the Gold version to the SP1 or SP2 version.

Using Client Push Installation To automatically install the Advanced Client, you can use the Client Push Installation method. In the SMS Administrator console, drill down through the Site Database and Site Hierarchy nodes to the site that you wish to configure, expand the Site Settings node, and expand Client Installation Methods. Right-click Client Push Installation and select Properties to open the Client Push Installation Properties dialog box, shown in Figure 3-4.

Figure 3-4. Client Push Installation Properties dialog box Place a check mark in the Enable Client Push Installation to Assigned Resources check box to have the SMS Advanced Client pushed out automatically to your clients.

59


60


The System Types section allows you to specify the system types that will or will not be automatically installed by the Client Push Installation process. This does not prevent you from installing the client on those systems left unchecked by some other process; it only restricts the Client Push Installation process from doing so. Think twice about which systems to target, specifically servers and domain controllers. A discovery method must execute first to generate the appropriate request to process the installation. Then, based on the settings contained here, the system will have the client pushed to it as long as it is assigned to this site. The discovery method generates a file called a client configuration record (CCR). This CCR is processed by the CCM process. You can watch this process and file in action by opening the x:\SMS\inboxes\CCR folder (where x: is the drive where SMS 2003 has been installed). You will see the collection of the CCR files line up as a discovery method fires. As they are processed, at a maximum of ten at a time, they move into the inproc folder for the duration of their processing time. After they are successfully processed, the CCR files are removed from here and replaced by the next CCRs waiting in line. However, any CCRs that fail are recycled into the CCR.retry folder. They are stored there until they are retried, up to 160 times. Examining the CCM.log file, within x:\SMS\Logs, will give you insight into the workings of this process. Any errors will also be reported in the CCM status messages within the SMS 2003 console.

Installing a Client Manually You may choose to install the SMS 2003 Advanced Client manually at some point. This is not difficult to do. Simply browse to the \\SiteServer\SMS\Client\i386 location and execute CCMSetup.exe. This will install the client using the defaults that you have specified in the SMS console. It also uses BITS to perform the download of the client installation MSI, called Client.MSI, which is 7MB in size. CCMSetup.exe is only 252KB. It will execute quickly and determine if the SMS client is already installed, and if necessary, spawn the transfer of Client.MSI and execute it. CCMSetup.exe has a number of switches, most of which are passed to the Client.MSI installation process. You may alter many of the client setup program’s properties using these switches, which are listed in Table 3-2.

Table 3-2. CCMSetup.exe Switches

Switch

Description

/?

Displays the CCMSetup command-line help.

/source:<path>

Specifies the source location for downloading the installation files. You may specify one or more locations by UNC path or local path.

/mp:<machine>

Specifies the source MP for downloading the installation files. You may specify multiple MPs.

/retry:<minutes>

Specifies the number of minutes in each retry interval. The default value is 10 minutes.

/useronly

Specifies that the execution of CCMSetup.exe should happen in the user’s context. The user must have the correct privileges to perform the installation, or it will fail.



Table 3-3 shows some of the installation properties that may be also passed to the client installation process. These are Windows Installer properties that are passed through the CCMSetup.exe process to the MSI installation that takes place.

Table 3-3. Commonly Used CCMSetup.exe Installation Properties

Property

Description

DISABLESITEOPT=[True|False]

Disables the ability of end users with administrative credentials on the client computer to change the Advanced Client’s assigned site using the Systems Management icon in the Control Panel.

DISABLECACHEOPT=[True|False]

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.

SMSDIRECTORYLOOKUP=[True|False]

Enables/disables Active Directory lookup for the MP.

SMSFULLREMOTETOOLS=[0|1]

Enables Remote Tools with default settings when set to 1.

SMSMP=<ServerName>

Defines the MP for the client.

SMSNOWINSLOOKUP=[True|False]

Does not search WINS for an MP.

SMSSITECODE=XXX

Define the site code for the client.

You may manually execute Client.MSI to install the client, but you will lose a couple items of functionality. Since it is an MSI-based installation, you should maintain the installation location for self-healing purposes, and that’s harder to do if you just execute the MSI manually. CCMSetup.exe saves a copy for just this purpose. Also, you are hitting the network with a request for 7MB using SMB rather than the more efficient BITS.

Installing a Client with a Machine Startup Script Since you may not be able to discover every client on your network successfully, you may want to implement a fail-safe method of catching the systems that are not discovered. This will also aid in any system that has had some extended lockdown processes performed against it, such as removing the default shares. So why use a machine startup script? You likely want to install the SMS client on the machine as soon as it boots onto the network. Instead of waiting for a user to log on to the system and trigger a logon script, the machine script executes as the machine is starting up. You can build some logic into the script to check that the client is not already installed, and not transfer CCMSetup.exe to the client system unless it’s necessary. You can use the following Visual Basic (VB) script as a starting point. Be sure to replace the name specified by the SiteServer variable in the script to include your own site server’s name. This can also be configured to execute the client installation from a variety of locations such as a Distributed File System (DFS) point or Sysvol (Active Directory’s System Volume folder) location.

61


62


'----------------------------------------------------'----------------------------------------------------'- SMS 2003 Client Installation Script '- To be used as a Machine startup script '- that checks for the existence of the '- SMS2003 Client before spawning the '- Client Access PointINST.exe process. '----------------------------------------------------'----------------------------------------------------Option Explicit Dim FSO, WSHShell, SysFolder, ClientInst, objNetwork Dim colSystemEnvVars, computerName 'Set up our object environments Set WSHShell = WScript.CreateObject("WScript.Shell") Set FSO = CreateObject("Scripting.FileSystemObject") Set objNetwork = Wscript.CreateObject("Wscript.Network") Set colSystemEnvVars = WSHshell.Environment("System") 'Get Computer Name for logging 'computerName = objNetwork.ComputerName 'Read SYSTEM32 folder location into variable Set SysFolder = fso.GetSpecialFolder(1) 'Check to see if SMS2003 Client executable exists If FSO.FileExists(SysFolder & "\ccm\ccmexec.exe") Then 'Msgbox "Client Already Installed" 'quit WScript.Quit(0) end if 'Msgbox "Installing Client" 'Launch the SMS2003 client installation, Client Access PointINST.exe, don't wait for 'it to exit WSHShell.Run "\\SiteServer\SMSClient\i386\capinst.exe", 1, false 'Quit WScript.Quit(0) '----------------------------------------------------'----------------------------------------------------You may also use a VB script or other scripting method to manually generate the text file that contains the same information as in the CCR file (see the upcoming “Troubleshooting Client Installation” section for an example of a CCR file). These files can be manually inserted to the inbox\CCM folder and will be processed. This is a rather indirect method, but demonstrates the flexibility in performing client installations. By placing the CCRs manually, you may do so at a secondary site level, leaving that secondary site to perform the client installation process. Normally, this occurs from the primary site level.



Imaging Computers with the SMS 2003 Advanced Client Preinstalled You may wish to include the SMS 2003 Advanced Client as part of your base operating system image. If you are already using Microsoft’s Business Desktop Deployment (BDD) Solution Accelerator, you may be set up to perform this task automatically. For those who have not yet embraced the BDD Solution Accelerator, there is still a fairly easy process to follow: 1. Choose which system you are using as your Base or Gold image. On this system, install the Advanced Client using CCMSetup.exe but with the CCMSTARTSERVICES=FALSE option: CCMSetup.exe CCMSTARTSERVICES=FALSE 2. Check that the SMS Agent Host service isn’t running. If it is, type the following at the command prompt. Net stop ccmexec 3. Execute the Ccmdelcert.exe tool from the SMS 2003 Toolkit 2 (available from http:// www.microsoft.com/smserver/downloads/2003/tools/toolkit.asp). The tool deletes any security certificates from the client. 4. Shut down your Base or Gold system. 5. Using your preferred imaging software, create the image of the Base or Gold computer. 6. Test the image by restoring the image on a test destination computer.

Resizing the Advanced Client Cache The SMS Advanced Client cache is where any package that is configured to be downloaded and then executed is stored. Typically, a cache of several hundred megabytes is adequate. However, if you are storing larger applications, you may need to resize the cache to make sure that they can be contained within that space. This is fairly easily done by a simple SMS advertisement. The following VB script resizes the Advanced Client cache so it is large enough to contain an operating system image. Alter the TotalSize value to any value you require, but do remember that it is in megabytes. Set ui = CreateObject("UIResource.UIResourceMgr") Set cacheInfo = ui.GetCacheInfo cacheInfo.TotalSize = 2000 ' Change maximum size to 2GB (approx)

Troubleshooting Client Installation If you need to troubleshoot the Advanced Client installation process, you can start by checking the SMS 2003 log files.

■Note

To view SMS log files, you are well advised to install the SMS 2003 Toolkit (http://www.microsoft. com/smserver/downloads/2003/tools/toolkit.asp). It contains extremely valuable tools, including SMSTrace32, which allows you to view SMS log files as they are updated. The result is a view of the log file in real time as it has updates posted to it.

63


64


Once the Client Push Installation is initiated, a CCR file is generated for that client. The CCR filename is made up of a random code, plus the .CCR extension. Figure 3-5 shows an example of a CCR file in the inproc folder.

Figure 3-5. A pending CCR waiting to be processed Open the CCM.log file to view the progress, or lack of progress, of the Client Push Installation process. In the sample log file shown in Figure 3-6, you can see the start of the process at line 2, Received request:..., followed by a series of error messages at the bottom of the log file. Error 53 indicates that the client was not found on the network. Typically, this is caused by the client machine being currently powered off. Since there is a retry process, you can hope that the machine will be powered on by the time of the next attempt.

Figure 3-6. The CCM.log file during an unsuccessful SMS 2003 Advanced Client push



If the initial installation attempt is unsuccessful, the CCR file is placed in the ccrretry.box folder. It is stored in this location until it is cycled again for a retry, when it is placed back into the ccr.box\inproc folder. The CCM process performs this action automatically without your intervention. The CCR file is renamed once it is placed into the ccrretry.box folder, so you can see which machine it refers to, as shown in Figure 3-7.

Figure 3-7. A CCR waiting for a retry While the CCR file is waiting to be retried, you can examine its contents. Since the CCR file is a simple text-based file, you can open it with Notepad. Here is an example of a CCR file for a failed installation attempt. [NT Client Configuration Request] Forced CCR=FALSE PushClientEvenIfDC=FALSE Info CCR=FALSE Machine Name=WINXPPRO1 Initial Request Date=10/13/2005 12:32:42 [Request Processing] Latest Processing Attempt=10/13/2005 12:33:29 Last Error Code=53 Number of Processing Attempts=1 [IDENT] TYPE=Client Config Request File The first section in the CCR file, NT Client Configuration Request, contains information about the machine and the push parameters that it was created under. The Request Processing section shows the latest status of the CCR process. In this example, you can see that the last attempt at 10/13/2005 ended with an error 53 (host not found on the network). You also see that this was its first attempt, as shown by Number of Processing Attempts=1. The last section, IDENT, defines the type of file; in this case, Client Config Request File (CCR file).

65


66


■Note

If a client is offline, or the CCR was generated due to a computer account that should have been removed, the CCR file will stick around for some time. You may periodically clean up the retry folder by manually deleting the CCRs that you find in there. They should age out by themselves, but the manual cleanup is sometimes necessary to aid in your own troubleshooting efforts. When the machine that you are trying to push the SMS Advanced Client to comes back online, the CCM process will retry the installation after its retry interval transpires. You can see the retry process in the CCM.log. The process first tries to connect to the default shares to see if the Advanced Client is already installed, and then retrieves several values needed to be able to process the installation. CCMSetup.exe is copied over to a temporary folder location on the client, followed by the creation and starting of the CCMSetup as a service. This service runs under the local system context. Once this service successfully starts, the CCR process is finished. CCMSetup.exe will walk the rest of the installation process through to completion. Figure 3-8 illustrates this process in the log file.

Figure 3-8. Successful Advanced Client installation recorded in CCM.log Once the CCMSetup.exe process is underway, you can see its progress in the CCMSetup folder, located in the %system32% folder. You will see the download process of the Client.MSI file, which happens via a checkpoint/restart-type job. Once downloaded, Client.MSI will be executed to complete the Advanced Client installation. The log files that are created in this CCMSetup folder are key files to browse when you need to diagnose failed installations. They will give you insight into the point at which the failure occurred and the cause. Figure 3-9 shows the files accumulated in the client’s CCMSetup folder.



Figure 3-9. Client-side CCMSetup folder The CCMSetup.log file gives you insight into the Client.MSI transfer process and the installation and startup of the CCMSetup service. Once the Client.MSI file has finished its installation process, you will see control returned to the CCMSetup.exe process, where it will post a message in CCMSetup.Log, as shown in Figure 3-10. That line should read Installation succeeded. The last couple lines are related to housekeeping chores, such as removing files that are no longer required after the installation process. A copy of the Client.MSI file is kept on the client system, as it can be used for self-healing processes after installation of the client.

Figure 3-10. A CCMSetup.log file from a successful client installation Client.MSI.Log is the setup log file for the Advanced Client. Figure 3-11 shows a log file from a successful installation. A key indicator is the second-to-last line of the log, indicating that the main engine code, or process, has returned an exit code of 0, which is a good thing.

67


68


Figure 3-11. Client.MSI.log contents After a successful client installation, you should be able to see additional logs in the %system32%\ CCM\Logs folder, as shown in Figure 3-12. The exact number may vary depending on what agents are enabled and the exact time the client installation completed. You can check these logs to troubleshoot problems with the Advanced Client.

Figure 3-12. SMS 2003 Advanced Client Logs folder contents



Uninstalling SMS Clients On occasion, you will need to remove a site. Before removing the existing site, you will want to either move or remove the SMS clients, as described in this section.

Uninstalling SMS Legacy Clients To remove a Legacy Client, either execute the SMSMAN.exe file from the \\SMSserver\<sitecode>\ Client\i386 folder or allow the SMS Legacy Client to uninstall itself. You can achieve this by removing the site boundaries that correspond to the group of clients you are trying to uninstall. But note that if you remove the client’s subnet, all other clients in that subnet will also have the SMS 2003 Legacy Client removed. Once modified, the Legacy Client software is automatically removed from the client after the next maintenance cycle or when you restart the client computer. Be sure to plan these activities ahead of time, as the uninstallation may take some time to complete. To modify the site boundaries, in the SMS Administrator console, expand the Site Database node, then the Site Hierarchy node. Right-click your site name and choose Properties to open the Site Properties dialog box. On the Site Boundaries tab, click the subnet that you want to remove, and then choose Delete. Confirm that you want to delete the subnet, and then click OK to close the Site Properties dialog box. At this point, your SMS Legacy Clients should start to deinstall themselves after their 24-hour CCM cycle has transpired.

Uninstalling SMS Advanced Clients To uninstall an SMS Advanced Client, you can use the CCMClean utility or the Client MSI package. Although not as graceful as using the MSI package, the CCMClean utility is able to perform a good job at removing most traces of the Advanced Client. It is generally easy enough to perform an uninstall from the source MSI file. You can simply execute the MSI on a client system to manually uninstall the client. More likely, you will want to perform an unattended uninstallation, which you can do by executing the following command at the command line: Msiexec.exe client.msi /x /qbThe /x switch uninstalls the program, and the /qb- switch specifies that it is unattended (during the uninstallation process, a progress bar appears, but there is no Cancel button). A simple command like this is easy to distribute with SMS 2003, provided your infrastructure is set up and running. If you do not have a working SMS infrastructure, you may want to use a stronger method of removing the SMS Advanced Client, which calls for the CCMClean.exe tool. The CCMClean tool, available in the SMS 2003 Toolkit, allows for the easy and complete removal of the SMS 2003 Advanced Client. You can run it in stand-alone mode for a manual process or make it operate in unattended mode. Table 3-4 lists the command-line switches for CCMClean. Typically, you would execute a command like this: CCMClean.exe /client /q /retry:5,60

69


70


This would produce a silent cleaning of the SMS Advanced Client that would retry five times, with a delay of 60 seconds between each retry.

Table 3-4. CCMClean.exe Command-Line Switches

Switch

Description

/?

Displays help

/client

Removes the SMS Advanced Client (default)

/mp

Removes the SMS MP

/all

Removes both the SMS Advanced Client and MP

/logdir:

Sets a location where to place the log file (by default, the Temp folder)

/logbackup:

Sets a location where to back up the existing client and/or MP logs

/removehistory

Removes software distribution and inventory history during client removal

/q

Makes the tool execute quietly by suppressing the user interface

/retry:,

Enables the retry if Windows Installer is busy; retries n times with an interval of t seconds

Secondary and Child Primary Site Installation As discussed in Chapter 2, your SMS 2003 site design may call for secondary sites and additional SMS 2003 primary sites, all connected to a primary parent site.

Installing Secondary Sites Secondary sites are most likely the easiest SMS site you will have to deal with. The main reason for this is that you do not have to worry about SQL Server at these locations. Before you jump in and add secondary sites, you must deal with the issue of permissions. As explained in the “Security and Permissions” section earlier in this chapter, SMS 2003 operates with one of two security models: standard security, which is user account–based, and advanced security, which uses computer accounts. Advanced security mode is preferred, as it is simpler and easier to configure. There is one catch though: to add a site to a role, you need the appropriate permissions. If you are operating in advanced security mode, you can ensure the SMS server has appropriate permissions to add a site by adding an account to either of the following groups: Domain Administrators group: Add the server computer account to the Domain Administrators group. By specifying that the primary site server’s computer name is a member of the Domain Administrators group, you allow it to have the privilege of accessing another domain server and installing its required components. When performing this action with the Active Directory Users and Groups MMC, be sure to change the Object Types to include Computer accounts. You must reboot your primary site server to allow this group membership change to take effect.



Local Administrators group: Alternatively, if the previous solution leaves a little too much room for security issues in your organization, you may take the opposite route. Add the primary site server’s computer name only to the member server’s Local Administrators group. The member server must be rebooted for this change to take effect. This has the potential to require reboots of one or more server systems as they are added to the role of secondary site server. After the appropriate permissions are in place, you may start the actual process of installing the secondary site. Here are the steps: 1. In the SMS Administrator console, expand the Site Database node, then the Site Hierarchy node. 2. Right-click the primary site name and select New ➤ Secondary Site, as shown in Figure 3-13.

Figure 3-13. Choosing to create a new secondary site 3. The Secondary Site Creation Wizard starts. Enter a site code and site name, as shown in Figure 3-14. The site code is limited to three characters. You may enter a longer name and description in the other fields. Click Next to continue. 4. Enter the domain where the secondary site server resides, followed by its NetBIOS name. Ensure the platform is correct. Typically, you won’t install the site server’s SMS folder to the C: drive. Choose another drive that is more suitable, such as the D: drive, as shown in Figure 3-15. Click Next to continue.

71


72


Figure 3-14. Specifying the secondary site code and name

Figure 3-15. Specifying secondary site server information 5. You have two source file options when installing a secondary site server. If you are placing this server at a site connected by a small or heavily used WAN link, choose the CD option. Then you can send the CD to the site and copy the source files to the secondary server. If you are setting this up in the lab, or a bench environment, and then shipping the server out after it is ready, you can choose to have the source files copied over the network and not worry about the CD media option. Ensure the CD is mounted in the optical drive when you select to install source files from this CD. Click Next to continue. 6. Choose a security mode (typically, Advanced), and then click Next to proceed. 7. Since this is a secondary site, you need to ensure there is a way for it to communicate with its primary site. Specify an address you’ve already configured, or allow the installation process to create a new address to the secondary site server. Click Next to continue. If you chose to use an existing address, skip to step 10.



8. If you chose to create a new address, the next wizard page will ask for the address type (typically the Standard Sender) and the name of the destination site server (your new secondary site server), as shown in Figure 3-16. You may specify an account. If you leave the account as the default, SMS will use the machine or computer account, which is the preferred method. Click Next to continue.

Figure 3-16. Specifying the address to the secondary site 9. Specify an address to the primary site server. Choose the address type, enter the parent’s site code, and set an account to use (if you are not using the computer account), as shown in Figure 3-17. Click Next to continue.

Figure 3-17. Specifying the address to the parent site

73


74


10. At this point, you have entered all the information required to install the secondary site server through the SMS Administrator console. Verify the information you entered at this point, and then click Finish to start the installation process. The dialog boxes will disappear, and the new secondary site will appear in the SMS Administrator console. There will be an hourglass associated with its icon until it has finished processing the installation. Figure 3-18 shows an example of a drive where a secondary site server will be installed during the installation.

Figure 3-18. Secondary site file structure during installation Once installation is completed, the same drive should look similar to Figure 3-19. While in the SMS Administrator console, you should be able to open the secondary site in the same way that you open any other SMS site.

Figure 3-19. Secondary site file structure after installation is completed



Installing Child Primary Sites Unlike secondary sites, additional primary sites cannot be installed from the SMS Administrator console. This server must meet the same prerequisites as a parent primary site, including SQL Server and IIS and its components installed on this machine. The installation of a child primary site is identical to that of a parent or regular primary site. Just execute setup.exe from the SMS 2003 source media (CD) as you did for your top-level primary site. Be sure to set the database size options appropriately for the number of clients you expect for this specific site. If you are creating a primary site to be a parent of another site, size it accordingly (the sum of all child site clients). Once the new site is installed, you can connect it to its parent site. Note that this process can involve transferring a lot of data. It is a good idea to complete this connection during off-peak hours or through a highly restricted address. And remember that you can assign schedules and bandwidth allocations to child sites. Follow these steps to connect your sites: 1. On the parent primary site server, create an address for this child primary site server. Also create an address for the parent primary server on this child primary site server. 2. Open the SMS Administrator console. Expand the tree in the left pane to show the Site Hierarchy and then your new child site, as shown in Figure 3-20.

Figure 3-20. SMS Administrator console showing primary site 3. Right-click the site and choose Properties to open the Site Properties dialog box for the child primary site, as shown in Figure 3-21. Click Set Parent Site.

75


76


Figure 3-21. Site Properties dialog box for the child primary site 4. Select the Report to Parent Site radio button, and then enter the site code of the parent site. Click OK. 5. You will be returned to the Site Properties dialog box. As shown in Figure 3-22, the Parent Site field now indicates the parent site you specified. Click OK.

Figure 3-22. Site Properties dialog box for the child primary site with the parent site defined



It will take a few minutes for the newly created site to appear in the parent site’s console; an existing site with data in it will take longer to appear. Initially, a flood of database information will be transferred across the link. Once SMS has the sites sorted out, you will see the new child site listed one level below its parent site in the SMS Administrator console, as shown in Figure 3-23.

Figure 3-23. SMS Administrator console showing the child primary site from the top-level primary site

Adding Site Systems When you add new SMS 2003 sites to your hierarchy, you will not doubt need to add specific site system components to them. When adding a site system, you typically choose the server you want to configure and add the appropriate role. The SMS 2003 roles and their prerequisites were covered in Chapter 1. You may add these roles to an existing SMS site server or distribute them to various member servers at strategic locations in your enterprise. By default, site server systems shows site systems, but you may add existing member servers.

■Note

Most of the SMS 2003 roles or components are MSI-based installations and can be uninstalled or rolled back safely if an error occurs. You can start this configuration at a parent or child primary site (if it is a secondary site, you must work from its parent primary site). Begin by opening the SMS Administrator console and drilling down to the Site Settings branch for the primary site, as shown in Figure 3-24. Choose the server for which you want to modify the site system roles in the right pane. Double-click it to open the Site System Properties box. As shown in Figure 3-25, the dialog box should show tabs for each potential role. Click the tab for the role you want to add, as described in the following sections.

■Note If the server is not listed under Site Systems, right-click in the right pane and choose New. Choose either Server or Server Share. Choosing Server will prompt you to set the member server’s name and continue the configuration process. Choosing Server Share will prompt you to enter the member server’s name and share name. The Site System Properties dialog box will look similar to Figure 3-25, but will limit you to adding only CAP and DP roles to that server share location.

77


78


Figure 3-24. SMS Administrator console showing the Site Systems branch

Figure 3-25. Site System Properties dialog box

Reporting Point To select the RP role for the site server, click the Reporting Point tab in the Site System Properties dialog box and place a check box in the Use This Site System As a Reporting Point check box, as shown in Figure 3-26.



Figure 3-26. Adding an RP Additionally, you may choose to alter the root folder that you have used for SMS reporting, use your HTTPS infrastructure to provide secure access to reports, and change the port the reporting website uses (the default is port 80). Typically, these settings are left as default, unless there is a specific business reason to change to another port. It is best to make this design decision early on, as it can be a hassle to change all your client systems to a new port once they have been deployed. If the system on which you are attempting to install the RP does not have IIS already installed on it, the installation will fail. You will see SMS status messages indicating the problem, as well as entries in the server’s log file, RSetup.Log (in the %SMS%\logs folder). Correct the issue, and the installation will retry and succeed.

Server Locator Point To select the SLP role for the site server, click the Server Locator Point tab in the Site System Properties dialog box and place a check in the Use This Site System As a Server Locator Point check box, as shown in Figure 3-27. The default is to use the site database for the SLP. However, if you need to use a different database, such as that of a parent site, you may set that here. Doing so will reveal several other fields that prompt you for the SQL Server name, database name, authentication type, and an account name and password. Again, if you don’t have IIS installed on the target machine, the SLP installation will fail. You can check the associated log file, SLPSetup.Log (in the %SMS%\logs folder).

79


80


Figure 3-27. Adding an SLP

Management Point To select the MP role for the site server, click the Management Point tab in the Site System Properties dialog box and place a check in the Use This Site System As a Management Point check box, as shown in Figure 3-28. You can configure one server within a primary site’s boundaries as an MP.

Figure 3-28. Adding an MP



You can accept the default to use the site database or specify another one, such as that of a parent primary site. If you select an alternate database, you will be prompted for the SQL Server name, database name, authentication type, and account name and password.

■Note

Be patient. The MP component takes significantly longer than other components to install.

Again, if the server doesn’t meet the prerequisites, the installation will fail. Along with IIS, ASP.NET, BITS, and the WebDAV components from the IIS component need to be loaded on the intended server. As with the other components, the MP installation will retry if it fails initially. The best place to diagnose MP installation problems is its associated log file, MPSetup.log (in the %SMS%\Logs folder).

Client Access Point You must have at least one CAP configured in your site, even if there are no Legacy Clients assigned to this site. To select the CAP role for the site server, click the Client Access Point tab in the Site System Properties dialog box and place a check in the Use This Site System As a Client Access Point check box, as shown in Figure 3-29. And that’s it. You don’t need to configure anything else for a CAP.

Figure 3-29. Adding a CAP

Distribution Point DPs are one of the most commonly rolled out SMS components (aside from the SMS client, of course!). They are a vital portion of the SMS infrastructure, necessary to ensure effective and efficient delivery of software packages to clients. Although they are easy enough to roll out to site systems and member servers, they don’t always install as planned. Typically, the prerequisites are not met or there is a lack of disk space to hold the quantity of SMS packages required. Additionally, if they are not protected correctly in a large environment, users from across WAN links may inadvertently access them and place a strain on WAN links.

81


82


■Tip

If you require the DP to be installed on a specific drive on a server, the best way to achieve this is to create a SMSPKG folder on that drive and share it, being sure to allow appropriate permissions. Specify a New Server Share Site System and configure the DP for that location. The DP will create a share below the specified location and share it out to clients as the SMSPKGx$ share that will contain the software packages. To select the DP role for the site server, click the Distribution Point tab in the Site System Properties dialog box and check the Use This Site System As a Distribution Point check box, as shown in Figure 3-30.

Figure 3-30. Adding a DP You can configure the DP by using the options on this tab as follows: Enable Background Intelligent Transfer Service (BITS): Typically, you will want to enable BITS for the DP. Group Membership: You may choose to create groups for DPs in your organization. This will make the task of distributing software to DPs easier down the road. Typically, I see DPs grouped together either in a physical structure (such as all North America DPs) or categorized by some logical quality (such as all BITS-enabled DPs or low-bandwidth DPs). Click the yellow star icon to create a new group, give it a name, and choose whether or not that system should be included in this group. You can use the other buttons to modify the properties of a group, delete a group, and to add or remove members from a group. Enable As a Protected Distribution Point: As discussed in Chapter 2, you can configure a protected DP, which restricts access to it. Once you select this option, the Configure Boundaries button is enabled. Click this button to see a list of the Active Directory sites and IP subnets used to configure the site boundaries. Select which boundaries you would like to be able to access this DP.



As with the other components, the installation will fail if the server system does not meet the prerequisites for a DP. If you intend to use BITS, you must load IIS and also the BITS components.

■Note If the server is a Windows 2003 or later server, BITS is an integrated piece of IIS that may be loaded at the same time. If your server is an older Windows 2000 server, you will need to download the BITS server software from the Microsoft website. Ensure it is the BITS server, not the BITS client. You should be able to find the correct version from http://www.microsoft.com/downloads/details.aspx?FamilyID=3ee866a0-3a09-4fdf8bdb-c906850ab9f2&displaylang=en. The current version as of this date of writing is version 2.0.

Site Removal On occasion, you will need to remove a site—perhaps due to a misconfiguration, a closure of a branch office, or reconfiguration of your SMS 2003 hierarchy. But don’t just turn the server off and decommission it! Before removing a site, if there are still clients at that location, you should move or remove them. If you’re decommissioning the SMS site, you should uninstall the clients first, as described earlier in this chapter. If you’re restructuring your hierarchy, you will likely want to add the boundaries of the site to be removed to another SMS 2003 site and have that site take over the management of the old site’s clients. Then take the appropriate steps in the SMS Administrator console, depending on whether you’re removing a secondary site or a child primary site.

Removing Secondary Sites When you remove a secondary site, you can choose between two methods: Delete site: Deletes the SMS site configuration for the secondary site. It leaves all SMS clients active within the SMS database. It does not uninstall the SMS secondary site software from the secondary server. It is quick and fairly safe to do. Deinstall site: Performs the uninstall process on the secondary site server. It also removes the associated SMS clients from the database. It is the most complete method. Deinstalling the site takes slightly longer than deleting it. Be sure of which approach you want to take, because the results are different for each. Follow these steps to uninstall or delete a secondary site: 1. Open the SMS Administrator console and expand the tree in the left pane to show the Site Hierarchy and then the secondary site that you wish to remove. 2. Right-click the site and select Delete. 3. The first dialog box directs you to the site you want to delete. Confirm that this is the site you to intend to remove, and then click Next. 4. Choose whether you want to delete or deinstall the site. Click Next once you have confirmed which method to use. 5. You are shown a confirmation indicating the actions about to be taken. Click the Finish button to complete the actions (the delete or deinstall operation).

83


84


Removing a Child Primary Site Server To remove a child primary site server, you reassign its parent site. Here are the steps: 1. Open the SMS Administrator console and expand the tree in the left pane to show the Site Hierarchy and then the child primary site that you wish to remove. 2. Right-click the site and choose Properties. In the Site Properties dialog box, click the Set Parent Site button. 3. Change the setting to the Central site option. Click OK to proceed with the configuration change. This will remove the site’s relationship with its parent site. 4. You will be returned to the Site Properties dialog box, which will now show that no parent site is assigned. 5. From both the child and parent sites, remove the configured addresses that pertain to each other. At this point, your primary site server has been uninstalled.

Unlocking Objects When you have set up another site as a child of another, you will see small yellow padlocks on numerous objects in the child console. This is because those are inherited objects from the parent site. The child site has no rights to modify them. These objects may be collections, advertisements, and/or packages. Unfortunately, if you happen to remove the parent site, the objects do not automatically unlock. Fortunately, many people have already felt this pain and have provided some key tools to assist in unlocking objects. Different objects require a slightly different variation in how they are unlocked, but the principle remains the same. One way to unlock objects is to use the WMI provider to manipulate these objects. This method requires the WMI SDK, which you can download from http://download.microsoft.com/download/ platformsdk/sdkx86/1.5/NT45/EN-US/wmisdk.exe.

■Note

Other methods of unlocking objects involve editing the SQL Server database tables directly. This is not always the optimal or safest route. After you have downloaded and installed the WMI SDK from the Microsoft website, follow these steps: 1. Open the WMI Object Browser by selecting Start ➤ WMI SDK. 2. Connect to your SMS 2003 site server. Use the browse function to browse to the namespace named Root\SMS\Site_<SiteCode>. If you are running this directly on your SMS site server, the WMI Object Browser will prompt you for a namespace to connect to after you open the application. Enter your namespace string in the dialog box, as shown in Figure 3-31.

Figure 3-31. Connecting to your namespace from the WMI Object Browser



3. You will be prompted for a username and password that has been granted rights to complete this connection. Make sure that you have either specified the correct credentials or are currently logged in as someone with appropriate credentials. Click OK to continue. 4. You will be prompted to select browse criteria. Scroll down the list of available classes and select SMS_Collection, as shown in Figure 3-32. Click the Add button to add it to the right pane. Choose OK to complete this step.

Figure 3-32. WMI Object Browser classes selection 5. You will be presented with a list of collections and their IDs. Select the ID of the collection that you want to remove the lock from, as shown in Figure 3-33. Click OK. 6. On the Properties tab in the right pane, you will see a list of properties for the SMS collection you selected. Double-check the name of the collection you intend to alter by viewing the Comment field in the properties list. If that is correct, select the property OwnedByThisSite. If this collection is locked, the value of this property will be false, as shown in Figure 3-34. Click the false value. In the drop-down box that appears, choose true. 7. Save your modifications by clicking the Save icon in the top-right corner of the window. 8. Close the WMI Object Browser. 9. Double-check that this performed the intended operation by reopening the SMS Administrator console and viewing the collections. The collection should no longer have a padlock on it.

85


86


Figure 3-33. Instances returned from WMI Object class

Figure 3-34. WMI Object Browser showing instance details

■Note

You can perform this same operation for other object types that may be locked in your SMS console.



Summary Like the preceding chapter, this chapter covered a lot of ground. We started by investigating the process of extending Active Directory’s schema to allow updates to be performed before, after, or during the SMS 2003 installation process. Next, we looked at security settings, including choosing either the advanced or standard security model and how to approach setting console security permissions. Then you learned about site configuration settings, covering addresses, senders, client agents, connection accounts, and client discovery methods. We also covered the options for installing the SMS client—via manual and automated processes. Next, you saw how to install secondary and child primary sites to parent sites. Because you need specific SMS 2003 server roles to be present in your SMS 2003 hierarchy, we looked at the various roles that you might assign to server systems and how to install those roles. Due to the ever-present opportunity to make mistakes or need to alter the architecture of your SMS 2003 hierarchy, you may need to remove sites. In the final section of this chapter, we explored the process for disconnecting and uninstalling secondary sites and child primary sites. We also looked at using the WMI SDK tool, WMI Object Browser, to unlock objects on child sites that were created at higher-level SMS sites and are locked at lower-level child sites.

87


Kruetzfeld_698-6C04.fm Page 89 Monday, October 23, 2006 9:31 AM

CHAPTER 4 ■■■

SMS 2003 Resource Management

O

nce you have an SMS 2003 infrastructure built and running, the next task at hand involves managing the clients that are discovered by your SMS sites. This chapter discusses how to manage your clients’ site assignment and health effectively, using not only SMS native tools, but also free third-party tools that provide additional functionality. The chapter also covers collections—how to create and manage them, plus a few strategies to get the most out of them for your specific environment.

Site Assignment SMS clients may be assigned to only a single SMS site, but they are allowed to roam to other SMS sites that are connected to the common SMS infrastructure, as explained in Chapter 2. You define which portion of the SMS infrastructure that the clients will connect to and use when they are in a specific area of the network by configuring site boundaries. As also explained in Chapter 2, you may form your site boundaries using Active Directory sites and/or IP subnets. Either can be used solely or together to form the boundaries for each of your SMS sites. You do not need to overlap boundaries by defining both the Active Directory site and IP subnet boundaries for the same network area. Include IP subnets only for areas that are not defined by Active Directory sites, or where a particular Active Directory site is not narrow enough in scope. You can configure the SMS site boundaries through the SMS Administrator console, as follows: 1. Open the SMS Administrator console, expand the Site Database node, and then expand the Site Hierarchy node, as shown in Figure 4-1.

Figure 4-1. Choosing the site for which you want to configure boundaries 89


90

CHAPTER 4 ■ SMS 2003 RESOURCE MANAGEMENT

2. Right-click the site for which you want to configure the site assignments and choose Properties to open the Site Properties dialog box. Click the Site Boundaries tab, as shown in Figure 4-2.

Figure 4-2. The Site Boundaries tab of the Site Properties dialog box 3. Click the add button (with an icon showing a yellow star) at the top right of the dialog box to open the New Site Boundary dialog box. 4. Select a type from the Boundary Type drop-down list (Active Directory site in the example), as shown in Figure 4-3. Enter the name of the site in the Site Name field. Then click OK.

■Caution

You will not be able to check or validate the name you enter in the Site Name field of the New Site Boundary dialog box, so make sure it is typed correctly. You may even want to copy and paste the text into the field to be sure it is correct.

Figure 4-3. New Site Boundary dialog box with Active Directory site chosen 5. You will see your new site boundary listed on the Site Boundaries tab of the Site Properties dialog box. Repeat steps 1 through 4 to add your other site boundaries. Figure 4-4 shows both an Active Directory site and an IP subnet boundary defined as SMS site boundaries. Don’t



forget to include VPN-based subnets if you intend to manage clients while they are connected via a VPN.

Figure 4-4. An SMS primary site with Active Directory and IP subnet boundaries defined

■Note

As you may remember, you cannot assign site clients to a secondary SMS site, but you can define site boundaries for both secondary and primary sites. These are two different concepts.

SMS Site Component Status When working with a SMS site, you should periodically check the status of its components. Within the SMS Administrator console, the SMS Component Status node summarizes your site’s health in one view. It lists each SMS component that is configured in your site and shows an icon representing the status of each one. You can drill down further to reveal each component’s status messages, on which its reported status is based. This is valuable information that helps you pinpoint failing SMS components and potential problem areas that you should investigate further. To access this information for a site, in the SMS Administrator console, drill down through the Site Database node to the System Status node, then the Site Status node. You will see the site you are currently working with listed there, plus any additional child sites associated with this site. The right panel will show the status for a couple dozen SMS components, including the core SMS Executive component, as shown in Figure 4-5.

91


92


Figure 4-5. Viewing the Component Status node in the SMS Administrator console You need to manually refresh this list to see any changes that may have occurred while viewing the list. Additionally, any changes will affect the status of the Status Summary branches in the console. You must manually refresh each level individually by pressing F5 to see the changes. To view the status messages for a particular component, right-click it and select Show Messages. As shown in Figure 4-6, you can choose to view all messages or filter the view to show only error, warning, or info messages. You will then see the messages in an SMS Status Message Viewer window, as shown in Figure 4-7. You may double-click any status message to view further details about the event.

Figure 4-6. Choosing to view the status messages for a component



■Note You may alter the thresholds at which a warning or error message is issued. To do so, in the SMS Administrator console, drill down through the Site Hierarchy, Site Database, and Site Hierarchy nodes to the site that you wish to configure, and expand the Site Settings node. Then select the Status Summarizers node. However, I don’t recommend changing these values by much, as it is very easy to dull their response to a point where you will not be able to see issues within your SMS hierarchy.

Figure 4-7. Viewing SMS status messages I recommend setting the SMS Status Message Viewer options, available in its View menu, to limit the number of messages returned and to specify an automatic refresh cycle for the message display. If you don’t limit the number of messages, it may take a long time for all the messages to be listed in the viewer, and will also add extra load on your site server. Typically, I set a refresh cycle of about 2 minutes, and limit the messages to 10 or 15. On occasion, you may need to clear the counters for a specific component’s status messages. To do so, right-click the component and select the Reset Counts option.

SMS Client Health The SMS Client Health Monitoring Tool, available as a free download from Microsoft, is a valuable asset to bring into your SMS environment. It is a fairly comprehensive tool that reports on the status of your SMS clients. This tool interprets various indications of client health by examining the SMS client’s reported inventory and discovery data. Additionally, the tool uses other methods to diagnose the reason that a client appears unhealthy or inactive. This Client Health Monitoring Tool identifies clients as follows: • Unhealthy • Online but are not currently requesting policies, have an SMS client but have SMS components that are not working, or have not updated their inventory or discovery data records within the predefined period • Offline and thus unable to perform SMS client actions such as install software or inventory operations • With duplicate SMS records and thus marked as obsolete The tool comes with several predefined reports. Its functions do not add significant load to your existing SMS infrastructure, as it operates independently from the SMS site services and uses its own SQL database.

93


94


Along with performing ping tests to see if a client is online, the Client Health Monitoring Tool performs pulse tests, which check whether the client has requested SMS policies from its MP. Setting up the Client Health Monitoring Tool is not quite as easy as installing and running an MSI. You must configure a few areas first. The following sections walk through the configuration process, and then describe how to use the reporting tools.

Setting Up the Client Health Monitoring Tool The Client Health Monitoring Tool is designed to be installed on a site-by-site basis; in the case of multiple sites, perhaps at the top-site level. You may install only one instance of the tool per computer. The following are its requirements: • The tool needs one SQL database, one SMS site database, and one Client Health database per instance. The SMS site database must reside on the same server as your Client Health database. • The tool may be installed on an SMS site server, SMS database server, or member server/ workstation. It is suggested that it be installed close to the SMS database server. • Your SMS site server must be an SMS 2003 SP1 or later site. Child sites do not need to meet this requirement, as long as you install the tool at the parent level and the parent site is an SMS 2003 SP1 or later site. • Logging of the SMS MPs must be enabled to allow the pulse tool to operate. • The SMS clients must have the Software Hardware Agent and Hardware Inventory Agents enabled, and Heartbeat Discovery enabled. • The tool requires a service account to operate. This service account must have administrator rights and also the right to log on as service on the system where it is installed. If you are installing the Client Health Monitoring tool on another machine that may have a different version of Windows, verify that system requirements meet the following criteria: • Windows XP, 2000 Professional, or Server 2003 • .NET Framework 1.1 or higher • Internet Explorer 6.0 (to view the Client Health Summary Report) • Microsoft Office Excel XP or later (to access the Client Health Pivot Table Report) • Microsoft Data Access Components (MDAC) 2.6 or later • Windows Firewall with ports TCP 139, TCP 445, and TCP 135 opened, and allow the enabling of the incoming echo request

■Note

I don’t suggest that you install the Client Monitoring Tool immediately after you install SMS 2003. Rather, plan to install it as a later phase of your SMS 2003 project.

Configuring the Client Health Service Account During the configuration of the Client Health Monitoring Tool, you can set up the Client Health Service account to use either the local system account or a specified domain user account. Each method has its benefits, but I prefer to use the local system account, as there are fewer opportunities for account password issues. If your SMS 2003 site is using the standard security mode, you should use the SMS Service account, as it already has the permissions you need on the various objects. Either way, you must specify that the account in question has the following privileges:



• Logon as a service right to the Client Health host system • Local Administrator rights to the Client Health host system • db_datawriter role on the SMS database, if you will use any of the options that update the SMS database • Database Creator role on the SQL Server where the database will reside, if you allow the tool to automatically create the database • db_owner role on the created Client Health database, if you manually create the database

Installing and Configuring the Tool Download the Client Health Monitoring Tool from http://www.microsoft.com/downloads/ details.aspx?FamilyID=D5C9DE9B-7283-42F2-BA0E-DD35F113D944&displaylang=en (yes, it is a free download and worth more than every penny). Then unzip the file and extract the ClientHealthSetup. MSI file. Double-click ClientHealthSetup.MSI to run the installation program. After the program is installed, configure it as follows: 1. Select Start ➤ All Programs ➤ Microsoft SMS 2003 Client Health Monitoring Tool ➤ Configure the Client Health Monitor Tool. You’ll see the SMS Client Health Monitoring Tool window, as shown in Figure 4-8.

Figure 4-8. Site Settings tab in the SMS Client Health Monitoring Tool 2. On the Site Settings tab, specify your SMS SQL Server, SMS site database, and Client Health database. (You may give the Client Health database any name you wish; however, you may need to retype it, so you might want the name to be fairly easy to remember and selfexplanatory.) Then specify the Client Health Service credentials, keeping in mind the considerations discussed in the previous section. Figure 4-9 shows an example of database settings and using the local system account.

95


96


Figure 4-9. Site Settings tab in the Client Health Monitoring Tool with database settings and local system credentials 3. Click the Options tab. By default, only the Heartbeat Discovery option with a period of 7 days is selected as the primary source for the health calculations. I recommend leaving this setting at 7 days, to prevent false positives. The default scope of the health check is all sites in the hierarchy. You may want to make the changes shown in Figure 4-10. By expanding the health calculation sources to include software and hardware inventories, the tool can further validate the functionality of the clients. You should generally set the period value for the hardware and software inventory as twice the schedule in your SMS site. For example, if the Hardware Inventory Agent runs every 5 days, set the period to 10 days. If you are using multiple installations of the tool in your environment, you will probably want to restrict the scope of the tool to only clients in this site.

■Note The downside of including the software and hardware inventories is that the size of your Client Health database will increase. You may want to experiment with this in a lab environment before rolling it out in your production environment. 4. Click the Schedule tab. I recommend the settings shown in Figure 4-11. You will likely want to collect pulse information from your MPs (see the next section for additional considerations regarding this setting). Enable the ping option that is restricted to only unhealthy clients. Checking the Update SMS Site Database with Inactive Client Information option will post the health information about the inactive clients to the SMS database when the active bit is set to 0 for unhealthy clients and when the obsolete bit is set to 1, marking the unhealthy clients as obsolete. Checking the Remove Aged Data option has the Client Health Service purge the Client Health records for clients that are older than the specified value. The default is 31 days, which should be adequate for most environments.



Figure 4-10. Options tab in the SMS Client Health Monitoring Tool with adjusted settings

■Caution

Collecting pulse information will place additional strain on both the MP and its network link at the scheduled time. Also, you should make sure the ping schedule is reasonable. Low usage times of the day are best; however, desktop systems tend to be powered down at that time of day. You can adjust the schedule for each by clicking the Schedule button next to the option on the Schedule tab.

Figure 4-11. Schedule tab in the SMS Client Health Monitoring Tool 5. Click the Info tab to see information about the version of the tool being used and also the status of the service, as shown in Figure 4-12. This tab will show any recent issues with accessing the database, which typically arise during setup where the db_owner role has not been added to the service account.

97


98


Figure 4-12. Info tab in the SMS Client Health Monitoring Tool 6. Click OK to save your changes and exit the configuration window.

Configuring for Pulse Information Collection If you enabled the option for collecting pulse information from your MPs, the specified service account will need to access the policy request information from Advanced Clients. The easiest way to ensure that this account has the correct permissions is to add the Client Health host system local system account to the MP’s Local Administrators group, or to add the service account to a domain security group and add that group to the Local Administrators group of the MP. This is not required if the Client Health host system is also the SMS site server, as it will already have the appropriate permissions. If you do not want to allow the security account to have Local Administrator access on your MPs, you will need to configure the MPs manually, as follows: 1. On each MP (and, if applicable, Device MP) in the affected hierarchy, share the Logs folder. The share name is not important—it might as well be hidden—but it should remain consistent on each MP. Be sure the folder has adequate permissions to allow the service account to access the log shares you create.

■Note

A Device MP is a Management Point specifically used to manage Microsoft Pocket PC or Windows Mobile devices. 2. Edit the Settings.XML file from %PROGRAMFILES%\Microsoft SMS Client Health. Locate the line containing <sMPShareName /> and change that line to read as follows (where MP_logs$ is the name of the share you defined for your MP logs directory): <sMPShareName>MP_logs$



3. Save your Settings.XML file. 4. Enable the logging of the policy requests by editing the Registry. Edit the following key: HKeyLM/Software/Microsoft/SMS/MP Add the value of LogPolicyRequests, and set it to contain a value of 1.

SMS Client Health Reporting The Client Health database will contain valuable information regarding the health of your clients. The Client Health Monitoring Tool provides two reporting tools: the Client Health Summary Report and the Client Health Pivot Table Report. Both reports classify clients as follows: Healthy: A healthy client is one that has inventory or discovery data records with dates within the specified health period (as configured on the Options tab of the SMS Client Health Monitoring Tool; see Figure 4-10). Obsolete: An obsolete client is one that has the obsolete bit set to 1 for its client record in the SMS database. This status is usually the result of suspected duplication of the client or Windows system. Suspected Unhealthy: A client that is suspected of being unhealthy requires further examination using the pulse and ping tools to provide information about the online/offline status of these clients. Unhealthy: Once the ping or pulse tool determines that a suspected unhealthy client is indeed online, it is categorized as an unhealthy client based on the assumption that if it is powered on and able to respond to a ping or pulse, it should be able to provide SMS-related records back to the SMS site. Since it was unable to, it is logically found to be unhealthy. Offline: If the unhealthy client does not respond to the ping or pulse test, it is found to be offline. No further information about its health can be found.

Using the Client Health Summary Report The Client Health Summary Report is an HTML page that provides summary and breakdown information about the client health. You can open it by selecting Start ➤ All Programs ➤ Microsoft SMS 2003 Client Health Monitoring Tool ➤ Client Health Summary Report. The report HTML file is located at %PROGRAMFILES%\Microsoft SMS Client Health\Reports\clienthealthsum.html. This report provides an easily accessible view of the current client health and is updated automatically. Date and time stamps within the report give you an idea of how current its information is. Unlike the Client Health Pivot Table Report, described next, this summary report does not let you drill down to see details; in fact, there is no interactive type of actions you can use within this report. However, it does have the advantage of requiring only Internet Explorer to view it.

Using the Client Health Pivot Table Report The Client Health Pivot Table Report is an Excel worksheet that contains the complete health breakdown for your clients. Since it is a pivot table, it can be complex to manage, but if you have some Excel skills, you’ll find the report quite usable and helpful for obtaining specific client health information. When you first open the report file, it appears to already contain data, but this is only sample data. You must manually configure the table to obtain live information from your site, as follows:

99


100


1. Select Start ➤ All Programs ➤ Microsoft SMS 2003 Client Health Monitoring Tool ➤ Client Health Pivot Table to open the pivot table (ClientHealthPivot.xls). 2. Click any data field in the worksheet. It is important that you select one of the cells that contains a data statement. For example, click the cell immediately to the right of the Sitecode cell (usually B13), as shown in Figure 4-13.

Figure 4-13. Clicking the Sitecode cell in the Client Health Tool Pivot Table 3. Select Data ➤ PivotTable ➤ PivotChart Report. You should find yourself in the PivotTable and PivotChart Wizard - Step 3 of 3. Click the Back button to move to Step 2 of 3, as shown in Figure 4-14.

Figure 4-14. Moving to Step 2 of 3 in the PivotTable and PivotChart Wizard



4. Click the Get Data button. This will take a moment, as it times out while you attempt to connect to a nonexistent server that was preconfigured in the sheet. When the Microsoft SQL Server Login error dialog box appears, click the OK button. 5. Excel may prompt you to install the Microsoft Query components. Allow the installation, and wait for it to complete (you may need access to your Office installation source). 6. In the SQL Server Login dialog box, click Options to expand the dialog box. 7. In the expanded SQL Server Login dialog box, enter the name of your SQL Server where you placed the Client Health database. You may want to check the box for the Use Trusted Connection, as shown in Figure 4-15, but make sure your current logged-in user has access to the SQL Server where the Client Health database is being stored. In the Database field, enter the name of the Client Health database that you created. Make sure that the Application Name and Workstation ID fields are blank. Then click OK.

Figure 4-15. SQL Server Login connection information 8. In the Microsoft Query window, select View ➤ SQL. This displays the SQL query statement that generates the data returned in the cell that you initially selected in the Excel worksheet. 9. In the SQL view, in the last line of the FROM statement, remove the SMS_CLIENTHEALTH_DB. dbo.ClientHealthResults, leaving only the ClientHealthResults table name remaining in the statement. Then click OK. You should see some results returned, depending on how long the tool has been running. A typical return of results in a small test environment is shown in Figure 4-16. 10. In the Microsoft Query window, select File ➤ Return Data to Microsoft Office Excel. 11. In the PivotTable and PivotChart Wizard - Step 2 of 3 page, click Finish. 12. Updated data should have been returned to your Excel worksheet. You may validate that by checking the Sitecode data. Its drop-down box should list your site code(s). 13. Save the Excel worksheet.

101


102


Figure 4-16. SMS Client Health query results This procedure configured your data source, and also let you test it to be sure you are getting the results returned correctly. Your Excel worksheet should resemble the one shown in Figure 4-17 (of course, your client statistics will depend on your site).

Figure 4-17. Client Health Pivot Table Report with results Now that you have the Client Health Pivot Table Report configured, you can filter the results and also see more details. If you configured the Client Health Monitoring Tool to operate for multiple sites, you can filter the results based on site code. This provides a handy way to break down your results by geographic location to summarize the client health issues at the current location versus those at other locations. You may also filter the results based on client version, to view health information about only specific versions of clients.



What may not be readily apparent is that you can double-click certain fields to see further details. You can double-click a group of systems listed together as a numeric count to see more information about the individual systems. For example, Figure 4-18 shows a portion of a report with a total of two systems in the Healthy 2.50.4160.2000 client category. By double-clicking cell D17 (with the count of 2), you can see further details about those systems and why they are listed as healthy. This screen shows the machine name, last logged-on user, DDR, hardware and software inventory dates, as well as extended information such as the last policy update. Figure 4-19 shows some of these fields.

Figure 4-18. Double-clicking a Client Health Pivot Table Report cell with a count

Figure 4-19. Details after double-clicking a cell with a count

Collections One of the primary areas in SMS 2003 that you will be working with is collections. A collection is a logical grouping of discovered clients. These objects may include desktop or server systems, as well as IP address–based devices that were discovered by SMS’s Network Discovery method. By grouping these systems into logically arranged collections, it’s easier to perform granular software distribution activities, and also easier to find and connect to systems for remote activities such as using Remote Desktop or Remote Assistance.

Creating Collections SMS 2003 supports two basic types of collections: Direct-membership collection: A collection that contains statically assigned systems. You must maintain these manually by adding/removing the systems that you want to appear in these collections. Typically, you may use these for ad hoc software distributions or for maintaining lists of machines that should receive a specific software distribution. Query-based collection: A collection that contains a Windows Query Language (WQL) query statement that provides some criteria. The query returns system names, which are made members of the collection. The basic process is to create the collection, and then add the members to the collection. You may also create subcollections, nesting collections to create a tree structure. In that case, the parent collections may not have any members. As an example of using collections, suppose that you have an application that may already be installed on some client systems. You would like to know which systems have it. You would also like

103


104


to be able to push the application to clients that do not have it. To accomplish this, you can use a combination of direct-membership and query-based collections, as demonstrated in the following sections.

Creating Direct-Membership Collections For the example of checking for and distributing a particular application, you begin with creating the collection for software distributions, and then nest application-specific subcollections under it. Let’s walk through the process of creating the container collections and the nested direct-membership collection. 1. Open the SMS 2003 Administrator console, expand the Site Database node, and then expand the Collections node. 2. Right-click Collections and choose New ➤ Collection to open the Collection Properties dialog box. 3. In the General tab, enter the name of the collection, which is Software Distributions in this example, as shown in Figure 4-20. Since this collection is just being used to hold other collections, you don’t need to specify anything else. Click OK.

Figure 4-20. General tab of the Collection Properties dialog box 4. Right-click the new Software Distributions collection and choose New ➤ Collection to create a collection beneath it. Name it as the application you intend to distribute, which is SMS Toolkit 2 in this example. Click OK.



5. Right-click the SMS Toolkit 2 collection and choose New ➤ Collection to nest another subcollection beneath it. Enter the name for the new collection, which is Clients to have SMS Toolkit 2 Installed in this example. 6. Click the Membership Rules tab, as shown in Figure 4-21.

Figure 4- 21. Membership Rules tab of the Collection Properties dialog box

■Note

In the Membership Rules tab of the Collection Properties dialog box, you may want to disable the Update This Collection on a Schedule option, as it can add some overhead to your site’s workload on a heavily loaded SMS site server. 7. Click the New Direct Membership button (with an icon of a computer with a yellow star beside it) at the top of the dialog box. This will start the Create Direct Membership Rule Wizard. Click Next to continue. 8. In the Search for Resources dialog box, select System Resource in the Resource Class dropdown list, and then select Name in the Attribute Name drop-down list. Type the name you want to add in the Value field. You may use a % as a wildcard, if needed. In the example shown in Figure 4-22, I added it as Acct%. Click Next to continue. If you would like to limit the scope of the search for systems to a specified name, enter the collection name when prompted.

105


106


Figure 4-22. Create Direct Membership Rule Wizard’s Search for Resources dialog box 9. The wizard returns any results that match your search, as shown in Figure 4-23. Select the systems that you want to add to your collection, and then click Next.

Figure 4-23. Create Direct Membership Rule Wizard’s Select Resources dialog box



10. The wizard displays a list of systems or resources that were added to the collection. Click Finish to complete this process. You will then return to the Collection Properties dialog box, where the resources you added will be listed in the Membership Rules section, as shown in Figure 4-24. Click OK.

Figure 4-24. Membership Rules tab with a resource added

Creating Query-Based Collections With the Software Distributions collection structure set up for this example, you can now add a query-based collection to contain the systems that already have the specific software package loaded. You will add a query rule to the collection and direct the query to check the system’s inventory to see if the specified software is installed. This will be a simple query that checks for the existence of the Add/Remove Program entry for the SMS Toolkit 2. 1. Right-click the SMS Toolkit 2 collection and choose New ➤ Collection. 2. In the General tab of the Collection Properties dialog box, enter the name of the collection, which is Clients that have SMS Toolkit 2 Installed in this example. 3. Click the Membership Rules tab. Click the Query Rule button (with an icon of a cylinder with a yellow star beside it) at the top of the dialog box. You’ll see the Query Rules Properties dialog box, which allows you to define a new query rule. 4. Enter a name for this query rule, which is Systems with SMS Toolkit 2 Installed in this example, as shown in Figure 4-25. In the Resource Class section, click the Edit Query Statement button.

107


108


Figure 4-25. Query Rule Properties dialog box 5. Select the Criteria tab in the Query Statement Properties dialog box, as shown in Figure 4-26.

Figure 4-26. Criteria tab of the Query Statement Properties dialog box 6. Click the button with a yellow star to create a new criteria set. The Criterion Properties dialog box appears.



7. In the Criterion Properties dialog box, click the Select button. In the Attribute Class dropdown box, select Add/Remove Programs. Then select Display Name from the Attribute dropdown list, as shown in Figure 4-27. (Of course, for your own query-based collections, you may choose other attributes that better describe your intended application.) Click OK to continue.

Figure 4-27. Select Attribute dialog box 8. The Criterion Properties dialog box should now look similar to Figure 4-28. Click OK to close it.

Figure 4-28. Completed Criterion Properties dialog box 9. You should see your criteria listed in the Query Statement Properties dialog box. Click OK, and then click OK again. This will return you to the Collection Properties dialog box, which now lists your query rule, as shown in Figure 4-29.

109


110


Figure 4-29. Collection Properties dialog box with Membership Rules tab populated with a query

■Note

Notice that the other two buttons at the top right of the Membership Rules tab in the Collection Properties dialog box in Figure 4-29 are now available. These two buttons allow you to edit and remove membership rules. 10. Click OK once more to return to the SMS Administrator console. Your collection structure should now look like Figure 4-30.

Figure 4-30. The collections in the SMS Administrator console The Systems with SMS Toolkit 2 Installed collection that you just created contains systems that have the application installed, since it is based on a query of systems with specific Add/Remove



Programs entries collected via inventory. It is automatically maintained—systems that have the application are automatically added to the collection, and those that do not are automatically removed from the collection. The Clients to have SMS Toolkit 2 Installed collection that you created earlier contains clients that are destined to have the application installed. You must maintain this collection manually. This is a basic setup to provide a consistent form for software distribution. It is fairly easy to maintain the list of systems to receive software, and fairly easy to view which systems already have the software loaded.

Using a Subselect Query It is possible to create an additional collection that is a hybrid of the two existing collections in this section’s example. This collection could detect the systems in the static list of clients to have the application installed that do not exist in the collection of systems that do have the application installed. The primary benefit of this approach is that it reduces the advertisement load on the SMS site server. You advertise software delivery to this third collection, which typically contains fewer clients than either of the other two collections, as it contains only systems that have an outstanding list of the software due to be installed. This technique uses a subselect query. You must first create your query for systems with the product, and then create your query within a collection to check against that query to determine which systems are not matching the criteria. The results will show systems that do not have the product loaded but should have it loaded. When systems do match the given criteria for having the software already loaded, they are automatically removed via the subselect query.

■Tip

Check the myITforum.com website at http://www.myitforum.com/search.asp?g=x&word=subselect for some examples of using subselect queries for various purposes.

Setting Up Security for Collections When you get into using SMS on a daily basis, you will start to discover that there are optimal configurations of the basic collections that you may use on a daily or weekly basis. Naturally, you will be creating collections on an ad hoc basis, but you should think seriously about keeping them organized and secured appropriately. For example, you may want to group all collections that contain servers together and set up security, prohibiting most SMS administrators from being able to distribute software to servers. You should start with creating a master list of all the staff members that would require access in some form to SMS via either the Web console or the Administrator console. Then group their access needs to each SMS console and to each console section, and further down to their rights. By grouping, it is possible to analyze their needs and organize those needs into roles. By creating these roles, such as Software Distributors or Web Report Viewers, you can create Active Directory groups that define the users who should receive that specific set of permissions to perform the associated tasks. For example, suppose that your organization has a group that is responsible for distributing software to desktops. The scope of this group is limited to desktops; the servers are managed by another group. This Desktop Distributor group does not need any access to configuring the SMS hierarchy, and so should be restricted from areas that allow such configuration. Moving through the SMS Administrator console, let’s review each section and evaluate what access may be required for this sample group’s daily operation.

111


112


Site Hierarchy: No permissions should be needed here, as the Desktop Distributor group will not be making any site configuration changes. This area should be marked as restricted. Collections: The Desktop Distributor group is only allowed to build configurations and deploy software packages. With no support for end users, this group is restricted in what it can do in the Collections section. The group rights should be restricted to creating, modifying, and deleting collections, and distributing software against the group’s clients within these collections. Image Packages: Depending on the Desktop Distributor group’s exact function, members of this group may or may not be responsible for the imaging of the operating systems. We will assume they are not, and will not be given access to this section of the console. Packages: To distribute software, the Desktop Distributor group will need to be able to create new packages. Advertisements: This group must have access to the Advertisements section in order to be able to distribute software to the group’s clients. Software Metering Rules: The SMS Administrators group will be charged with the task of configuring the software metering rules as needed. The results of these rules can be used by other groups when building reports, queries, or collections. Reporting: This is also known as the Web console. The Desktop Distributor group requires access to this section in order to track the distribution status of its advertisements. Product Compliance: The rules on product compliance are maintained by the SMS Administrators group on an as-needed basis. The other groups will be able to access only the results of these rules when building reports, queries, or collections. Queries: In order to effectively perform software distributions, the Desktop Distributor group likely will need access to create and run queries to build complex collections. Software Updates: The Security group manages the download and authorization of software updates. Once authorized, these updates are made available to the Desktop Distributor group as packages. Systems Status: Since the Desktop Distributor group is monitoring the success/failure of package replication and advertisement status, the members should have access to this section. Security Rights: All security rights will be maintained by the SMS Administrators group. Tools: The tools within this section are reserved for the SMS Administrators group. Now that the Desktop Distributor group’s high-level needs have been outlined, these security requirements must be applied to that group’s accounts. You should create an Active Directory group to contain the group members’ specific user accounts. You should also create a group to manage global security and name it appropriately. Populate this Active Directory security group with the appropriate domain user accounts. In order to gain access to the SMS Administrator console and database, all SMS users must be added to the SMS Users group. Create this Active Directory group and populate it with all the SMSrelated groups. If you don’t add users to this group, users will not be able to connect to the SMS console with the SMS site server.



■Tip

I typically use universal domain groups for this setup, as they are flexible in allowing nested groups. The contents of these groups don’t change that much, so you don’t need to worry too much about global catalog (GC) replication within your Active Directory structure. Keep in mind that you need your Active Directory infrastructure to be in Native mode for universal groups. After you have set up your security groups appropriately, it’s time to get your hands dirty in the SMS Administrator console and put these groups to work. As explained in Chapter 3, SMS supports two security configurations for console objects: class and instance. Class rights affect all objects of that type, or class. If permission is granted to a specific class such as collections, it applies that permission to all collections. Instance permissions apply only to the selected object. By combining the two permission schemes, you can grant granular permissions to specific sections of the console for users or groups of users. Apply this technique to the Desktop Distributor group example as follows: • Add its Active Directory universal group to the SMS Users universal group. Being a member of the site server’s local SMS Users group allows the Desktop Distributor group to open the SMS Administrator console. • Add instance permissions to the Software Distributions collection under Collections, and any subcollections beneath that level. This lets the users in the group view these collections, but no others. • To allow the group to create new collections beneath the allowed collections level, add class permissions to allow Create, Delete, and Advertise rights to all collections. This does not alter the collections that the group members are able to view, but adds the right to create, delete, and advertise packages to the viewable collections. This setup provides the level of security to allow your users to perform their functions. You would extend this same technique to the other areas of the console that require permissions, leveraging both class- and instance-level permissions where needed.

Summary This chapter focused on managing SMS resources, namely SMS clients. We began with setting up SMS site boundaries, which are used for site assignments. You then learned how to view the status of individual site components, to check the basic health of your SMS infrastructure. Next, we discussed the SMS Client Health Monitoring Tool, including how to install, configure, and use it. The last part of this chapter covered collections, describing how to create and use both directmembership and query-based collections. You also learned about security considerations for your SMS collections and how to manage security using groups and permissions.

113



CHAPTER 5 ■■■

SMS 2003 Software Delivery and Reporting

O

ne of the primary reasons for implementing SMS 2003 in an organization is to use its software distribution services. You can always rely on other methodologies, such as GPO-based software delivery, but they do not offer the same level of control and reporting that SMS 2003 provides. In this chapter, you will learn how to define packages and advertisements to deliver software and scripts to clients. Then you will see how to set up software metering. The final sections cover some reporting tools: queries and web reports.

Packages Packages form one of the fundamental building blocks of functionality within SMS 2003. A package defines the software that you want to distribute, as well as how you want to install and configure that software. You move and maintain packages of software on Distribution Points (DPs). Your clients access the contents of these packages through advertisements, which specify what program should be executed from within the package location and the schedule to perform this execution. (Advertisements are covered in the next section.) A single package may contain multiple programs. For example, you might use a package to distribute Microsoft Office Standard. You would copy its media contents to a folder, and define that folder as a package source location. Once the package is processed by SMS, in accordance with the options chosen at the time of package creation, it is then copied to the DPs as specified by the SMS administrator. By default, a package is not moved to any DPs until they are assigned to the package by the SMS administrator.

Defining Packages The process of defining a package is fairly simple. Over time, you will be able to do this in your sleep. To get you started, we’ll walk through the procedure, using the example of the SMS Toolkit 2 as the software to distribute through the package. The process involves three main tasks: create the package, define the DPs, and define the program(s).

115


116

CHAPTER 5 ■ SMS 2003 SOFTWARE DELIVERY AND REPORTING

Creating the Package As you might expect, the SMS Administrator console guides you through the process of creating a package with a wizard. Follow these steps to use it: 1. Open the SMS Administrator console, expand the Site Database node, and then expand the Packages node, as shown in Figure 5-1.

Figure 5-1. The Packages node in the SMS Administrator console 2. Right-click the Packages node and choose New ➤ Package from Definition. This option allows you to automatically define some of the package attributes, such as name, version, and language. You can use this option if you are provided with an SMS, a PDF, or an MSI file with your installation. The Package option offered on the New context menu requires you to supply all the information for the required fields; SMS is not able to pull any of the language, version, or other information from the setup files.

■Note

The Folder option on the Packages ➤ New context menu is used strictly for creating a folder structure to allow you to organize and keep your Packages tree tidy. I recommend that you use this feature to group similar packages together into a logical structure.



3. The Create Package from Definition Wizard starts. Click Next to continue. 4. In the Package Definition dialog box, shown in Figure 5-2, click the Browse button to browse for your installation file, which is the SMS Toolkit 2 in this example. Once you have located your MSI, SMS, or PDF file, click Next to continue.

Figure 5-2. Create Package from Definition Wizard showing publisher and package information 5. In the Source Files dialog box, shown in Figure 5-3, choose an option to specify how SMS should handle the source files: • If the package does not contain any files—perhaps you are executing a file that already exists on your targeted systems, such as a defrag executable—select This Package Does Not Contain Any Files. • If the files are located on the same server as your SMS site server, you would likely select Always Obtain Files from a Source Directory. This option bypasses the step of copying the files to the intermediary location (the SMSPKG folder on your site server) and copies them directly to your DPs, if any have been configured at this point. The source files are not compressed during this copy operation. Typically, this option is used in a simple SMS setup with a single site server that also acts as its DP, or in cases when the source files do not compress well. • Typically, you will choose the Create a Compressed Version of the Source option. This option compresses the source files as they are copied from the source location, and places a compressed .pkg file into the SMSPKG folder location.

117


118


Figure 5-3. Create Package from Definition Wizard showing source file options 6. Click Next after you have made your selection to move to the Source Directory dialog box. 7. In the Source Directory dialog box, specify the physical location of the software for which you are creating the package. Choose Network Path (UNC Name) if the software folder is accessed over a network connection, or choose Local Drive on Site Server if the folder is located on the site server’s local drive. Then enter the path to that folder location, as shown in Figure 5-4. Click Next to complete this step.

Figure 5-4. Create Package from Definition Wizard showing source directory options 8. Click Finish to complete this process and close the wizard. At this point, you have created a basic package, but you have not defined the DPs, nor have you defined the program(s) that you will advertise to your clients. So, let’s continue.



Defining the DPs The package you created will now be listed under the Packages node in the SMS Administrator console. Drill into your package, to the Distribution Points node, right-click it, and then choose New ➤ Distribution Points, as shown in Figure 5-5.

Figure 5-5. Selecting to add new DPs to your package In the dialog box that appears, select the DP or DPs that you have configured for your site where you wish to replicate a copy of your software package. You need at least one DP to service your clients.

Defining the Programs Once you have created the package and specified the DPs, the last step is to define the program. The program can be thought of as the command line that you should execute to install the software package. You define the program through the Program Properties dialog box. To open this dialog box, drill into your package to the Programs node, right-click it, and choose New ➤ Program. The Program Properties dialog box has six tabs: General, Requirements, Environment, Advanced, Windows Installer, and MOM. Set the properties as described in the following sections.

■Note You may define multiple programs for a package. For example, for a package to distribute the Microsoft Office Standard program, you might define Unattended Install ➤ All Features ➤ Current User and Unattended Install ➤ All Features ➤ All Users. You would use the same executables, but the command-line options may be different. It’s also common to create an Uninstall program within the same package as the program you’re distributing. General Program Properties The General tab of the Program Properties dialog box contains the following settings: Name: Give the program a meaningful name that describes how it will be installed. For example, you might name it Silent Install to All Users, Silent Uninstall, or Unattended Install. These names must be unique within the same package, but can be the same between different packages. Name your programs consistently. Try to keep the names fairly short, as long names can be a pain if you need to retype them, plus they are concatenated with the collection name to form the advertisement name.

119


120


Comment: Add some text here. Include anything you wanted to state in the name but didn’t because it would have made the name too long. Even include a version in here if you like, as it is a handy diagnostic measure to determine if a package update has been processed and delivered to your client. Command Line: This is where you state how the package should be installed. It is literally the command line that you could execute from the Start ➤ Run dialog box. Typically, it reads similar to Setup.exe /s /SMS for a classic InstallShield packaged application, or msiexec.exe /I Office.msi /qn! for an MSI-based installation. A handy way to do this is to browse to your main installation file, whether it’s a setup.exe or an .msi. This allows you to avoid typing the name (and the inevitable typos), and it also confirms that you have entered the package source location correctly, as you should be able to see the files belonging to the package. Start In: This field allows you to define an alternate folder location for the execution of the file you specified in the command line. Occasionally, an installation folder has a setup executable buried in a subfolder separate from the rest of the files. Using the Start In setting is one way to preserve the vendor’s file structure and execute the correct file for the installation. Run: Choose how the program will run: • Normal indicates that the installation execution will be displayed, just as if it were executed from the command line. • Hidden indicates that the SMS client should attempt to hide the display of the executable being run by the program. This is particularly effective at hiding command shells that are processing in the user’s context. Normally, you install software using the system context, which, by default, can be hidden from the user’s view. • Minimized does just that—attempts to minimize the window of the executing file. • Maximized performs just the opposite of Minimized. It maximizes the window for the executing file. After Running: This allows you to select a variety of options to be performed after the installation has completed. You need to be careful with this, as sometimes installations will spawn other processes that may not have finished at the same time. These may be terminated unexpectedly if a reboot option is chosen. There are four options here: • No Action means that nothing happens after completion. • SMS Restarts Computer means that once the program has completed, SMS initiates a shutdown of the computer on which it performed the installation. This is not a forcible shutdown; users will be prompted to save data when applicable. • Program Restarts Computer is used to tell SMS that the installation program is handling the restart, and to expect one at completion. • SMS Logs User Off means that SMS logs any current user off the system where it performed the installation. The user is prompted for save data when applicable. Category: This is one of my favorite fields, and in my opinion, underused. You may arbitrarily pick a category name for the program. The users will then see this category name in the Add/Remove Programs location when they browse for applications to install manually though SMS. This makes it easier for users to navigate the numerous applications that may be available to them.



Program Requirements The Requirements tab of the Program Properties dialog box contains the following settings: Estimated Disk Space: If you are aware of the disk space requirements of the application that you will be installing with this package, you may choose to include that value here. A basic disk space check will be performed to ensure there is enough space for the intended installation. Maximum Allowed Run Time: Be careful with this one, as it’s not what you expect. This places a restriction on how long the installation may take until it is determined that something has gone wrong and the installation process should be terminated. If you choose a time period that is too short, you will end up with a lot of failures. This Program Can Run on Any Platform: This option allows the installation to happen on any supported OS platform. This Program Can Run Only on Specified Client Platforms: You may select a series of OS platforms for the installation. This is handy for widely mixed environments. For example, you may want to use this option if your application has been repackaged on a specific build of Windows and may not run reliably on other versions.

Program Environment The Environment tab of the Program Properties dialog box has three options: Program Can Run: This option determines the user login conditions that must be met before the program is installed. There are three possible conditions: • Only When a User Is Logged In means that the program will wait until a user logs in to the system. If the user logs in, then off again, the installation will still proceed. • Whether or Not a User Is Logged In means that, regardless of the state of the machine, the installation will proceed. • Only When No User Is Logged In has the program wait until a user is not logged in. This option will usually perform the installation when the machine first starts up, but before a user has had a chance to log in. The installation will continue if a user logs in while it is in process. Run Mode: You may choose the user context for the program to be run in: with user’s rights or with administrative rights. If you choose Run with User’s Rights, the program will run under the user’s context and may be visible to the user, so the user may interact with the installation if needed. If you choose Run with Administrative Rights, the program will run with elevated rights stemming from one of two sources. The default method will allow the program to execute within the local system’s administrator level context. Two suboptions may be available: • Use Software Installation Account will use the account specified in the Site Properties dialog box to execute the program using its account, which is configured to be a domain account with administrative privileges on the client system. This option is not available if you chose to have the program run only when a user is logged in. • Allow Users to Interact with This Program lets users see any dialog boxes resulting from the program execution, and potentially interact with them. This box is unavailable if you chose to have the program run only when no user is logged in.

121


122


Drive Mode: Three drive modes available. You will typically use only the first mode, but may require the other two in special circumstances. • Runs with UNC Name is the standard mode. Most software is able to execute via a network path to its source location. • Requires Drive Letter is for software that requires a drive letter to be mapped prior to its installation or execution. SMS will automatically choose a drive letter and map it to the network share. • Requires Specific Drive Letter is for software that require a specific drive letter to be mapped prior to its installation.

Advanced Program Properties On the Advanced tab of the Program Properties dialog box, you can set the following: Run Another Program First: This option allows you to chain together multiple programs from the same or different packages. Be careful when creating these links, as they execute in a reverse order than you may think initially. If you set another package to execute first, it will do just that— execute first, followed by the one where you configured this. You can configure a few options with this setting: • The Package option selects the package from which to choose the program that you wish to execute first. • The Program option selects the program from within the previously selected package to execute first. • The Run This Other Program Every Time option enforces that the specified program will execute every time that this master program is executed. Normally, SMS will detect that the previously specified program has run and will not execute it again. • You may also specify how often this program should be executed: either once per computer or once for each user that logs in to the computer. This option is unavailable if the program is not set to run when a user is logged in. Suppress Program Notifications: This option suppresses the built-in SMS program notifications mechanism. It reduces the amount of notification dialog boxes that a user may see. Check this box to allow for silent installations of software. Disable This Program on Computers Where It Is Advertised: By placing a check in this check box, the selected program will be disabled at the DPs. Any system that has an outstanding advertisement schedule to execute this program will be unable to do so. If you are testing a program, you may wish to leave this box checked until ready for deployment. In some cases, you may inadvertently advertise software to a group of systems. Rather than removing the advertisement schedule, or deleting the advertisement, place a check in this box. This is the quickest and most reliable way to stop the execution of the program. This option can be a lifesaver (or career-saver, for that matter).

Windows Installer Program Properties The Windows Installer tab of the Program Properties dialog box lets you import Windows Installer (.msi) files. The Import button allows you to browse for an .msi file, and then import the embedded Windows Installer GUID of the file into SMS.



Once you have imported the .msi file, the embedded product code will be shown in the Windows Installer Product Code field, and the Windows Installer File field will contain the name of the imported file.

MOM Program Properties The MOM tab of the Program Properties dialog box has two options related to Microsoft Operations Manager (MOM): Disable MOM Alerts While This Program Runs: This option places the system executing the program into MOM’s maintenance mode, which will suppress alerts from being generated within the MOM Operator Console resulting from any program execution action, such as a reboot. This is useful when deploying patches to systems being monitored by MOM. Generate MOM Alert If This Program Fails: This allows the alerts resulting from the failure of execution of a program to be passed to MOM.

Checking the Status of Packages So far, you have defined your package and program. You have also defined your DPs and allowed your package to replicate out to the sites where it will be needed by clients. You are almost ready to put the package that you have created to work for you. You do that by creating advertisements, as described in the next section. Before we get to that process, let’s see how you can check on the status of your package, in case you need to troubleshoot a problem. The SMS package that you have created is maintained by SMS automatically. If you chose to maintain a compressed copy of the source directory during the creation of the package, you will find it on your SMS site server in a folder named SMSPKG. Within that folder, you may find several files (depending on the number of packages you have with compressed source files) with an extension of .pkg. These files are named in the form <Site Code><Package ID>.pkg. For example, if the site code is PRI and the package ID (which SMS automatically generates) is 0000C, the resulting filename is PRI0000C.pkg. These files should have dates that are consistent with the last time they were updated. Once the source files have been obtained and compressed into a .pkg file, they are transferred to the DP(s) that have been configured for use by the specific package. The DPs store the package contents in an uncompressed form in a common structure. Typically, the Distribution Point Manager service running on a DP will determine the drive with the most free space available and place a folder for the storage of the packages on that drive. This folder is named as SMSPKG(x)$, where x is the drive letter of the drive on which this share is located. You may browse into these folders and see subfolders named with the package ID. These folders contain the uncompressed package contents of the packages they represent. You can track the package IDs through the DistMgr.log file during their processing to troubleshoot any issues that may arise. This log file tracks the process responsible for replicating your package, so you can also use it to check on your progress of the package replication to the assigned DPs. Figure 5-6 shows an example of a typical update cycle that was successful in performing an update of a package. You can directly access these files at the DP, so what is to stop you from modifying them? Nothing really, other than a CRC checksum that is applied to the package contents and stored as part of the package information. This means that if you manually modify or replace a file within this package structure, it will render that instance of the package unusable until it has been re-replicated from its source location. You should never modify package files at the DP. Instead, make any necessary changes through the site server’s Packages node, and then update the package through an advertisement. SMS will manage the transfer of data to your DPs for you once instructed to update the package.

123


124


Figure 5-6. SMS Trace viewer showing DistMgr.log

Advertisements Now that you have defined your packages, you need to create an advertisement. An advertisement is the linkage between the source (package) and the destination (collection of users or machines). Advertisements define the schedule for package installation and how the package contents should be transferred to the client system.

Creating Advertisements Creating an advertisement is a fairly quick and easy process. Since it is so quick and easy, you may want to seriously look at restricting this ability to specific users or groups in your organization. Accidentally advertising software to systems is generally a bad thing, so you should always double-check that you are distributing software to the correct systems. You can create an advertisement from the Collections, Packages, or Advertisements node within the SMS Administrator console. Here, we will walk through the steps of creating an advertisement from the Advertisements node.



1. Open the SMS Administrator console, expand the Site Database node, and then expand the Advertisements node. 2. Right-click the Advertisements node and select New. 3. On the General tab of the Advertisement Properties dialog box, shown in Figure 5-7, set the options as follows: • Name: Give the advertisement a meaningful and standardized name (for example, SMS Toolkit 2). Try to keep this name brief, as it is combined with the targeted collection’s name and package name to form the full advertisement name. • Comment: You can enter additional text here to further describe the advertisement. This can be helpful if you need to troubleshoot an advertisement update that has been processed and delivered to your client. • Package: From this drop-down list, select the package that you wish to distribute. The list includes the packages that have already been created. • Program: From this drop-down list, choose the program you wish to advertise. This list includes the available programs that have been defined within the package you selected. • Collection: You may either browse or type the name of the collection that is the target of this advertisement. Typing the name is prone to spelling errors, and makes it easier to distribute software to unintended collections. Browsing removes that uncertainty, but it can take a significant amount of time in larger collection structures to find the right collection.

Figure 5-7. General tab of the Advertisement Properties dialog box 4. Click the Schedule tab, as shown in Figure 5-8. You may enter a value for the Advertisement Start Time to specify when the clients will be able to receive the advertisement information. If you set this at a point in the future, the clients will be able to see the contents of the scheduled advertisement only on or after that time. The Advertisement Start Time setting does not necessarily dictate when clients will execute the software deployment. You can force the software distribution to start at a specific date and time, as you’ll see in the next step.

125


126


Figure 5-8. Schedule tab of the Advertisement Properties dialog box 5. Click the button with the yellow star in the Mandatory Assignments section. In the Assignment Schedule dialog box, click the Schedule button. 6. Select an appropriate time and date for software distribution to start. If you wish for this installation to reoccur, you may select a reoccurrence pattern. This is particularly handy for patch management scanning activities that should occur weekly or monthly. You can also set the software distribution to occur at a particular point of activity by selecting the Assign Immediately After This Event option. You may specify the event as Logon, Logoff, or As Soon As Possible. These values take effect after the client has received the advertisement information from the Management Point (MP). 7. Click OK to return to the Schedule tab. 8. Set the remaining options on the Schedule tab as follows: • Assignments Are Not Mandatory Over Slow Links: This option allows the advertisement to not be forced to clients that are currently located on slow links. If this option is not selected, the advertisement may create additional load on those slow links. • Allow Users to Run the Program Independently of Assignments: This option allows the recipients of the advertised packages to manually execute the advertisement without waiting for the assigned schedule to occur. • Advertisement Will Expire: By enabling this option, you will ensure the advertisement is unavailable to use after a certain date and time. • Priority: You may alter the priority of the advertisement. This typically has no effect unless you have assigned priorities on your site senders and addresses. In smaller sites, leave this value alone. In larger sites where this may have some effect on the transfer and execution of the advertisement, use it with care to avoid network congestion on small or heavily used links.



9. Click the Advanced Client tab. Set the options as follows: • When a Distribution Point Is Available Locally: Two options are available for selection. You may instruct the Advanced Client to execute the program directly from the DP by selecting Run Program from Distribution Point. Alternatively, select Download Program from Distribution Point to instruct the Advanced Client to first download a copy of the package and program into its cache and then start execution from that locally cached location. This is typically done for patch management packages that contain many patches, some of which may not be appropriate to the system. • When No Distribution Point Is Available Locally: Select from two options. Do Not Run Program instructs the Advanced Client to wait until a DP is available locally. This may be the case for a laptop user who has connected via a VPN connection. Download Program from a Remote Distribution Point instructs the Advanced Client to download the package from a location that is remotely connected to the client. This option may cause significant delay as the package is downloaded to the Advanced Client’s cache, and may be subject to multiple disconnect and reconnect cycles.

■Caution

Think about the options on the Advanced Client tab of the Advertisement Properties dialog box carefully, as they can affect the amount of network traffic that is transferred over your WAN links.

That completes the steps for creating an advertisement. Now you will want to be able to monitor your advertisements. You also may need to modify them.

Monitoring Advertisements You could simply wait for the phone to ring with reports of missing or failed software distributions, but that is hardly a proactive approach. A better method is to check the status of your current software distributions. You can view the SMS status messages regarding advertisements in the SMS Status Message Viewer window (similar to viewing component status, as discussed in Chapter 4) or as a web report in the Web console.

Viewing SMS Advertisement Status Through the Advertisement Status node of the SMS Administrator console, you can see a complete audit trail of an advertisement, including when it was created and modified, and what its status is as reported by the SMS clients that have interacted with it. These items are all detailed with status message codes and time-stamped within the status message logs, allowing you to easily locate specific events and status messages. To access this information for a site, in the SMS Administrator console, drill down through the Site Database node to the System Status node, then the Advertisement Status node. You should see entries for each advertisement that currently exists in your site. Click the advertisement you want to check to see its general status, as shown in Figure 5-9. In the right pane, right-click the site that corresponds to where you want to check the advertisement status and choose Show Messages ➤ All. The SMS Status Message Viewer window opens, showing status messages (if there has been any activity for that advertisement). This should include some milestone and audit messages about the creation of the advertisement.

127


128


Figure 5-9. Viewing advertisement status details

■Note

Similar to the context menu for site component status messages, the advertisement status context menu includes options for filtering the various status message types and resetting the counters for specific message types.

The typical flow you should observe is as follows (shown in Figure 5-10): • Advertisement created—message ID 30006 • SMS Offer Manager successfully processed new advertisement—message ID 3900 • Advertisement was received—message ID 100002 • Program started—message ID 100005 • Advertisement completed successfully—message ID 100008/9

Figure 5-10. SMS Status Viewer showing successful software distribution



■Note SMS status messages are all uniquely numbered. Typically, each message ID represents a unique informational or error state. Two exceptions are the 10008 and 10009 message IDs. These both indicate success of the software program execution on a client. Each is generated in a unique circumstance, depending on the type of program being distributed. A 10009 message ID generally is generated by an installation that creates an MIF file. A 10008 message ID is generally created by an exit code of 0 from a program. For further information on troubleshooting the expected creation of the 10009 message, refer to the Microsoft article at http://support. microsoft.com/?kbid=916797. You may want to adjust a couple key settings in this viewer. Choose View ➤ Options and make sure the time zone is set correctly. Also adjust the automatic refresh interval for the message display and number of messages returned per query. If I am looking for a specific event that has yet to happen, I set the refresh rate to 1 minute and limit the number of messages to 10. You may double-click any message to view its details in the Status Message Details dialog box, as shown in Figure 5-11. You can cycle through the messages by clicking the Previous and Next buttons at the bottom of this dialog box.

Figure 5-11. Status Message Details dialog box

Using the Web Console As an alternative to the SMS Status Message Viewer, you may choose to use the SMS Web console to see status message information about advertisements. To access this web report, in the SMS Administrator console, drill down through the Reporting node, the Reports node, and the Software Distribution node to the Advertisement Status report group. Then select the Status of a Specific Advertisement report. The web report displays results that are similar to those you see in the SMS Administrator console. However, the results are arranged slightly differently, and the report has links to access specific details, as shown in Figure 5-12. For example, if you click the Succeeded link, you should see results similar to the ones shown in Figure 5-13. Other links show similar data corresponding to their state.

129


130


Figure 5-12. Status of a Specific Advertisement Report in the Web console

Figure 5-13. Systems reporting success messages for an advertisement I think this is one of the more effective uses of SMS web reports, which we’ll explore further in the “Web Reporting” section later in this chapter. You can’t create or modify the advertisements from the Web console, but it is useful as a status message viewer.



Modifying Advertisements After you have created and used an advertisement, you may need to make modifications to it. You can return to the Advertisement Properties dialog box and change any property, even after the advertisement has already been used by clients. For example, you can change all the schedule parameters of an existing advertisement. A common modification is to switch its mandatory assignment from a specified date and time to as soon as possible, or vice versa. You may also choose to add another schedule to execute the package. This will cause systems that may have returned an error during previous attempts to retry executing the advertised program. Just remember that if a client has already successfully run a package, it will not rerun it by default when a single new schedule is added.

■Tip By adding two future schedules, you can cause all your clients to reexecute the advertised program. This is very useful when you have updated the contents of a package and want to make sure that all clients have the same version installed.

Software Metering As noted in previous chapters, the SMS 2003 software metering function is drastically different from software metering in previous versions of SMS. Having been rewritten, the core functionality of the feature has changed. It is reduced in some ways—for example, you can no longer restrict the usage of an application based on exceeding a number of licenses—but enhanced in other ways. The client agent that performs the software metering actions on the client is less resource-intensive. The reporting mechanisms are greatly improved, and SMS 2003 includes many default reports, such as current usage and summary reports on usage. Also, software metering now includes support for Terminal Services. You must create rules to monitor applications, as no default rules are included. Software metering rules are policy-based and automatically downloaded via normal policy update cycles for Advanced Clients. Legacy Clients are also supported; their rules are transferred through Client Access Points (CAPs) as XML data. Monitoring data is passed back to the SMS infrastructure for both Advanced Clients and Legacy Clients as XML data. The Software Metering Client Agent is responsible for retrieving the metering rules from the CAP or MP on the specified schedule. The Software Metering process running on the SMS 2003 site server is responsible for creating and maintaining the software metering inboxes. It also compiles metering rules into XML files, and then replicates files on CAPs for Legacy Clients to download. The policies are created by the policy provider for Advanced Clients. The database then sends policy updates to the MP for distribution to the Advanced Clients. Additionally, the Software Metering process handles incoming data files from clients and usage data reports sent as MUX (metering usage) files from clients to a CAP or an MP. Once it has received this data, it processes the metering data into its site database, storing detailed usage records from clients into the database and summarizing data into periodic and file-usage data.

Defining Software Metering Rules Defining rules for SMS software metering is a fairly easy task. Follow these steps to set up a sample rule for the Trace tool in the SMS Toolkit:

131


132


1. Open the SMS Administrator console, expand the Software Metering Rules node, right-click the right pane, and choose New from the context menu. 2. Type in a name for the rule. Use something brief and descriptive. In this example, enter Systems Management Server Trace. 3. To configure the software metering rule, find the required .exe file on any machine and import it into a new software metering rule. In this example, click the Browse button and locate the Trace32.exe application in the SMS Toolkit. 4. The remaining fields should be filled in automatically. You can generalize specific values such as version by removing some of the version specifics (subversion information) and replacing them with an asterisk (*). The completed dialog box is shown in Figure 5-14.

Figure 5-14. Completed Software Metering Rule Properties dialog box

■Note

The site code appears at the bottom of the dialog box. Once the rule is created, you may not change that code. You must create a new rule with the desired site code at that point. Also, the Original File Name value comes from the resource header of the executable. If an end user knows you are monitoring an application, he can try to rename the file via Windows Explorer, but when metering an application, you can track from either the filename (Windows Explorer) or the original filename (resource header). This thwarts efforts to trick the Software Metering Agent.

5. Click OK to complete the process.

Scheduling Software Metering As explained in Chapter 3, you must first enable the Software Metering Client Agent from within the Client Agents node in the SMS Administrator console, as shown in Figure 5-15.



Figure 5-15. Accessing the SMS Software Metering Client Agent Once you have opened the Software Client Metering Agent Properties dialog box, enable metering, as shown in Figure 5-16.

Figure 5-16. Enabling the Software Metering Client Agent The Schedule tab, shown in Figure 5-17, has the scheduling options. Typically, you can leave these values at their default settings, unless you require specialized reporting intervals.

133


134


Figure 5-17. Scheduling the Software Metering Client Agent The Data Collection Schedule setting dictates how frequently the clients report usage data that they’ve generated over a period of time. The default configuration is every seven days on a Friday. The Metering Rules Download Schedule setting dictates how often the Legacy Clients will download the metering rules from the CAP. Advanced Clients download the policies automatically at the next machine policy retrieval and evaluation cycle.

Configuring Software Metering Tasks In addition to the schedules you can configure through the Software Metering Client Agent Properties dialog box, you can also configure some site maintenance tasks that dictate how software metering data is handled. To access these settings, in the SMS Administrator console, drill down through the Site Settings node to the System Maintenance and then Task nodes, as shown in Figure 5-18. Four tasks are related to software metering: Delete Aged Software Metering Data: Deletes data older than 270 days nightly. Both the age value of 270 days and the nightly schedule are configurable. Delete Aged Software Metering Summary Data: Deletes metering summary data older than 270 days on every Sunday. These parameters are configurable. Summarize Software Metering File Usage Data: Consolidates the usage data into daily summaries. Summarize Software Metering Monthly Usage Data: Consolidates the usage data into monthly summaries. The combination of these tasks reduces the quantity of data that needs to be retained within the database, while still keeping pertinent usage statistics available for reports.



Figure 5-18. Accessing site maintenance tasks

Using Software Metering Reports SMS 2003 provides 13 predefined reports related to software metering, as shown in Figure 5-19. Their titles are fairly self-explanatory.

Figure 5-19. SMS predefined software metering reports The last three reports listed are particularly useful. The total usage trend analysis reports show usage statistics for specific software packages or rules that you have defined. The report on users that have run a specific software program shows details on which users have been executing the specific program that you have been monitoring with your defined rules.

Queries A query within SMS 2003 allows you to access data stored within the SMS database about SMS objects and their properties. SMS 2003 comes with a variety of predefined queries, available through the SMS Administrator console. However, an essential skill is the ability to write new queries.

135


136


The query language that is used by SMS is WQL, a subset of SQL. If you have any programming experience or familiarity with SQL queries, WQL will come very quickly to you. For the rest of us, it’s really not that hard. You can always examine the existing queries and apply what you’ve learned to creating new ones. Let’s follow through with our previous example using the SMS Toolkit and check to see which machines and users currently have it installed. 1. Open the SMS Administrator console, drill down to the Site Database node, and expand the Queries node. 2. In the right pane, right-click and choose New ➤ Query, as shown in Figure 5-20.

Figure 5-20. Choosing to create a new query 3. In the Query Properties dialog box, type in a name for your query. In this example, enter Systems with SMS Toolkit Installed, as shown in Figure 5-21. Then click the Edit Query Statement button. 4. In the Query Statement Properties dialog box, the General tab allows you to specify the attributes to find and how they should be displayed, as shown in Figure 5-22. Click the button with a yellow star to add an attribute. 5. Click the Select button to choose the attribute class and attribute fields that you want to display. Choose the System attribute class and Name attribute. Click OK to add them. 6. In the Query Statement Properties dialog box, click the far-right button on the icon bar above the list, change the Sort option to Descending, and click OK.



Figure 5-21. Query Properties dialog box

Figure 5-22. Query Statement Properties dialog box 7. Repeat steps 4 and 5 to add the System Resource attribute class and Last Logon User Name attribute. Don’t bother changing the Sort option for this iteration. Your General tab should look like Figure 5-23.

137


138


Figure 5-23. Attributes added to the General tab of the Query Statement Properties dialog box 8. Click the Criteria tab. This tab allows you to narrow the returned results. Otherwise, the query would return values for all systems within SMS. Click the button with the yellow star to add criteria. 9. Click the Select button to add the attribute class and attribute. For this example, choose the Add/Remove Programs class and the Display Name attribute. Then click OK. 10. Now that you have chosen the source of the data that you want to use as your criteria, you need to choose an operator and a value for comparison. Make sure the Is Equal to option is selected in the Operator field. Then click the Values button.

■Note You could enter a value directly in the Value field. Clicking Values is useful if you cannot remember the name exactly or want to see which values are available in this attribute. Ensuring the accuracy of your value is crucial in returning correct results. However, it may take awhile for the Value list to be populated. In a large environment where you have many systems, each reporting multiple attribute values, such as is the case with the Add/Remove Programs – Display Name attribute, you may have many thousands of results to browse through. Be patient! 11. Many results are returned, even for a small environment like a test system. Browse down the list to what you want. In this example, select SMS Toolkit 2 (notice that SMS Toolkit is not the exact name). Then click OK. The Criterion Properties dialog box should now look like Figure 5-24. 12. Click OK to return to the Query Statement Properties dialog box. Notice that your criteria search results now appear here.

■Tip

You may need to configure multiple and complex criteria. They would all appear in the Query Statement Properties dialog box. The button bar allows you to add brackets to form a sequence of operations and also to add simple operators such as AND/OR and NOT.



Figure 5-24. Populated Criterion Properties dialog box 13. Click the Show Query Language button to see the WQL query statement that you’ve built, as shown in Figure 5-25.

Figure 5-25. Viewing the query statement created from the WQL GUI interface

139


140


14. Click OK to return to the Query Properties dialog box. If desired, in the Collection Limiting section of this dialog box, you can specify a collection to limit the query to run against. You may find this useful in determining a subset of systems of specific machine types (as those collections already exist and don’t require you to build that into your query). 15. Click OK again to return to the SMS Administrator console. 16. In the SMS Administrator console, right-click your new query and choose Run. The results should be returned in the right pane of the console. It was definitely easier to create this query through the GUI rather than typing the exact syntax needed to craft the query statement. However, there are times that it may be more convenient to use the query language directly. By using WQL, you can copy and paste query statements from one query to another. It is an easy way to copy and share queries with colleagues at different sites or companies. As you learned in Chapter 4, query-based collections may use queries to generate their members. Rather than creating the query when you create your new collection, as described in Chapter 4, you can first create your query in the Queries node, as in the preceding example. Then browse for that query while creating your new collection. This is the approach I recommend. I also suggest organizing your queries into folders to keep them tidy. In some cases, you may need to create a query-based collection where members of one collection are not members of another collection. As explained in Chapter 4, this can be handled through a subselect query. Essentially, you are providing a master list of systems for comparison and determining which ones are not in another collection. Using the example of SMS Toolkit’s SMS Trace application, here are the contents of the query you would need to build a collection of systems that do not have the SMS Toolkit application installed. select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, ➥ SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, ➥ SMS_R_System.Client from SMS_R_System inner join SMS_G_System_SYSTEM on ➥ SMS_G_System_SYSTEM.ResourceID = SMS_R_System.ResourceId where ➥ SMS_G_System_SYSTEM.Name not in (select SMS_R_System.Name from SMS_R_System ➥ inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = ➥ SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName ="trace32.exe") As systems report that they have the application installed, they will not be returned on subsequent executions of this query. Since queries within collections have update schedules, they will automatically keep themselves up-to-date with systems that do not have the needed criteria. This is very useful for distributing software to systems where it does not exist already. As they receive the new application and return their inventory results, they will drop out of the collection and not have the advertisement sent to them anymore. You could easily limit the collection for this query to a source collection of systems that you wanted to advertise a program against. This would provide a self-maintaining collection of systems to advertise to, and automatically remove the ones where it has already installed. You may create the inverse of this, where the query returns systems with the application installed. You should see one collection shrink, and then other grow over time.

Web Reporting We touched on SMS’s web reports earlier in this chapter in the sections about SMS advertisements and software metering. SMS 2003 provides many pages of predefined reports. These range from hardware and software inventory reports to status message reports, and even site configuration reports.



You can use the predefined reports to assist in your everyday activities with SMS, but they do have limitations. Therefore, you may want to add reports, such as those for systems with and without patches installed. Here, I’ll show you two ways to do this.

Importing and Exporting Reports Since web reports are just SQL queries—that’s SQL, not WQL—you can’t directly import those queries you create into the Web console. You can do it indirectly, but that’s the topic of the next section. You can import and export reports by using SMS’s Export Object and Import Object functions. These allow you to take all the parameters necessary to re-create a report and export it into an .mof file. This .mof file can then be shared and reimported to re-create that report. This sure beats opening the report, copying the SQL statement out of the report, pasting it into a text file, and sharing that text file. To export a report, follow these steps: 1. Open the SMS Administrator console and drill down to the Reporting then Reports node. 2. Right-click the report you would like to export and select All Tasks ➤ Export Objects. 3. Click Next in the Welcome dialog box to continue. 4. Select the object you want to export and click Next. 5. Enter a save path and name for the export file. Enter a comment as appropriate. The name and path must end in an .mof extension. Then click Finish. And here’s the process for importing the .mof file: 1. Open the SMS Administrator console and drill down to the Reporting then Reports node. 2. Right-click Reports and select All Tasks ➤ Import Objects. 3. Click Next in the Welcome dialog box to continue. 4. Browse to the path and filename for the exported .mof file. Verify that this is the object you want import, and then click Next. 5. Review the comment associated with this object, and then click Next to continue with the import process. 6. Click Finish to exit the wizard and import the file.

■Note

You can apply this same export process to exporting query objects and collection objects.

Retrieving Converted WQL for a Web Report Earlier, I mentioned that the reports are composed of SQL statements, and unfortunately, the queries that we create so easily within the SMS Administrator console use WQL. The query languages are different, so you cannot copy and paste the contents between the two. Fortunately, there is a secret tool. Well, not so secret, since I’m about to share it with you. The tool is the SMSPROV.log file. The SMSPROV.log file contains a running log of all query commands being processed by SMS against the SQL database. Every time you execute a query operation, it is logged in this file. The upside of this is that each query executed is converted to a SQL query. Now I know you are thinking great, but what’s the catch? Actually, there are two catches:

141


142


• There’s more going on in SQL than just you executing queries. Each time a collection updates, it is executing a query, and that gets logged in SMSPROV.log. You need to watch out for other query actions and not get them mixed up with those you want to use. • If your WQL query has quotes in it—for example, comparing a value with another—those quotes are retained in the SQL query logged in this log file. You need to manually replace each of the double quotes (") with a single quote ('). Follow this process to retrieve your WQL converted to SQL: 1. Open the SMS folder on your site server, and drill into the Logs folder. 2. Among all the log files, you should find the SMSPROV.log file. Open it with your SMS Trace tool. 3. Execute the query that you want to convert. 4. You should see the query execution logged in the SMSPROV.log file. Once that has happened, pause the log file so it does not scroll away on you. 5. Look for the two lines starting with Execute WQL= and Execute SQL=, as shown in Figure 5-26.

Figure 5-26. SMSProv.log showing converted WQL statement 6. Copy the text out of the bottom pane of the log viewer and paste it into your web report. Be sure to clean up some of the content. Typically, the contents of the SQL query should start right after the SQL =, so include only the text that occurs after that point.Don’t forget to clean up the quotes as described previously. In the example in Figure 5-26, you can see that SMS 2003 Toolkit 2 is enclosed in double quotes. You need to change those to single quotes. Your final SQL query statement would look like this:



select all SMS_G_System_SYSTEM.Name0,SMS_R_System.User_Name0 from System_DISC AS ➥ SMS_R_System INNER JOIN System_DATA AS SMS_G_System_SYSTEM ON ➥ SMS_G_System_SYSTEM.MachineID = SMS_R_System.ItemKey INNER JOIN ➥ Add_Remove_Programs_DATA AS __System_ADD_REMOVE_PROGRAMS0 ON ➥ __System_ADD_REMOVE_PROGRAMS0.MachineID = SMS_R_System.ItemKey ➥ where __System_ADD_REMOVE_PROGRAMS0.DisplayName00 = 'SMS 2003 Toolkit 2' ➥ order by SMS_G_System_SYSTEM.Name0 desc Now that you have this precious SQL query statement, you can go ahead and create a web report, as follows: 1. In the SMS Administrator console, drill down to Reports, right-click, and select New. 2. Name the report appropriately, and paste your SQL query into it. 3. You may assign a new category or use one of the existing categories. 4. Complete the process by clicking OK. You’ll return to the SMS Administrator console. 5. Try executing the report to make sure it works as you intended.

■Note On occasion, you may need to alter a permission on a SQL view or table that is referred to by the SQL query. Find the offending SQL view or query in SQL Enterprise Manager and alter its permissions to allow select operations on it by public.

Summary In this chapter, we got into some of the fun stuff you can do with SMS 2003. Software distribution is one of the key areas of functionality of SMS 2003. We ran through the basics of packages and programs, detailing the difference between the two. After the discussion of how to make packages and programs available to clients on your DPs, we walked through the process of creating an advertisement to complete the software delivery. Along the way, you saw how to monitor your packages and the progress of your clients as they execute advertisements. Next, you learned how to create and apply software metering rules to monitor the usage of specific applications in your environment. We then focused on how to create queries. We also looked at a special kind of query, called a subselect query, that is used to find systems that do not match a set of criteria. A subselect query is particularly useful in creating collections that empty themselves out as software is installed to the systems. Finally, we looked at SMS web reports. You saw how to use queries to create new web reports, including a trick to convert the WQL query you created in the SMS Administrator console into a SQL query statement that is usable for SMS web reports.

143


Kruetzfeld_698-6C06.fm Page 145 Friday, October 27, 2006 12:48 PM

CHAPTER 6 ■■■

SMS 2003 Patch Management

P

atches, often referred to as updates, offer more than just fixes to software. They help keep the software running on your desktop and server systems more secure. Of course, you already know that you should update your systems on a regular basis to make sure they are protected. But why should you apply patches using a complex tool such as SMS 2003? You could set up the Automatic Updating feature within your Windows systems and allow them to patch themselves automatically. Or you could use Windows Software Update Services (WSUS), which allows specific patches to be applied to groups of Windows systems. These tools may be adequate for smaller and simpler organizations, but SMS 2003’s services give you more control and accuracy in managing your Windows systems. SMS 2003 provides granular control of which patches are grouped together for distribution to systems. You can determine when updates will be distributed to systems, when they will be applied to systems, and which systems will receive the patches. By being able to control these parameters, you can provide your users a more secure Windows platform while minimizing usage interruptions. This chapter begins with an overview of the Microsoft Operations Framework methodology for managing enterprise changes. Then I will discuss the actual tools to perform those update and patch deployments, focusing on the SMS 2003 Inventory Tool for Microsoft Updates (ITMU). Finally, I’ll suggest some techniques for more effective and efficient patch management.

Patch Management Methodology The Microsoft Operations Framework (MOF) methodology is essentially a set of best practices for organizing and controlling change within the enterprise. MOF methodology consists of the following four phases, which we can easily apply to patch management with SMS 2003: Assess: You need to assess what you currently have in your environment. By performing an assessment, you can determine the security issues that exist and the threats you face. Additionally, this phase will help you to identify how best to respond to new software updates to your systems. Identify: You discover new software updates that are applicable to your environment and identify the urgency in which they need to be applied. Various updates may have different urgencies associated with them, depending on the role and placement of a specific system and the nature of the threat the update addresses. Evaluate/Plan: You evaluate each software update and decide if and how it should be deployed. Included in this phase is testing the update in a quality-assurance or production-like environment to verify that the update does not break existing systems and applications. Not every application can be tested in this environment, but it is important for updates that impact business-critical systems. Deploy: In this phase, you actually deploy the update to your systems, using the data you’ve collected from the previous phases. 145


146

CHAPTER 6 ■ SMS 2003 PATCH MANAGEMENT

■Note

Another standardized methodology to patch management is Information Technology Infrastructure Library (ITIL), which is similar to MOF. See http://www.itil.co.uk for more information about ITIL.

These phases give you control over the deployment and maintenance of the fixes being applied to your systems. You decide what needs to be updated, what updates need to be deployed, how they should be deployed, and on what schedule. Using this methodology, you can successfully deploy updates to systems in a reliable and constant manner. Typically, organizations develop a release schedule that follows Microsoft’s patch release cycle. During the first week following the release of security updates, they will begin the Assess phase. Depending on the change-management requirements of your organization, you may follow through rapidly with the Identify and Evaluate/Plan phases. You may choose to release updates that are identified as critical or updates to systems that have the highest exposure to the vulnerability, following with other systems and updates of less criticality.

■Note

At the time of writing, Microsoft’s patch release cycle starts with the second Tuesday of each month. Some updates are released out of cycle if they are deemed to be of high enough importance.

Many organizations begin the Deploy phase by deploying the updates to less-critical systems (those not running business-critical applications) to help identify any potential issues that may break other more important systems. These lower-priority systems may be IT staff desktops, file and print servers, systems that run from within a virtual environment such as Virtual Server or VMware, or any other system that may be easily repaired or restored from a backup.

SMS 2003 Inventory Tool for Microsoft Updates (ITMU) The primary tool for patch management with SMS 2003 is the Inventory Tool for Microsoft Updates (ITMU). This tool is an add-in for SMS 2003 that automates the deployment of updates. One of the compelling reasons to use ITMU is that it uses the Windows Update catalog. This catalog provides information to support the detection and application of security updates, update rollups, and Service Packs for the following Microsoft products: • Windows 2000 SP4 and later • Windows XP Embedded support • Windows 64-bit edition support • All other Windows components, such as Microsoft XML Parser, Data Access Components, Microsoft Virtual Machine, and others • Office XP and later • Exchange Server 2000 and 2003 • SQL Server 2000 SP4 and later



ITMU consists of the following programs: Microsoft Updates Tool: This tool is advertised and executed on a regular basis on your clients. It returns scan results to the client’s inventory, which will be passed up to the site server at the client’s next hardware inventory cycle. A variant of this program expedites the transfer of the scan inventory by kicking off a hardware inventory cycle on the client immediately after the scan has completed. This tool is also executed just prior to the installation of a patch package, allowing the package to determine which of the included patches need to be installed. This optimizes the delivery of the patches and helps minimize the amount of time you need to apply patches to systems. Microsoft Updates Tool Sync: In order for the Updates Tool to know about new patches, it must be able to reference a catalog of patches from Microsoft. This catalog is updated with new patch information on a regular basis. The Sync program downloads a copy of the catalog from the Microsoft website to be made available locally to your clients executing the Updates Tool. The Sync program is advertised to a specific system that has access to the Internet, typically an SMS site server, and placed on a reoccurring schedule so it runs on a regular basis. This process provides the dynamically updated content that is used to determine if a specific patch is required on a client system when running the Updates Tool. Windows Update Agent Component: The Window Update Agent is vital to allowing the newer Microsoft Baseline Scan Analyzer (MBSA) 2.0 scan engine to operate on a system. The Windows Update Agent Component program installs the required components on client systems that need the Windows Update Agent. This is typically done once per system, prior to executing the Updates Tool for the first time. (By default, this program is linked to the scan tool via the Run First option in the Program’s Advanced Properties tab.) Note that if you have not performed a default installation, you may need to advertise this program separately to your clients.

■Caution

If you fail to update the Windows Update Agent (which is handled automatically if you performed a default installation of the ITMU), the ITMU scan will fail. You may query for the correct version of the Windows Update Agent by checking for wuaveng.dll version 5.8 or later in the %system32% folder. You may build a collection of systems that do not meet this requirement and target the installation of the Windows Update Agent to those systems, rather than pushing it to all systems that will run the Updates Tool.

Installing ITMU The following are the prerequisites for ITMU installation: Windows Installer 3.1 or later: This is considered a mandatory update from Windows Update, so it may have already been automatically deployed in your environment. The Updates Tool actually will run on systems that do not have Windows Installer 3.1, and you may also deploy updates to systems that do not have that version installed. What you will miss out on is being able to deploy updates and patches to Office XP and 2003. Applicable updates for Office XP and 2003 will not be returned as results, and you will not receive any warnings or errors if this is the case. Then you will not know what you are missing on these systems.

147


148


■Tip

You may obtain the Windows Installer 3.1 redistributable package from http://www.microsoft.com/ downloads/details.aspx?familyid=889482fc-5f56-4a38-b838-de776fd4138c&displaylang=en. Then redistribute this package to systems using the command line WindowsInstaller-KB884016-v2-x86.exe /quiet /norestart. This performs a quiet installation and suppresses the restart when completed. (Of course, you will need to restart the systems at some point.) You may opt to advertise the package to clients when they are logged off, but advertise a specific program from the package that does force the restart. Ensure the advertisement expires before the next morning, and then catch the remaining systems with a program configured not to restart their systems. I have found this two-pronged approach works well because it does not disturb users and achieves a high installation and reboot rate among systems.

MSXML Parser 3.0 or later: Most systems should already meet this requirement. If you find that this is not the case, be sure to update them to a current version of MSXML Parser before you deploy ITMU. SMS 2003 SP1 or later: Your SMS 2003 infrastructure must already be patched to SP1 for SMS 2003. This involves applying the Service Pack to your site servers, as well as deploying an updated client version to your systems. Fortunately, the new version of the Advanced Client can be easily distributed with your existing SMS 2003 infrastructure. At this point though, you may as well opt for deploying SMS 2003 SP2 (or the latest one available). SP2 forms the base for further updates, such as the SMS 2003 Operating System Deployment Security Scan Tool Update, which will allow for Windows Vista OS deployments with SMS 2003. As with SP1, the SMS 2003 site systems must be updated with the SP2 files, and the Advanced Client must also be updated. The installation of ITMU is fairly straightforward. It will create collections, packages, programs, and advertisements for you during the installation process. It automatically creates a package and program containing the Microsoft Updates Tool, the Microsoft Updates Sync program, and the Windows Update Agent.

■Note

Don’t worry—ITMU is not about to push every patch published to all your systems. It is quite benign and will not affect your systems by default.

The specific procedure for installing ITMU depends on whether your site is using SMS 2003 SP1 or SP2 or later.

Installing ITMU on SMS 2003 SP1 Sites As noted earlier, you must update your site to at least SMS 2003 SP1 before you can install ITMU. You may want to seriously consider moving directly to SP2 instead, as it is a direct upgrade path and simplifies the ITMU installation process. Here are the steps for installing ITMU on an SMS 2003 SP1 site: 1. Execute the SMS2003ITMU_ENU.exe that you obtained from the Microsoft website. This is a self-extracting executable that will provide several files needed to install ITMU. You will need to provide a destination location for the extracted files.



2. Before you proceed and install the MSI file that was extracted, you must apply some specific hotfixes to your SMS hierarchy. The required patches are included within the SMS2003ITMU_ENU.exe package. Locate the following patches within the extracted files and apply them: • 900257: An update for the SMS Administrator console that allows filenames longer than 64 characters and the automatic selection of related ITMU updates if they are intended to be deployed as one group. You must apply this update to all your site servers and SMS Administrator consoles that you will use to deploy updates. I recommend deploying this to all systems with SMS Administrator consoles. Make sure the SMS Administrator consoles are closed when applying the 900257 hotfix, so you won’t need to reboot the servers. • 900401: A SQL script that must be executed against your SMS site databases to allow corrected software update compliance information to be returned. You will need to execute this script within SQL Server against all SMS site databases on which you will be using ITMU. You do not need to reboot your SMS server after this hotfix, but you will need to stop the SMS services before running this SQL script. • 901034: An update that replaces the Advanced Client source files on the server. You must install this update on all primary site servers, and then update your Management Points (MPs) and Proxy Management Points (PMPs). You will need to distribute a new Advanced Client to your client systems after applying this update. Make sure the update is installed on your primary site servers, and then do a site reset before distributing the client files. Following the site reset, the MP source files will reinstall and update the MP components. If you fail to follow this specific order, you will get duplicate updates listed in the SMS database, with incorrect update ID and product ID information.

■Note

If it is out of the question for you to redistribute the Advanced Client to your systems, you may opt to install hotfixes 899512 and 892044 in lieu of the entire Advanced Client MSI in the 901034 update. This is not the recommended path, but it’s a viable option.

3. In the extraction location that you specified, locate the SMSITMU.msi file and execute it on your site server where you will be installing ITMU. Typically, this site server is your top-level site server within your SMS hierarchy. 4. In the Welcome dialog box, click Next to continue. 5. In the License Agreement dialog box, agree to the End User License Agreement (EULA) by selecting the I Agree radio button. Click Next to continue. 6. In the Destination Folder dialog box, browse to an installation location folder for ITMU, and then click Next.

■Note You may want to install to a data drive, rather than accepting the default location on your server. These tools do not occupy a large amount of space, but it’s generally best practice to install these SMS updates and tools to a drive other than your server’s system drive. Typically, I redirect to the installation location to a data drive and remove the Program Files folder from the path.

149


150


7. In the next dialog box, specify which system should perform the Windows Update catalog synchronization task, as shown in Figure 6-1. If the system that you are performing the installation on does not have Internet access, you may specify a location where the catalog file may have already been downloaded. (If you cannot meet either of these conditions, you won’t be able to proceed successfully through the remainder of the installation.) If you choose to automatically download the catalog from the Web, the system on which you are installing ITMU will immediately connect to the Internet and download the latest version of the catalog. When you’re finished, click Next to continue.

Figure 6-1. Specifying the synchronization host

■Note

The synchronization host must also have the Advanced Client installed at this point. If you are performing the ITMU installation as part of an SMS site server build process, you will want to ensure you have already installed the Advanced Client on this server.

8. In the next dialog box, specify the distribution settings for ITMU, as shown in Figure 6-2. You can allow the installation to automatically create ITMU packages and programs, update all Distribution Points (DPs), and advertise the tool to a test collection that contains a test client that you specify. I typically leave the default name for SMS objects and allow the installation program to create the package for me and distribute it to my DPs. I also usually specify a test system to check that the ITMU installation is working as expected. Click Next to continue. 9. In the next dialog box, select options for automatically distributing the Windows Update Agent to your clients, as shown in Figure 6-3. I often uncheck the “Create a program to install the Windows Update Agent on which the inventory tool is dependent” in favor of creating a collection based on a query for systems that do not have the appropriate version. This avoids sending the Windows Update Agent needlessly to systems that already have the correct version installed. However, it’s a fairly small package, so you may choose to leave this option selected. Click Next to continue.



Figure 6-2. Selecting ITMU distribution settings

Figure 6-3. Selecting Windows Update Agent distribution settings 10. When the Installation dialog box appears, click Next to continue. You will see the installation process execute, creating the appropriate packages, collections, and advertisements, as you specified. Once the installation has completed, click Finish to exit the installation program.

151


152


Installing ITMU on SMS 2003 SP2 Sites Installing ITMU on an SMS hierarchy that has been updated to SP2 is much easier than installing it on an SP1 site, because you do not need to apply any hotfixes or deploy Advanced Client updates or changes beforehand. From either the SMS 2003 SP2 CD or SP2 package downloaded from the Microsoft website, extract the files to a folder structure using SMSSP2.exe /x. You will be prompted to enter a location to place the extracted files. Once the files are extracted, you can install ITMU in either of the following ways: • Via the Autorun.exe GUI that executes when you place your SMS 2003 SP2 CD into the CD drive on your server. Choose the option to install the ITMU Scan Update. • Install the SMSITMU.msi manually, following steps 3 through 10 in the preceding section. Installing it from the separate download is easiest, as you can run the setup program directly. When installing it from the SP2 media, you may need to extract the SP files first from the downloaded self-extracting executable. It does not install by default with the SP2 installation.

Reviewing the Installed ITMU Packages and Programs When you install ITMU, it creates the Microsoft Tools Update package, which contains the programs listed in Table 6-1 to support update scanning for the x86, x64, and IA64 platforms. In addition, you will have Windows Update Agent packages with programs for the x86, IA64, and x64 platforms. As noted earlier, the appropriate agent program must be deployed to all systems prior to running the Updates Tool.

Table 6-1. Microsoft Tools Update Package Programs

Program

Description

Microsoft Updates Tool

Performs Microsoft update scans on x86 clients; results will be sent to the MP at the next hardware inventory cycle of the client

Microsoft Updates Tool (Expedited)

Performs update scans on x86 clients; results will be sent to the MP immediately via a forced hardware inventory cycle

Microsoft Updates Tool IA64

Performs update scans on IA64 clients; results will be sent to the MP at the next hardware inventory cycle of the client

Microsoft Updates Tool IA64 (Expedited)

Performs update scans on IA64 clients; results will be sent to the MP immediately via a forced hardware inventory cycle

Microsoft Updates Tool x64

Performs update scans on x64 clients; results will be sent to the MP at the next hardware inventory cycle of the client

Microsoft Updates Tool x64 (Expedited)

Performs update scans on x64 clients; results will be sent to the MP immediately via a forced hardware inventory cycle

Microsoft Updates Tool Sync

Performs the download of the Windows Update catalog from the Internet; this is commonly advertised to the SMS primary server itself



Setting Up ITMU Now that you have ITMU installed, only a few tasks remain to get it in a usable state. You must first allow the Sync program to execute on a host system in order to provide an up-to-date catalog of updates available for deployment. Following this task, you must perform a scan on your client systems to determine which updates from the catalog are applicable. By default, the ITMU installation creates the basic advertisements needed. Two advertisements are created once the Updates Tool performs the advertisement of the Sync program to the Microsoft Updates Tool Sync collection. The other advertisement advertises the Updates Tool to the Microsoft Updates Tool collection to perform a scan of systems, determining which patches are applicable to each system. This advertisement is typically set on a recurring schedule to keep up-todate records of what patches are deployed or needed by each system.

Executing the Microsoft Updates Tool Here are the steps to run the Updates Tool and execute the Sync program: 1. Open the Microsoft Updates Tool Sync collection and make sure that it has at least one member. This member(s) will be responsible for periodically downloading the latest Windows Update catalog and placing it on the DP for clients to access. 2. Open the Microsoft Updates Tool Sync advertisement. On the Schedule tab, you should note that a recurring schedule has been already configured. You may adjust this schedule to suit your organization’s schedule requirements. Normally, once daily is more than sufficient. Note that Microsoft updates the Windows Update catalog on an as-needed basis during the month, so it is a good idea to update this catalog more frequently than once a month.

■Note Once the initial sync operation has happened, you will want to be sure your DPs have an updated copy of the catalog file. The Microsoft Updates Tool Sync program only downloads the catalog to a source location and does not update the DPs in your organization. You must set the package to update itself on a regular basis. While this DP is being updated, the Updates Tool Sync and Updates Tool packages and advertisements will be unavailable to clients. You should keep your patch packages outside the Microsoft Updates Tool package, for shorter update times. 3. Open the Microsoft Updates Tool package Properties dialog box. On the Data Source tab, enable the Update Distribution Points on a Schedule option. Choose a schedule that corresponds with the schedule of the system performing the synchronization operation to ensure it has downloaded the catalog file. 4. The Microsoft Updates Tool advertisement is set up automatically to advertise a scan operation to find out which patches and fixes are required in your environment. Open the Microsoft Updates Tool advertisement and review its schedule and its targeted collection. It should be targeted to the Microsoft Updates Tool collection. 5. Expand the Microsoft Updates Tool collection. Make sure this collection is populated with at least one test system to run the Updates Tool scan against. For initial testing, I typically run the scan against the server I am working with and at least one representative desktop system.

153


154


■Note

If you examine the contents of the Microsoft Updates Tool collection closely, you will discover a query rule that pulls the clients that have been manually populated into the Microsoft Updates Tool (preproduction) collection. You may add members directly to either collection; it is just a matter of process. If you add systems to the Microsoft Updates Tool (preproduction) collection, you will need to ensure the Microsoft Updates Tool collection has been updated after that (by default, it updates itself every 24 hours) and has the current clients added into it. Adding clients to either collection is fine, but you may be better off following the standard process of adding test clients to the Microsoft Updates Tool (preproduction) collection.

6. After a short time, you should be able to see the Microsoft Updates Tool execute on your test or preproduction systems. Once you have verified it has successfully run on a system, trigger a hardware inventory cycle on that system to push its new update information up to the SMS database. You don’t need to do this if you altered the advertisement to run the expedited version of the scan tool. Otherwise, you may trigger a hardware inventory by opening the Systems Management applet in the Control Panel, clicking the Actions tab, selecting Hardware Inventory Cycle, and clicking Initiate Action.

■Tip

If you need to verify if the hardware inventory cycle is executing, open the Inventory Agent log file. This log file will detail the actions and results taken by the SMS client when performing the inventory action on the client.

Now that you have scan results available in your SMS database, you may perform reporting to see which patches are required in your environment. If you ran the scan tool on enough systems, you can get an idea of how many systems require each patch. This will assist you in prioritizing in your patches.

Configuring the Updates Package Through the SMS Administrator console, you use the Distribute Software Updates Wizard to set up your update distribution. Follow these steps to set up your test distribution: 1. Expand the Software Updates node in the SMS Administrator console. You should see a list of updates, along with the name, bulletin ID, and the number of systems requesting and compliant for each update. 2. Right-click the Software Updates node and choose Distribute Software Updates. 3. In the Welcome to the Distribute Software Updates Wizard dialog box, click Next. 4. Select the scan tool type that you wish to use to distribute updates. At this point, you have installed only ITMU. Once you’ve installed other scan tools, they also will be available here. Ensure the Microsoft Updates Tool is selected and click Next. 5. Click Next to create a new SMS package. Since this is the first time you have used the tool, no Software Updates packages exist yet. 6. Give the package a descriptive name. If you are grouping patches together based on platform or time period, they make good descriptors in the name, as in Dec 06 Updates for Win XP. Click Next to continue.



7. In the next dialog box, you can enter a custom name to be displayed to the end user. This name allows you to make the notification screen appear more legitimate. You may also import a rich text file (.rtf), which might contain other instructions or logos that reflect your corporate branding strategy. Enter a name in the field or leave it as the default (it will not affect the overall functionality of the process). Click Next to continue. 8. In the next dialog box, select the package that contains the scanning tool that you wish to execute on systems. Since you are performing this initial distribution as a test, select Microsoft Updates Tool (expedited) as the program. This will automate the delivery of the scan information to your database via an expedited hardware inventory cycle on each client. Click Next to continue. 9. The Add and Remove Updates dialog box appears. Here, you select the updates to include within the update package. You may apply filters by entering a value in the filter field at the top of each column and clicking the funnel button next to that field. It is possible, and recommended, to apply multiple filters to reduce the number of updates to a manageable quantity. Figure 6-4 shows an example of filtering on only Windows XP and English updates, and then sorting the results based on the Requested column on the right (as you can see, the system requesting updates is missing quite a few of them). Place a check in the box to the left of each update to include it in your updates package. Click Next to continue.

Figure 6-4. Distribute Software Updates Wizard’s Add and Remove Updates dialog box 10. The Specify a Source Directory for Files dialog box appears next, as shown in Figure 6-5. Make sure the package source directory is set to a correct location to store the source files. I recommend creating a folder structure that holds all software updates, and placing each updates package in a separate subfolder beneath the main folder. You may allow the wizard to automatically download the updates for you, or if you have already located the updates, you may specify the source location yourself. Click Next to continue.

155


156


Figure 6-5. Distribute Software Updates Wizard’s Specify a Source Directory for Files dialog box 11. The wizard automatically transfers the required updates from a secure location to your source location. This may take several minutes, depending on the number and size of updates you have requested. Once the transfer has completed, you will see a summary dialog box showing the updates and their relative size. These updates all have had their command lines preconfigured for deployment. You may review the details of each update by clicking the Properties button. Once you are satisfied with the updates and the information provided, click Next to continue. 12. The Update Distribution Points dialog box appears. Here, you can select the DPs on which this package should be available. Since you are still putting together this package for the first time, and are not ready to roll it out to all your clients, specify only the DPs that you require to allow testing of the package. Click Next to continue. 13. In the Configure Installation Agent Settings dialog box, shown in Figure 6-6, you configure how the package will be presented to clients and their systems. You may specify if inventory is collected immediately after patch application. This will increase the load on your client systems, but returns results to the SMS database more quickly for reporting. You can also decide how to handle reboots. Typically, you will want to suppress reboots for servers as a minimum. Some environments disallow the reboot of workstations, too. For this test distribution, choose to collect client inventory immediately and postpone restarts for servers. Click Next to continue.



Figure 6-6. Distribute Software Updates Wizard’s first Configure Installation Agent Settings dialog box 14. The next dialog box contains more Installation Agent settings to configure, as shown in Figure 6-7. These options are associated with how updates should be installed. In the example, the updates are configured to be installed in an unattended manner, and the restart is delayed for 90 minutes. If any update takes longer than 30 minutes to install, it will be canceled. The maximum installation time is set to 90 minutes. If the installation of the updates package runs longer than that amount of time, remaining updates will be deferred and not applied. The Maximum Run Time and Maximum Installation Time settings are separate values. The first refers only to individual updates, and the second applies to the whole update package as a group. After configuring these options, click Next to continue. 15. The wizard shows a third dialog box with Installation Agent settings. These options are associated with notification of the user for the pending installation of updates. In the example shown in Figure 6-8, users will not be allowed to postpone updates being applied in unattended operations, but they will be able to postpone reboot actions on their systems. After making your selections, click Next to continue. 16. You have now finished the configuration of the updates package that you will distribute to your clients. Click Finish to complete this process. The only remaining task is to actually advertise this update package to your client (or test client in our case).

157


158


Figure 6-7. Distribute Software Updates Wizard’s second Configure Installation Agent Settings dialog box

Figure 6-8. Distribute Software Updates Wizard’s third Configure Installation Agent Settings dialog box



Creating the Advertisement Create an advertisement to a collection of test clients. You may schedule the advertisement however you like. (See Chapter 5 for details on creating advertisements.) Remember that ITMU is intelligent enough to apply updates only as required and applicable to a system. Just because you added an update into a package does not mean that it will be applied to all systems to which it is advertised. You may choose to group your updates for all platforms into a single update package, perhaps still separating server and workstation platforms, but keeping all Windows XP, XP SP1, XP SP2, and Windows 2000 SP4 updates in one updates package. This is legitimate, but does make for a larger package to be transferred. I suspect you can see what I am getting at here: if this is a download and execute advertisement, every client will download the entire set of updates into their cache, but will execute only the ones applicable to their platform.

■Caution I don’t recommend making your updates package a download and execute package if it contains more than a single or perhaps two months’ worth of updates. If you did that, systems would end up downloading the entire content, even if they did not need all the updates. This is especially true if you integrate updates for multiple OS platforms into a single updates package. You may choose to make the advertisement have a reoccurring schedule. This will assist in ensuring the updates are applied and systems are kept current. Typically, I recommend rolling up monthly updates into packages that contain three months’ worth of updates on a per-OS basis. You may keep these updates packages advertised to collections that match your OS type. This seems to be an optimal setup to reduce complexity and network impact, while still keeping those systems upto-date without any additional complexity.

Troubleshooting Update Deployment Occasionally, something may go wrong during a deployment of updates to your client systems. Since this is a complex process, it helps to have an insight into the internal ITMU processes. ITMU comes equipped with a good set of logs that you may reference to determine the underlying issue. For example, the sync process may take a long time during setup for the tool (such as 5 to 15 minutes), depending on the machine. If you have doubts about the length of time of sync during setup, check the WUSSyncXML.log file in the CCM\Logs folder on the site server to verify that updates are being inserted. Table 6-2 lists the log files associated with the ITMU, where to find them, and what each contains.

Table 6-2. ITMU Log Files

Name

Location

Description

SMSWUSHANDLER.log

CCM\Logs folder on the client

Contains the results of the inventory tool scan

Advertisement.log

Installing user’s temporary folder on the site server

Contains the results of the creation of collections, package, program, and advertisements created during the setup process

SMSCLIUI.log


Reminder text and user icon interactions configured for the updates package

159


160


Table 6-2. ITMU Log Files (Continued)

Name

Location

Description

PatchUIMonitor.log


Activities performed by the reminder service regarding scheduling of reminders and other system tasks related to patch management

EXECMGR.log


Tracking information for all SMS programs the client is executing

Patchinstall.log


Actions performed while installing patches when the main advertisement is running

WUSSyncXML.log

CCM\Logs folder on the site server

The results of the overall catalog download process

PatchDownloader.log

System temp or User temp on the site server

The results of the detailed patch download and catalog download process

Other Scanning Tools If your SMS 2003 infrastructure is not ready to support the improved functionality of ITMU and its updated scanning engine, older scanning tools are available. Additionally, there are other scanning tools that provide enhanced functionality for SMS 2003, including scanning and delivery of updates for hardware vendors, account review scans, and more in-depth scanning for updates not covered by the ITMU scan engine. Here is a summary of the other scanning tools available: SMS 2003 Account Review Tool: This tool is designed to assess the SMS accounts in use within a central and/or child sites and to alert you about any account configurations that may assist in compromising security in your organization. This tool is not typically a daily-use tool, but designed to be run on a periodic basis as part of a security audit process. SMS Inventory Tool for HP ProLiant and Integrity Update: This tool allows SMS 2003 to scan and manage the distribution of updates applicable to HP ProLiant and Integrity systems. These updates include support packs, drivers, ROM, and software agents to servers. This tool provides additional reports that allow you to review inventory and configuration information pertinent to your servers. IBM Systems Update Tool for Microsoft SMS: This tool assists in allowing SMS to manage IBM updates for IBM eServer and IBM eServer xSeries servers. These updates include drivers and firmware. SMS 2003 SP1 Scan Tools: This tool set is the older scan tools used by SMS 2003. There are two separate scan tools: one to manage Windows patches and another to manage Office patches. Each is a separate download. Installation and configuration are very similar to that for ITMU. SMS 2003 Inventory Tool for Dell Updates Version 3: This tool assists in allowing SMS to manage Dell updates for Dell servers. These updates include BIOS, drivers, and firmware. SMS Extended Security Update Inventory Tool: This tool is periodically updated to detect specific security bulletins that are not covered by ITMU. Installation is fairly similar to the other Microsoft scanning tools; however, no sync operation needs to be performed.



Patch Application Techniques and Tricks There are no hard-and-fast rules regarding the right or wrong way to apply updates to the systems in your organization. The bottom line is that any method that is easily managed and effective is a good method. That being said, I’ll suggest a few techniques for efficiently deploying updates.

Update Schedules One of the basic pieces of the patch-management methodologies to consider is when the updates will be applied to systems. Typically, when given a chance, a user will cancel or postpone an installation of updates. Unattended installations are an easy way to mitigate this, but do present the problem that you may potentially impact the users’ system performance while they need to use their system. This is where scheduling comes in. You probably want to push your updates to systems so you can install during off-peak hours. But are these systems available then? Are they powered on? What happens when a system that was powered off comes back online? Do you let the updates proceed to install as soon as possible when that system is powered up? Creative use of schedules in SMS 2003 can help by making advertisements mandatory during off-peak hours, and expiring the advertisements prior to the start of the business day. Additionally, you can configure another variant of the updates package to catch the systems that powered on later and missed the off-hours distribution/installation process, offering an interactive approach to the update distribution during business hours. Alternatively, you can turn to a more technology-based solution such as Wake on LAN (WOL) and managed shutdown of systems. For these solutions, you need to look to third-party products to integrate with SMS 2003. In Chapter 8, we will visit a few third- party options for performing such actions.

SMS Reporting on Patch Status After you have installed ITMU, you will have a few reports on patches and compliance status. However, in my opinion, these are not straightforward and don’t give the level of detail needed for an overview with an appropriate drill-down for further details. Quite a few reports are available for free within the SMS community. One of my favorite set of reports for patch management comes from Warren Byle. Warren released a set of two web reports for SMS 2003 that simplify display of patch status for systems in your environment. These reports offer a quick view of each system’s compliance, with an available drill-down to a specific machine to find exactly which patches are applicable to that machine and the current status of the patches. These reports were originally written for SMS 2003’s older patch management system, but were easily ported over to use the revised database tables that ITMU provides. I will discuss accessing free resources such as these reports in Chapter 8.

Summary What fun we are having now! Using SMS 2003 for patch management with ITMU seems like a great alternative to using other systems. This chapter began with an overview of MOF, a methodology that you can apply to have a standardized and planned approach to applying updates to your systems. Then we focused on ITMU—installing it and setting it up for automatically deploying updates. The ITMU is not the only update tool on the block, so we also took a quick look at some of the other scanning tools available. Finally, I suggested some techniques for efficient patch management, including scheduling scans in your environment and reporting the patch status of systems.

161


Kruetzfeld_698-6C07.fm Page 163 Tuesday, October 31, 2006 6:58 AM

CHAPTER 7 ■■■

SMS Feature Packs

S

MS Feature Packs are add-on packages from Microsoft that extend the original feature set of SMS 2003. This chapter focuses on the SMS Operating System Deployment (OSD) Feature Pack and the Microsoft Solution Accelerator for Business Desktop Deployment (BDD), which integrates directly with the OSD Feature Pack. We’ll also take a brief look at the SMS Device Management Feature Pack and the SMS Administration Feature Pack.

SMS Operating System Deployment Feature Pack The SMS OSD Feature Pack allows you to capture Windows OS images and deploy those images to other machines. The SMS OSD Feature Pack captures and stores the OS image in a different way than other imaging tools do. Typical imaging tools read hard disks on a sector-by-sector basis and compress the data as read by the tool. Rather than scanning the disk at the sector level, the Feature Pack’s tool scans the file structure and saves it in a proprietary format called Windows Imaging (WIM). This method has three main advantages: • By reading only the files, the tool is not scanning empty disk sectors. • By reading the file structure, it has intimate knowledge of the files that exist, and is able to optimize the file storage in the WIM image by placing pointers. It keeps only one copy of each file, and generates a pointer for any other matching file that is found. Since it’s common to have duplicates of files such as DLLs, you will see a space savings in the image size. • Many other tools maintain backward-compatibility with their previous version’s format, so the compression algorithms have changed little over time. The WIM format presented an opportunity to introduce new, higher-compression algorithms into the process. These optimizations allow a typical image size to be reduced by a factor of more than 3:1; that is, a 6GB image is commonly reduced to a size of around 2GB. The time to restore such images is commonly around 15 to 20 minutes. The time taken to capture such an image is significantly longer, but the great reduction in image deployment time is well worth the trade-off. The OSD Feature Pack includes the ImageX tool for file-structure scanning. It also includes Windows Preinstallation Environment (PE), a lightweight version of Windows with somewhat limited abilities. It reboots every 24 hours, so you can drop any hopes of using it as a replacement OS. What Windows PE does provide is a 32-bit environment where you can access WMI and hard disks, and perform various scripting actions through batch, CMD, Windows Scripting Host (WSH), or Visual Basic scripts. The version that comes with the OSD Feature Pack requires no additional licensing (other than the SMS 2003 licensing), so it truly is a free tool. You can’t really use it outside the OSD Feature Pack capture and deployment scenarios, though. 163


164

CHAPTER 7 ■ SMS FEATURE PACKS

■Note

You may still see ImageX referred to as XImage, as Microsoft changed its name to avoid confusion with a Dell tool of that name. ImageX is also available as a tool for deploying Windows Vista.

Installing the SMS OSD Feature Pack To use the SMS OSD Feature Pack, your SMS 2003 site must, at minimum, have SMS 2003 SP1 applied. This is also a requirement for installing any of the Feature Pack components on your desktop system for use with the SMS Administrator console. SMS 2003 SP2 is recommended, in order to support upcoming updates to the Feature Pack. Like many Microsoft downloads, this OSD Feature Pack comes in a self-extracting package. You must extract the components to a folder prior to installation. First, extract the files from the SMS2003OSDFP.exe file to a folder. Then execute OSDeployment_ Setup.exe to start the installation process. You use the same setup file for both SMS server installations and SMS console installations. Step through the setup program to complete the installation.

■Note

The installation is fairly straightforward, but be aware that you must have the Advanced Client network access account configured prior to using the SMS OSD Feature Pack.

Now that you have the OSD Feature Pack installed, you need to create an OS image capture CD and then actually capture an image.

Creating an OS Image Capture CD To capture an OS image, you first must create an image capture CD. You will use this CD to prepare the reference computer for imaging and to load the capture tool from within the Windows PE environment to perform the capture of the OS and application files. Before proceeding, you need to locate the 32-bit (or Windows XP) driver for the network card in the desktop platform from which you will be capturing the OS. Chances are you already have the installation media for that hardware. Alternatively, you may find it on the hardware vendor’s website as a free download. You only need the actual driver files, not the setup.exe and other executables associated with the driver installation package. Typically, these driver files take the form of .inf, .sys, and .cat files. Locate these driver files for your network card(s) installed on your desktop systems and store them in a folder for later use. The following are the other items you will need: • A CD burner to create your OS image capture and deployment CDs. • Some room to store your images. A typical image is 2GB to 4GB, and depending on the number of images, you may require significant storage space. Set up this location as a share. I typically name the share as WIMImages. • A copy of Microsoft’s System Preparation Tool, Sysprep, that is applicable to the version of Windows that you are capturing. Sysprep prepares an OS for cloning. You don’t need to worry too much about configuring Sysprep, as most configuration options are available from within the OSD Package and Program Properties dialog boxes.



■Tip

To obtain Sysprep, you can download the Windows Deployment Tools from the Microsoft website. Search the downloads section for “deploy tools” and choose the correct download to match your OS. The Deploy.msi file will install the Sysprep tools that you will need. Don’t do this on your reference computer, do it somewhere else and copy the Sysprep files over to a C:\Sysprep folder on the reference computer.

Follow these steps to create an OS image capture CD: 1. In the SMS Administrator console, right-click the Image Packages node and select All Tasks ➤ Create Operating System Image Capture CD. 2. The Operating System Image Capture CD Wizard starts. Click Next to continue. 3. In the Windows PE Settings dialog box, place a check in the Additional Network Drivers box and specify the location where you saved your network card drivers. Click Next to continue. 4. In the Create CD Image dialog box, enter a save path for the CD ISO file. Typically, I use a path like x:\OSD CD Images. Click Next to continue. 5. Once the wizard has completed creating the ISO image, the CD Creation Complete dialog box is displayed. Click Finish to complete the process. 6. Burn the ISO file to a CD or DVD (only if all your systems have DVD ROMs). Your OS image capture CD is now ready to use.

Capturing an OS Image Using the OS Image Capture CD Now that you have created the OS image capture CD, you can use it to capture an installed OS. Typically, you will follow a standardized process for creating a reference image—an installed copy of your OS, configured as needed and with the basic applications that are common to most users. Follow these steps to capture the OS image: 1. Take your reference computer out of your domain if it is not already outside the domain. You may not capture an image of a reference computer that is on a domain using the SMS OSD Feature Pack. 2. Copy the appropriate version of Sysprep and its related files into a folder (such as C:\Sysprep) onto your reference computer. 3. Insert your OS image capture CD into the master computer. This CD should auto-run. If it does not, manually browse and execute the OSDICW.exe file in the root folder of the CD. 4. The OSD Image Capture Wizard starts. Click Next. 5. When the Image Destination dialog box appears, enter the image filename (such as XP.wim), network location (such as \\SMSServer\WIMImages), account name (such as Corp\ ImageAdministrator), and password. Note that the account name specified here should have change access in the share where you are storing the WIM images. Click Next after you’ve filled in the dialog box. 6. In the Sysprep Information dialog box, enter and confirm the local administrator password. Then click Next. 7. In the Image Properties dialog box, specify the properties that you want to use. This information is purely optional and can include any descriptive text you would like to include. Commonly, the image version is placed in a Registry key on the reference system, and also placed in this information area. The OS version information is inserted automatically for you. Click Next to continue.

165


166


8. The Capture Image dialog box appears. Click Finish. The Image Capture Wizard will now begin to run Sysprep on the reference computer. When it has completed, it will shut down the system automatically. 9. Power up the reference computer and boot from the CD to complete the OSD image capture process.

■Caution

If you let the system boot into Windows, rather than from the CD, you will need to restart the image process from the start, as Sysprep will run automatically.

10. Once the reference computer has booted from the Operating System Image Capture CD, the Image Capture Progress window is displayed. The progress bar indicates the amount of time elapsed and time remaining. Once the Image Capture Wizard has finished, you will find a copy of the WIM file that was captured at the network location you specified. The capture of the OS image may take up to an hour or more, depending on the size of the reference image. Remember that the WIM image format is optimized to create the smallest possible image, so it will take longer than other image-capture tools you may have used in the past. Typical issues during this process include low network connectivity, server disk space, and either not including the network card drivers or including the wrong ones.

Creating an OSD Image Package Now that you have successfully captured an OS and created a WIM image file, you need to tell SMS 2003 about it. You do this by creating an image package. The program you’ll define for this package is just an instance of how the package source files will be used. Then you need to ensure it is available at a suitable DP for deployment. (See Chapter 5 for details on creating packages.) Follow these steps: 1. In the SMS 2003 Administrator console, right-click the Image Packages node and select New ➤ Operating System Image Package. 2. The New OS Package Wizard starts. Click Next to continue. 3. In the OS Package Settings dialog box, enter a package name (such as XPMaster), your image file with its path (such as C:\WimImages\XP.wim), and the package source location (such as \\SMSServer\WIMImages\Packages\XPMaster, which uses a subfolder in the WIMImages share for the OSD image packages). Click Next to complete this step. 4. When the New OS Package Wizard Complete dialog box appears, click Finish. The packagecreation process may take several minutes to complete. 5. When notified that the DPs must be updated, click OK.

■Caution

Remember that you are dealing with large files here. Inadvertently assigning a DP across a small or saturated WAN link can be career damaging.

6. In the SMS 2003 Administrator console, locate the new OS package you just created and expand it. 7. Right-click the Programs node and choose New ➤ Operating System Program.



8. The New OS Program Wizard starts. Click Next to continue. 9. In the New Program Options dialog box, enter the program name (such as WindowsXP), and then click Next. 10. In the Licensing Settings dialog box, enter the product key that is suitable for your OS, and then click Next. 11. In the Membership Settings dialog box, enter the domain (such as Corp). Then click Set to enter the user credentials to add the machine to the domain. Fill in the account and password fields. Deselect the option to create a random password for the local administrator on the target machine. Then click Next. 12. Click Finish in the New OS Program Wizard Complete dialog box.

■Note Now that you have set up the basic parameters of the image program, you can see it in the Image Packages node in the SMS Administrator console. By clicking the Programs item beneath it in the tree, you can view the new program in the details pane on the right side of the console. 13. In the SMS Administrator console, right-click the image package you created and choose All Tasks ➤ Manage Distribution Points. 14. The Manage Distribution Points Wizard starts. Click Next to continue. 15. Select the Copy the Package to New Distribution Points option, and then click Next. 16. Click Select All, or at least choose one DP (such as SMSServer) for the package, and then click Next.

■Caution

A big package is about to be replicated to DPs.

17. Click Finish to begin the package distribution. Distribution to your DPs will take probably take a while. As discussed earlier, OS images are quite large. For example, a typical Windows XP image can be more than 2GB.

Deploying the Captured Image Now that you have captured an image, you need to be able to deploy it. There are two major methods of deploying images: through an SMS advertisement or by using an OS image installation CD. Distributing the captured OS image to other systems through standard SMS advertisements is a “Lite-Touch deployment” approach. It can be triggered remotely and does not require anyone to insert boot media into the targeted systems. However, someone still needs to be present to enter a few details prior to starting the imaging process on the target machine.

■Note

Totally automating the deployment, or “Zero-Touch deployment,” is possible using the Microsoft Solution Accelerator for BDD.

167


168


When an image is delivered via an SMS advertisement, the Windows PE boot media is downloaded to a safe folder location on the local hard disk. The boot sector is modified to reference this new boot media source location. Using an OS image installation CD is similar to deploying an image via an SMS advertisement. Essentially the same process is at work when booting from this CD, except the Windows PE boot media is copied directly from the CD source.

■Note

Whichever deployment method you use, the WIM image is still transferred across the network link. However, you can apply a customization that will allow you to use download and execute advertisements with the SMS OSD Feature Pack. See http://www.microsoft.com/technet/desktopdeployment/depprocess/osddlex.mspx for an excellent article on how to implement download and execute deployment for OSD imaging.

Advertising the Image Package To deploy an image in Lite-Touch fashion using standard SMS advertisements, follow these steps: 1. In the SMS Administrator console, right-click Advertisements and select New ➤ Advertisement. 2. On the General tab, specify the advertisement name (for example, Windows XP Upgrade), the package (for example, XPmaster), the program (for example, WindowsXP), and the collection (for example, a collection containing one or more Windows XP machines). 3. Click the Schedule tab, and then click the yellow star button to add a new mandatory schedule. Click OK to accept the schedule date and time. Then click OK to create the advertisement. The advertisement will now be made available to all of the systems listed in the specified collection. Once accepted by the client machine, SMS will begin the upgrading process automatically.

Creating and Using an OS Image Installation CD The other method of image deployment involves creating an OS image installation CD. This bootable CD contains Windows PE and the appropriate network drivers, allowing it to contact the SMS infrastructure to transfer a copy of the image to the local system being imaged. For example, if the computer has an unformatted drive, you can deploy the image by booting from the OS image installation CD. If you want to upgrade an existing computer to the new OS, you could deploy the new OS by running OSDInstallWizard.exe from the OS image installation CD.

■Note

The OS image installation CD can be used with a Remote Installation Services server (a simple component you may add to your Windows 2000/2003 server). The SMS OSD Feature Pack Guide contains instructions on how to do this.

Creating an OSD Image Installation CD Follow these steps to create an OS image installation CD: 1. In the SMS Administrator console, expand the Image Packages node. 2. Right-click the Image Packages node and select All Tasks ➤ Create Operating System Image Installation CD.



3. When the Welcome to the Operating System Image Installation CD Wizard dialog appears, click Next. 4. In the Installation Settings dialog box, choose the installation options you want the OS image installation CD to use. You must select either “Allow installation of Operating System Packages from a location provided by the local computer installer” or “Allow installation of Operating System Packages from SMS distribution points.” Click Next to continue. The next dialog box that appears depends on one or more of the options that you selected here. 5. If you selected to install from SMS DPs, you’ll see the Install from SMS Distribution Points dialog box. Choose the image package(s) that you want the OS image installation CD to use. 6. You may see the Automatically Select Operating System Package dialog box, which allows you to automate the OSD package installation by running a script. For now, you can leave it blank. You will manually choose which OS package to install at deployment time. 7. In the Windows PE Settings dialog box, specify any network drivers or additional storage drivers that may be needed. Typically, you will need to specify only your network card drivers. Windows PE comes with a selection of popular network card drivers already built in, but they are somewhat aged and do not contain the latest driver version or model needed. Enter the local or UNC path for each driver location. 8. In the Create CD Image dialog box, enter a name for the CD you are creating (such as OSD Image Installation CD). When possible, I also use a name that indicates the network drivers included. Enter a local or UNC path to where you want to store the OS image installation CD image. Remember that it is creating an ISO file that you must burn to a CD or DVD. Click Next. 9. The wizard will create the CD image. Once it has completed, click Finish.

Using the OS Image Installation CD After you have created an OS image installation CD, you can use it to install an OS on a computer, as follows: 1. Insert the OS image installation CD and boot the computer to launch the OS Image Installation Wizard. If the wizard fails to launch (perhaps auto-run is disabled on the system), browse the CD contents and execute OSDInstallWizard.exe manually. 2. When the wizard starts, click Next to continue. 3. In the Operating System Image Selection dialog box, select the image that you wish to deploy. Select the appropriate package from the list, and then click Next. 4. The next dialog box allows you to install from another location, in case an SMS DP is not available. Make your selection and click Next. If you did not to choose to install from another location, proceed to step 6. 5. Enter the network path and folder where you stored the image package. Enter the UNC path to the share and folder that contain the image package source. Enter an account and password that has access to that network location where the image package is stored. Then select the appropriate program associated with the image package from the Configuration list. Click Next to continue. 6. In the Transfer Files and Settings dialog box, enter a location for transferred files and settings. You may either use the settings provided by the SMS administrator or enter a UNC path and folder. You must specify an account and password with appropriate access to that network location. Click Next.

169


170


■Note

The transfer of files and settings is dependent on the usage of the User State Migration Tool (USMT) within the program properties of the image package. For the use and configuration of USMT, I suggest that you engage a Desktop Deployment Planning Service (DDPS) from one of Microsoft’s Gold Partners certified in the delivery of such complex materials. These engagements cover USMT and more, including Zero-Touch Installation technology and processes.

7. In the Computer Configuration dialog box, enter the new computer name. Click Next to continue. 8. In the Operating System Installation dialog box, click Finish to complete this process and start deploying the image to the system. So far, you’ve learned about the basic operations of the SMS OSD Feature Pack. Next, we will build on this using some key components from the Solution Accelerator for BDD.

Solution Accelerator for BDD The Solution Accelerator for BDD version 2.5 contains guidance, tools, and scripts to optimize the creation and delivery of the Windows OS. Here, I’ll explain how to get up and running with the BDD tool set to use the Windows unattended build process. This involves installing and configuring BDD, and then building a reference computer image.

■Note The Microsoft Solution Accelerator for BDD offers extensive resources. Start at http://www. microsoft.com/technet/desktopdeployment/bddoverview.mspx#addprev. The Team Guides provide a lot of details. For example, to find out more about the folder shares used by BDD, see the Computer Imaging System Feature Team Guide.

Setting Up BDD Setting up BDD in your environment involves several main tasks: • Downloading and installing BDD • Creating folder shares • Copying over the media • Installing the media Before you proceed, make sure you have all the prerequisites for BDD, which we’ll look at first.

BDD Requirements BDD has quite a few prerequisites, but since you’re starting with SMS 2003 installed, you have half the requirements covered. You will probably want to start with BDD in a test or lab environment. so let’s see what you need to make that work. First, you must have an infrastructure server and/or image build/deployment server. This can be any computer—a workstation or server—that meets the hardware compatibility requirements of running Windows Server 2003 Standard Edition or Enterprise Edition and also has the capacity to host Active Directory, DNS, and DHCP for the lab environment. It will also host the build files and



images. While the system has no specific dependencies on the build computer itself, the computer should have at least 60GB of disk space and some form of backup equipment, such as a tape drive or a storage area network (SAN). It is reasonable to roll this all into a single, well-equipped server.

■Tip

Hardware costs money, right? Why not spring for a decent class server with adequate memory and disk space, and leverage some of the free/low cost virtual server offerings available from Microsoft or VMware? You may build the physical server as a member server in a workgroup and keep all the other server components (Active Directory, DNS, DHCP, SQL Server, SMS 2003, RIS, and BDD) on one or more virtual servers, all hosted on the one box. While you’re at it, you can use this virtual environment for performing test builds and migrations without having to image and reimage physical desktops. In addition, Windows PE typically supports the network adapters built into the virtual environments without additional drivers.

Obviously, you will need an SMS 2003 infrastructure, an Active Directory infrastructure, DHCP services, and DNS services. For your client workstations, any unique type of workstation configuration that will be found in production should be duplicated in the lab. This allows for testing each hardware configuration. It can also be helpful to have the client workstations connected to a KVM switch to minimize the floor space needed to host the workstations.

■Tip

I always push for flat-panel displays just because of the space savings and lower heat dissipation (not to mention flicker-free display) in my labs. Anyone who has to spend amounts of time in a lab room with several systems running, with their associated video displays, will appreciate less heat being generated.

You’ll also need network switches and cabling; 100Mbps or faster is recommended to accommodate the high volumes of data. You should have Internet access available in order to download new patches, service releases, and hotfixes. And, of course, to make the media, you’ll need a CD or DVD burner. The software requirements are as follows: • Windows 2003 Server Standard Edition • Microsoft .NET Framework 1.1 and its relevant service pack and update • SQL Server 2000 (SP3 minimum) for the SMS and BDD databases • Windows XP Professional with SP2 media, available on the volume license media (Microsoft Select CDs), and volume license keys (you don’t have to use SP2, but why wouldn’t you these days?) • Office 2000 or 2003 media, available on the volume license media (Select CDs), and volume license keys • Office 2003 SP1 or SP2 media, available on the volume license media (Select CDs) or downloadable equivalent • Windows PE 2004 or 2995 media, available on volume license media (Select CDs) • Any additional application media to be included in the images, such as PDF readers • Any hardware-specific software, such as drivers, CD-ROM burner software, and DVDviewing software

171


172


Downloading and Installing BDD With SMS 2003, you use BDD Enterprise Edition version 2.5. Here, I will describe the procedures for setting up a typical BDD lab, using one server to serve both the image build (deployment) and infrastructure roles. Follow these steps to install BDD: 1. Gather all the required software for a client and compile it onto a DVD (yes, dual-layer DVDs are handy). On the DVD root, create a Tools folder to contain all your downloaded tools. I’ll refer to this DVD as the BDD DVD in these instructions.

■Note

This DVD setup is my recommendation. It works well as a backup and a source when performing the setup of the various tools needed. If you don’t have access to DVD burner, you can devise your own system with CDs or other storage. 2. Log on to your infrastructure/image build/deployment server as a user with administrative rights. I will refer to this server as ImageServer throughout these instructions. 3. Insert the BDD DVD and navigate to the Tools folder. Locate the folder where you placed BDD 2.5. 4. Double-click BDDEnterprise.msi to begin the installation process. 5. Click Open in the initial screen, and then click Next. 6. Agree to the License Agreement and click Next to continue. Click Next again to move past the BDD Information page. 7. In the Select Installation Folder dialog box, click Next to accept the default location for the installation (C:\Program Files\BDD Enterprise 2.5\). This assumes that the C:\ has at least 40GB of free disk space. I typically place this on a secondary drive rather than the system partition. 8. In the Confirm Installation dialog box, click Next. 9. After the wizard has installed all the files, click Close. Although BDD has been installed, we are far from done here. The installation placed only some of the files you need into the file structure. You also need to create several shares.

Creating BDD Folder Shares To configure the server for the image-creation process, you need to create several shares on ImageServer. These shares host the basic computer image build environment. Follow these steps to create the folder shares: 1. On ImageServer, use My Computer to navigate to the Computer Imaging System folder under C:\Program Files\ BDD Enterprise 2.5. 2. Right-click Computer Imaging System and select Sharing and Security from the context menu. Select Share this Folder and enter Unattend as the share name. Click Permissions and give Full Control permissions to the Administrators group. Then click OK.



■Caution

We are building a lab environment. Best practices dictate that you should be more selective about the permissions you apply to these shares in a production environment. Refer to the BDD 2.5 Computer Imaging System documentation for notes on tightening share permissions. 3. Right-click the Zero Touch Installation folder and select Sharing and Security from the context menu. Select Share This Folder and enter ZTI as the share name. Click Permissions and give Full Control permissions to the Administrators group. Then click OK. 4. Right-click the Lite Touch Deploy folder and select Sharing and Security from the context menu. Select Share This folder and enter Deploy as the share name. Click OK to accept the default permissions for the shared folder.

■Tip

I like to keep the share names standardized, as it is easiest way to refer to them in the BDD documentation— all 1,000 pages of it.

5. Verify that you have UNC access from the Run command on ImageServer to the following shares: • \\ImageServer\Unattend\Applications • \\ImageServer\Unattend\Boot Disks\WINPE\Extranics • \\ImageServer\Unattend\Master $OEM$\$OEM$\$1\Microsoft • \\ImageServer\Unattend\Source • \\ImageServer\Deploy • \\ImageServer\ZTI

Copying Over the Media Now that you have the shares set up, you must copy over the media that you have collected. Since you gathered it and placed it all on a DVD, it should be easy to find and copy, right? Everything has a place, and you will become more familiar with the locations as you use the system more and more. Service packs, hotfixes, and updates must also be downloaded and copied into their appropriate folder locations. The BDD installation you performed created several folders and copied scripts, templates, and configuration files to those folders. The Computer Imaging System folder structure’s main purpose is to host the Unattend share and the subfolders. It also acts as a repository for any image files that may be created from the workstation. Table 7-1 describes the layout of the folder structure created inside the Unattend folder. You may move this folder structure and share to another server, but you will need to update any references to the original server name in text and XML files.

173


174


Table 7-1. BDD Unattend Folder Structure

Folder

Description

Applications

Applications for installation during the image build process.

Applications\MBSA2.0

Files to install the Microsoft Baseline Security Analyzer (MBSA) 2.0 application (optional).

Applications\MUIInst

Top-level folder for the Multilingual User Interface (MUI) application (optional).

Applications\Office2003

Office 2003 files and transforms (optional if Office is not part of your core image).

Applications\Office2003MUI

Office 2003 MUI files (optional).

Applications\SMS2003Client

SMS 2003 Advanced Client installation files

Applications\SystemUpdates

System updates and security fixes that should be applied to the image prior to Sysprep (optional).

Applications\Windows Installer 3.1

Files to install Microsoft Windows Installer 3.1.

Boot disks

Top-level folder to hold boot disk files.

Boot disks\WINPE

Top-level folder for Windows PE customization files.

Boot disks\WINPE\Deploy

Subfolders and files that are copied onto the Windows PE CD image when you create a Deploy CD. Used in the Lite-Touch deployment scenario.

Boot disks\WINPE\Extranics

Subfolders and files that are copied onto the Windows PE CD image. The folder contains the network interface card drivers.

Boot disks\WINPE\Extranics.x64

Subfolders and files that are copied onto the Windows PE CD image. The folder contains the network interface card drivers.

Boot disks\WINPE\Lab

Subfolders and files that are copied onto the Windows PE CD image when you create a Lab CD.

Control

Batch files for starting the build process, distributing the $OEM$ directories, and building Windows PE CDs. The folder holds the Unattend.txt files and uniqueness database. Note that the Unattend.txt and Sysprep.inf files aren’t created until the first time you run Config.hta.

Master $OEM$

Top-level folder for the $OEM$ folder structure.

Master $OEM$\$OEM$

The root of $OEM$ that is copied to the workstation as part of the build process.

Master $OEM$\$OEM$\$1

The contents of this folder are copied to the root of the system drive (C:\) during Windows setup.

Master $OEM$\$OEM$\$1\Dell

Subfolders and files specific to Dell hardware. Unlike the files in the Drivers folder, these must be installed using a setup routine. They contain applications such as keyboard settings and DVD software.



Table 7-1. BDD Unattend Folder Structure (Continued)

Folder

Description

Master $OEM$\$OEM$\$1\Drivers

Subfolders and files that are added to the OEMPNPDriversPath statement in the Unattend.txt file so that Windows can automatically find and install these additional drivers during setup using Plug and Play detection. Files are typically broken down by hardware platform (that is, Drivers\ Vendor\Model\Video).

Master $OEM$\$OEM$\$1\HP

Subfolders and files specific to HP hardware. Unlike the files in the Drivers folder, these must be installed using a setup routine. They contain applications such as keyboard settings and DVD software.

Master $OEM$\$OEM$\$1\Microsoft

Subfolders and files specific to Microsoft hardware. In this case, the folder contains the Microsoft Virtual PC additions, used to improve virtual machine performance when the image is deployed to Virtual PC.

Master $OEM$\$OEM$\$1\Motion

Subfolders and files specific to Motion Computing tablet hardware. Unlike the files in the Drivers folder, these must be installed using a setup routine. They contain applications such as keyboard settings and DVD software.

Master $OEM$\$OEM$\$1\Toshiba

Subfolders and files specific to Toshiba hardware. Unlike the files in the Drivers folder, these must be installed using a setup routine. They contain applications such as keyboard settings and DVD software.

Source

Each Windows installation source directory, as well as the Windows PE CD source files.

Source\WindowsPE2004

Windows PE 2004 CD source files.

Source\WindowsPE2005

Windows PE 2005 CD source files.

Source\XPPro\SP1

Slipstreamed Windows XP SP1 media.

Source\XPPro\SP2

Slipstreamed Windows XP SP2 media.

Source\XPPro.x64\RTM

Windows XP Professional x64 Edition media.

Templates

Template files used by Config.hta.

Installing the Windows Media You have now installed BDD, shared the folders as required, and placed the applications and drivers into the correct folder structure as outlined in Table 7-1. Next, you must populate the media folders with the appropriate version of Windows media. For Windows XP SP2, copy the entire contents of the Windows XP with SP2 CD or ISO into the Unattend\Source\XPPro\SP2 folder. Do not just copy the i386 folder! The Windows installation and Windows PE customization processes need additional files from the CD outside the i386 folder. Table 7-2 outlines the various Windows XP installation folders. You don’t have to populate folders for both versions of Windows XP—only the ones you intend to use.

175


176


Table 7-2. Windows XP Installation File Directories

Directory

Purpose

Unattend\Source\XPPro\SP2\

Windows XP Professional with SP2 slipstreamed

Unattend\Source\XPPro\SP2\CMPNENTS

Files from the Windows XP Tablet PC Edition 2005 CD 2; used when creating a Tablet image

Unattend\Source\XPPro\SP1\

Windows XP Professional with SP1 slipstreamed

Unattend\Source\XPPro\SP1\CMPNENTS

Files from the Windows XP Tablet PC Edition (with SP1) CD2; used when creating a Tablet image

Unattend\Source\XPPro.x64\RTM

Windows XP Professional x64 Edition

Unattend\Applications\MUIInst

MUI installation files and the language pack files that need to be installed

I also add a folder for Windows 2003 Server Standard Edition. I can use it to create an unattended build for imaging purposes for servers, and more importantly, to assist in the generation of Windows PE 2005. Finally, you have completed the installation and setup process for BDD 2.5. You can proceed to configure the unattended build environment.

■Note After you have set up BDD a few times, it will take you nowhere near as long as the first time. Its folder structure and contents seem to make more and more sense as you use it. From my perspective as a consultant, I can evaluate a company’s installation of BDD easily and quickly, as all these installations are typically very standardized.

Configuring the Build Process BDD provides a Computer Imaging System application, Config.hta, which makes it easy to configure your build environment and to generate Windows PE boot CDs.

Configuring the Computer Imaging System Follow these steps to run Config.hta and configure your unattended build environment: 1. Launch the BDD Explorer application from the BDD Enterprise Edition 2.5 group in the Start menu. 2. In BDD Explorer, choose Computer Imaging System ➤ Scripts ➤ Config.hta, as shown in Figure 7-1. 3. Click Open to open the Computer Imaging System Configuration tool. 4. Click the Configuration tab and fill in the fields with your information. Figure 7-2 shows an example of a Configuration tab filled in with sample information.



Figure 7-1. Opening the Config.hta application from BDD Explorer

Figure 7-2. Configuration tab in the Config.hta application

177


178


5. Click the Builds tab to configure the builds that will be available for unattended setup. This brings up an acknowledgment dialog box. Click OK to continue. 6. As shown in Figure 7-3, the Builds tab already lists some sample builds as templates. Feel free to use one of the existing ones or create a new one. Make sure your build name does not contain spaces if you create a new build. Complete the Builds tab for Windows XP Professional SP2 as follows: • Enter a description for the build you are creating. • Enter Source\XPPro\SP2 for the directory of the Windows XP SP2 source. • Enter your Windows product key in this format: AAAAA-BBBBB-CCCCC-DDDDD-EEEEE. Double-check this. If you enter it incorrectly, you will be prompted for the correct key during the build. • If you have any extra or special drivers, click the Edit Unattend.txt button and append your driver directory to the OemPnPDriversPath = line. Separate directories with a semicolon (;). • Click the Edit Sysprep.inf button. In the Sysprep.inf file, double-check that the BuildMassStorage Section has been enabled by removing the semicolon (;) from the front of that line.

Figure 7-3. Builds tab in the Config.hta application



7. Click the Customization tab to see the scripts that make up the build environment, along with a brief description of each script, as shown in Figure 7-4. Any customization that you may wish to make to the build environment will be in the files listed here. You may click any file’s underlined link to open that file in Notepad for inspection or editing.

Figure 7-4. Customization tab in the Config.hta application 8. Click the Actions tab to see additional installation procedures that have been preconfigured, as shown in Figure 7-5. These actions are unique to the Windows build currently being configured. If necessary, add or remove any actions for your own environment. These actions process in the order shown in the list. You may move them up or down within the list. I recommend enabling/disabling actions, rather than deleting them, as you may find a need for them later.

179


180


Figure 7-5. Actions tab in the Config.hta application 9. Click the Deployment tab. Provide the Sysprep and Lite-Touch deployment information for your build. Figure 7-6 shows the Deployment tab filled in with sample values. You can revisit any of the tabs of the Config.hta application to check and change any of your settings. All changes are automatically saved into the master General.xml, Builds.xml, and Builds.opt files, which are located within the Computer Imaging System\Control folder structure.



Figure 7-6. Deployment tab in the Config.hta application

Creating Windows PE Boot CDs This leaves one other step to perform before you can actually use the Windows unattended build process. You must generate the Windows PX-based build CDs. This is a lot easier than it sounds, thanks to the handy Config.hta application. The Lab CD is used to start the unattended build process and initiate the SMS OSD image capture process. This Deploy CD is used in Lite-Touch deployment scenarios. Follow these steps to build your CDs: 1. Click the Windows PE X86 tab in the Config.hta application. Here, you create the necessary Windows PE ISO images for use in your deployment. 2. To create a Windows PE 2005 ISO image, make sure that the following information is correctly specified: • WinPE path: ...\Computer Imaging System\Source\WindowsPE2004 • Extra NIC path: ...\Computer Imaging System\Boot Disks\WINPE\Extranics • Windows 2003 SP1 source files path: ...\Computer Imaging System\Source\Windows2003\SP1 (this is Windows 2003 Server with SP1 slipstreamed into it) • Temporary directory: Any empty writable directory that can be used, such as %temp% • Lab ISO file destination: C:\WinPElab.iso • Deploy ISO file destination: C:\WinPEdeploy.iso • Generic ISO file destination: C:\winpe.iso

181


182


3. Click Make Lab CD to create the Windows PE CD image (winpelab.iso) for lab use. 4. Wait until the process is finished. (Be patient, as it will take several minutes.)

■Note

If you need to troubleshoot any issues, review the log file at C:\Documents and Settings\ Administrator\Local Settings\Temp\BuildCD.log. Commonly, a warning message is issued if an existing driver has been overwritten with another copy or version—nothing to worry about.

5. You may create the Deploy ISO (winpedeploy.iso) file by clicking the Make Deploy CD button. This completes the customization of the Computer Imaging System. Since the example here is for testing BDD in the lab, we’ll be using only the Lab CD. See the BDD documentation for details on using the Deploy CD. Burn the Lab CD ISO to a CD, and you are ready to start building your unattended Windows installation.

Capturing the Build Process Now that you have configured your imaging system, you can start leveraging your ability to provide a consistent and repeatable build process for your OS reference image. Imaging processes can easily save you time on five or fewer repeated builds. To begin, insert the Windows PE Lab CD into the reference computer. Restart the computer and ensure that it boots from the CD media. It commonly takes several minutes for a physical CD to boot the Windows PE lab environment. After a Windows XP–style system startup process, a command window will open on the screen. Once the system has completed initializing, it will attempt to connect to the build server (ImageServer) with the credentials provided during the build server installation process. If there are missing network drivers or other network connectivity issues, it will fail to provide this connection as a mapped m: drive. Once the computer has booted and connected to the server, the Computer Image Build Wizard will start. Follow these steps to complete the build of your Windows XP reference image and then capture it: 1. In the Computer Image Build Wizard’s first screen, choose the SMS 2003 Image Capture Wizard option, and then click the Begin Build button.

■Note If you are building this image strictly for testing, you may opt for the Build Completely Now option. It will complete the entire unattended build process so that you may test the OS and applications to ensure they were built to your satisfaction. The Sysprep a Machine option will complete the unattended build process, perform the Sysprep, and then shut down the machine in preparation for imaging. See the Computer Imaging System Feature Team Guide for more details about the Computer Image Build Wizard’s three options. 2. Click the Begin Build button. This will begin the unattended installation process. The system erases the existing hard disk and formats it for NTFS. Both of these processes use the Diskpart utility. The system files are then copied to the local disk in preparation for Windows installation. If you are building the image on a virtual machine, the build time may take at least an hour. It should take about 35 to 45 minutes on physical hardware.



3. Once the build has completed, it will prompt you to insert the SMS 2003 Operating System Image Capture CD to capture the image as a WIM file. Insert this CD (creating this CD is described in the “Creating an OS Image Capture CD” section earlier in this chapter). That’s it. The capture process will now proceed. This completes our coverage of the SMS 2003 OSD Feature Pack and BDD.

SMS Device Management Feature Pack The SMS Device Management Feature Pack allows you to manage most of the popular PocketPC and Windows CE platforms, including PocketPC and Phone Edition 2002/2003, Windows Mobile 5.0 (support coming in 2007), Windows CE 5.0 Platform Builder (built-in client), and Windows CE 3.0 and above (with OS dependencies). As with the other Feature Packs, it is a free download, with no other licensing requirements than having SMS 2003 in your organization. So what can the Feature Pack do for you and your fleet of PocketPC and Windows CE devices? Well, honestly, the answer is that it can do a lot. The Device Management Feature Pack allows mobile devices to connect directly to an SMS infrastructure; they do not need to connect through a host PC. Once the Feature Pack is installed and configured with mobile clients, you can use it for the following functions: Hardware/software inventory: As with all systems in SMS, discovery data is initially returned about a new potential client. In the case of mobile systems, the discovery data includes a hardware ID that is used to identify the system within the SMS 2003 database, the device name, and the OS name. More hardware inventory details are returned once the SMS client has been installed and is running on the mobile device. Typical results for the hardware include video subsystem, OS details, and CPU information. Software inventory data is also returned, including the files and applications located on the device. File collection: As with typical SMS clients, you can leverage file collection to return specific files to the SMS infrastructure for later analysis or use. Software distribution: Again, as with normal SMS clients, you can target software distribution to clients based on discovery or inventory data. The standard download and execute methodology for transferring package contents to the clients is used, allowing for checkpoint restarts of package downloads. You can specify network characteristics based on how the device is connected, such as the package downloading content when connected via high speed. The basic options for advertisements also apply to mobile clients, such as being able to specify mandatory and reoccurring schedules. Settings management: The settings management options let you make key changes to your devices without needing to touch them physically. By using these options, you can manipulate common PocketPC settings, such as network connections (PPP, VPN, and such), applications (Exchange Server, e-mail, Internet Explorer proxy, and so on), and security (the installation of certificates). Password policy management: You can implement password policies for your clients to enforce security requirements, such as strong passwords, power-off timeout values, and password lockout parameters.

183


184


SMS Administration Feature Pack One of the other useful Feature Packs available for SMS 2003 is the SMS Administration Feature Pack. This Feature Pack contains three tools that are geared to performing SMS 2003 administrative tasks: Manage Site Accounts Tool (MSAC.exe), Elevated-Rights Deployment Tool (Run_once.exe), and Transfer Site Settings Wizard. These are some handy tools. Granted, they are not tools that you will use daily, but they are useful when you need them and would otherwise have to resort to some manual process to accomplish the same task. Let’s take a quick look at each of these tools.

■Note

The actual syntax of each of the SMS Administration Feature Pack tools is well documented within each tool’s help file.

Manage Site Accounts Tool The Manage Site Accounts tool allows you to use the command-line interface to perform a number of actions against the accounts in use by your SMS sites. For example, you can create, update, verify, and delete accounts. Specifically, you are able to manage the following account types for SMS 2003: • SMS service account • Client connection • Intersite communications accounts • SQL Server account • Client Push Installation accounts • SMS client remote installation accounts • Site system connection account • NT client software installation account • Advanced Client network access account • Server Locator Point (SLP) SQL Server account • Management Point (MP) SQL Server account

Elevated-Rights Deployment Tool As your software distributions become more sophisticated, you may encounter certain situations where an installation may require a restart part of the way through the process. Following that restart, additional installation tasks may be required, and they typically will require elevated user rights, such as local administrator privileges. This may not be a problem if your users already have those rights, but I would suspect you are looking for ways to remove local administrator privileges from your users. The Elevated-Rights Deployment Tool (Run_once.exe) allows you to handle scenarios where the user account that may log on to a system to allow the execution of a Run_once command in the Registry does not have the administrator privileges to perform the execution. Once the initial installation is performed, the secondary portion is set to execute using Run_once.exe. Upon the restart of the system and logon of a user, the remaining part of the installation process will start, executing using a local administrator context.



Transfer Site Settings Wizard The Transfer Site Settings Wizard allows you to streamline the process of creating multiple SMS sites. It achieves this by allowing you to make a copy of the configuration of an existing site and deploy those configurations to other sites. It is able to apply these configuration changes to multiple sites simultaneously. You may also transfer collection and package settings between sites. As you can imagine, performing this task manually takes large amounts of time and labor. This tool works through either the command line or a GUI. If you encounter issues while using this tool, you may review its log files, which are located in the C:\SMS folder. The SSRT_Log.log file will contain the progress and errors that occurred during your use of the tool.

Summary The majority of this chapter discussed using the SMS OSD Feature Pack to capture and deploy images. We drilled through technical aspects of the OSD Feature Pack, including how the imaging tool operates and differs from other conventional imaging tools. You saw that the installation process for the OSD Feature Pack is fairly straightforward, but its operation and the use of its features can be complex. Next, we moved on to using the Solution Accelerator for BDD, limiting our discussion to Lite-Touch Deployment scenarios to get you started. When working with this type of technology, it pays to prepare yourself well with a lab environment, and I described such a setup. Then we walked through the process of creating the base image and capturing it, for use with SMS 2003 and the OSD Feature Pack. Using this technology, combined with Windows PE, you are able to leverage some key tools from Microsoft at little cost to perform advanced OS imaging functions. Then we took a quick look at two other useful Feature Packs. The SMS Device Management Feature Pack lets you manage, inventory, and control mobile devices. This Feature Pack is often underutilized, but I predict that it will become more popular as more and more Windows mobile devices enter our corporate culture. The SMS Administration Feature Pack provides useful tools for administrators. These tools allow you to manage site accounts, elevate rights for software deployment, and streamline the process of creating multiple SMS sites.

185



CHAPTER 8 ■■■

The SMS Community

B

esides the fact that it’s an extremely capable system, another reason why I think SMS 2003 is one of the best systems management products available is the SMS community. In this chapter, we will explore what the community has to offer. First, we will look at the third-party add-in products for SMS 2003. Various companies and individuals have developed numerous products that enhance and expand the functionality of SMS. The great part about all this is that many of the enhancements are free. Others are available at a reasonable cost. Not every add-in is going to be applicable to your scenario or required in your environment, but knowing what is available will give you an idea of what can be accomplished with such products. The second part of this chapter is about the wealth of web-based resources available for SMS 2003. These include articles, forums, e-mail lists, blogcasts, and more.

SMS Tools and Add-ins The tools and add-ins available for SMS 2003 are extremely remarkable. As I’ve mentioned, many of these are free, and that’s where we’ll start.

Free Stuff Many people have put a lot of hours into developing their own tools to solve problems, and then they took one more step: they shared the results with the community. In this section, I’ll review some of my favorite free tools for SMS 2003.

Console Tools The SMS Administrator console is great. It doesn’t offer drag-and-drop functionality, but that’s good, because it would be too easy to make mistakes. However, some additional features would be useful in a few key areas. Cory Becht stepped up to the plate and developed an add-in for the SMS Administrator console. This tool lets the SMS administrator perform a number of handy actions with a simple right-click: • Reassign a site code • Restart the SMS Agent Host service • Regenerate the SMS client GUID • Rerun advertisements without modifying them • Regenerate client-side discovery data requests • Gather software inventory 187


188

CHAPTER 8 ■ THE SMS COMMUNITY

• Gather hardware inventory • Perform file collection • Determine software metering usage • Refresh machine policies • Evaluate policies • Update Windows Installer sources • Change port numbers • Change cache sizes Most of these actions are applicable to a single machine or an entire collection of machines. To download this great tool, visit http://www.myitforum.com/articles/11/view.asp?id=7099. There, you’ll find an article documenting this tool and a download link to obtain a copy of it.

Security Logon Audit Tool The Security Logon Audit Tool (SLAT) extends SMS hardware inventory to include user logon information. This data can be used in web reports and queries. The tool includes the following sample reports: • Top users for all systems • User logon information for a specific computer • Systems where the last logged-on user is not the top user • Systems where a specific user has logged on SLAT searches the security event log for the 528 event, which is created when user logon events occur and is enabled via Group Policy. When a logon event is found, a new Windows Management Interface (WMI) class called User Logon Info is created on the SMS client. An instance is created for every user who has logon events identified in the security event log. The count of each user logon is added to this instance data, as well as the rank of the user. The User Logon Info.exe should be run periodically as an advertisement on all Windows NT 4.0 and above systems with SMS clients (once a day to once a week). When it has finished running, you can provide a /kick parameter to force a hardware inventory. The SMS_def.mof file needs to be updated to collect the new WMI class. A sample userlogoninfo.mof is included and can be cut-and-pasted into your existing SMS_def.mof. (See Chapter 9 for more information about editing the SMS_def.mof file.) You can download the SLAT tool from http://www.systemcentertools.com. Steve Bobosky has graciously donated this tool to the community for public use.

Enhanced System and User Discovery Tools Out of the box, SMS 2003 does a pretty good job of discovering systems from Active Directory. It’s not perfect, though—there are a few gaps in its methods. The Enhanced System Discovery tool, available from http://www.systemcentertools.com, assists in filling these gaps. Out of the box, SMS 2003 does not perform Windows NT 4 domain discovery. This tool solves that by enumerating all machines from a list of NT 4 domains, resolving their IP addresses from DNS or WINS, and creating data discovery records for each system.



SMS 2003 does have an Active Directory discovery method, but it is limited in the attributes that it can discover about systems. The Enhanced System Discovery tool is able to discover customized attributes about systems that it finds in Active Directory, such as if the computer account is disabled. You can also specify the maximum age of the computer account, discover systems that respond to a ping test, and discover only local systems—allowing for a distributed discovery process. The Enhanced User Discovery tool, also available from http://www.systemcentertools.com, is similar to the Enhanced System Discovery tool, but discovers user accounts from Active Directory. SMS 2003 already performs this action, but on a limited basis. This enhanced version is able to discover rich user information, such as address, phone number, and e-mail address. This is not designed to be a direct replacement for SMS 2003’s user discovery method, but more to augment its inventory.

SMSView SMSView, available from http://www.smsview.com, extends the functionality of the SMS Advanced Client. By using this tool, you can allow nonadministrative users to perform a number of activities, including the following: • View current mandatory assignments • View advertisement status • Rerun advertisements • Remotely view and manage SMS clients • Display hardware and software inventory status Typically, this tool would be best used by the SMS administrator to allow help desks or regular users to perform key SMS functions.

BITS Bandwidth Manager One tool that has recently come to my attention is the BITS Bandwidth Manager. If you recall, BITS is the throttling mechanism that SMS uses to schedule data transmission on the local network interface. It has its limitations when slow or high-latency WAN links are encountered, as they are not “seen” by the BITS throttling mechanism from within the Windows client system. This means that you may misuse the bandwidth and potentially encounter network connectivity issues. One simple work-around is to manually schedule and throttle the traffic that BITS is processing at the client, usually by manipulating Registry keys or applying Group Policy Objects. The BITS Bandwidth Manager is an SMS Installer script that lets you throttle BITS bandwidth on Windows XP SP2 systems. You do not need to manually adjust any settings. The script takes care of the Registry key manipulation for you. Thanks to David Alvarez for putting this valuable tool together and sharing it with all of us. You can download the tool from myITforum at http://www.myitforum.com/inc/upload/ 11332BITSManager.zip.

Commercial Products Even with all of the free tools and enhancements available for SMS 2003, you still may need some additional tools to perform specific functions. A few companies provide various functionalities for SMS 2003, ranging from Wake On LAN (WOL) technology to allowing SMS to manage non-Windows systems.

189


190


1E Solutions 1E (http://www.1e.com) has been in the systems management business for a while now, and as such, the company has several very good offerings for SMS 2003. The following are the ones that I’ve used personally or that sound particularly interesting to me: SMSWakeUp: Part of the SMS Patch Management Pack, this WOL product is able to turn on computers after they have been shut down by users. The wake cycle can be triggered on a regular schedule to power up systems in preparation for the workday, or to perform software deployment activities. SMSWakeUp integrates directly with SMS 2003 to wake only systems that have a software distribution scheduled.

■Note

There are a few caveats associated with SMSWakeUp. The systems must support WOL and be configured for such activities. Moreover, most routers are configured to block the WOL packets. This can be mitigated by installing software on systems on each subnet to act as relays to each other; of course, one machine must be left on at each subnet to allow this configuration to work.

NightWatchman: Since we are talking about waking systems that have been shut down, it may be a good practice to examine how best to shut down those systems in the first place. Why do we want to shut down systems? We do this to enforce reboot cycles and to save energy costs. 1E offers a great worksheet to assist in calculating energy savings from their NightWatchman product. NightWatchman, also part of the SMS Patch Management Pack, allows you to schedule and perform a controlled shutdown of remote systems while allowing applications to save their data. NightWatchman can be configured to handle custom applications, and comes preconfigured to handle most common applications. It can shut down systems while saving versions of documents that were open at shutdown time. If NightWatchman does not know how to shut down a particular application, the system will be locked rather than powered off. SMSNomad Branch: Some offices may not have the server hardware to allow for a Distribution Point (DP). But those offices may have a substantial number of users and/or be separated from the rest of the network by a low-speed or saturated WAN link, which you would rather not send multiple copies of a package across. This is where SMSNomad Branch comes in. It acts similar to a peer-to-peer network, allowing other computers to become DPs. If one machine is shut down, another is selected as the DP. Included in this technology is multicast, increasing its efficiency to reduce network traffic on the local network segment. OSD Plus Pack: This is an enhancement to the SMS OSD Feature Pack (covered in Chapter 7). It allows you to leverage the SMS OSD Feature Pack in offices that do not have DPs. OSD Plus Pack offers similar functionality to SMSNomad Branch, but also has a few other applications bundled with it: • State Migration Editor, which is an interface for the User State Migration Tool • AppMigrator, which allows the automatic reinstallation of applications after OS imaging • PXE Lite, which is a local PXE server to allow deployment of OS images to bare-metal machines booted from the network PXE server

SMS Companion 2006 The SMS Companion 2006 package is offered by SMS Expert (http://www.smsexpert.com). This product provides WOL capabilities, similar to 1E’s SMSWakeUp, but leverages slightly different technologies behind the scenes. A key difference is that SMS Companion puts systems in hibernation,



rather than powering them off. The following are some of the key applications included with this product: Wake-on-Schedule: Allows clients to come out of a hibernation state. Service Windows: Allows you to restrict the SMS inventory and software distributions from happening during specific time periods, to reduce or eliminate user interruptions. Load Balancing: Allows you to reduce peak network and SMS server loading by making sure that the clients use these resources in a controlled manner.

Quest Management Xtensions for SMS Recently purchased by Quest Software, Vintela was one of the only vendors allowing SMS to manage non-Windows platforms. Since being purchased by Quest Software, development has continued, and Vintela Management Extensions are now called Quest Management Xtensions (http://www. quest.com/quest_management_xtensions_for_sms/). Since Windows platforms are not the only systems in an enterprise, you may need a way to manage other platforms, such as Unix, Linux, and Mac OS X. These management extensions offer that capability for SMS 2003. One of the unique aspects of this product is its support route: first-level support is handled by Microsoft Product Support Services.

Web-Based Resources Web-based resources offer invaluable material for SMS 2003. Here, we will explore several must-see sites for key areas for you to explore.

myITforum.com One of the first stops you should make is myITforum.com (http://www.myitforum.com). It is the primary community-support resource you will need. A fellow by the name of Rod Trent, author of other great SMS-related books, such as Microsoft SMS Installer, hosts and moderates this site. Recently, myITforum incorporated to allow for further expansion and custom offerings for its user community. It is a free resource for you to use. Glancing at its homepage, what is obvious to the new visitor is a list of recent articles, but there’s a lot more to this site. Be sure to subscribe to its daily newsletter, which publishes new articles each day, a recent summary of new downloads available, and a sample of current discussions from the site’s web forums. Most of the site content is complementary to SMS subjects. Many SMS administrators are charged with other duties, and some of those areas are discussed at this site. First, on the homepage, you see a list of various articles. You can click the title for each article category on the homepage to view more articles in that specific category. Of course, it has a search facility and author filter that allow you to refine your searches for specific topics and content. The next area of interest is the Downloads section. Here, you will find various scripts, executables, bits of documentation, and other goodies available for free download. Some of the tools I mentioned earlier in this chapter are available here. One area that has undergone recent changes is the web forums. These web-based discussion lists are public forums for discussing issues and ideas with other members of the community. A recent addition to this section is its availability via RSS feed. This lets those of us who don’t have the time or ability to check back on a web-based forum keep tabs of discussions. In fact, various areas of the myITforum site are now available via RSS feed.

191


192


■Note

RSS stands for Really Simple Syndication. It is a web-feed format leveraging XML that allows information such as news, blogs, and podcasts to be quickly and easily distributed to clients on a pull basis. The RSS-based updates and information are viewed using an aggregator. There are many aggregators available, including Outlook 2007, NewsGator, and Feedreader.

My preferred medium for discussion is the e-mail discussion lists. Browse there directly by visiting http://www.myitforum.com/Lists.asp. The discussion lists have recently been expanded to include a wide range of topics, again mostly related to the tasks of an SMS administrator. Table 8-1 lists the current discussion lists.

Table 8-1. myITforum E-Mail Discussion Lists

List

Name

Posting Address

Active Directory and Group Policy

adgpo

[email protected]

Microsoft SharePoint List

sharepoint

[email protected]

AntiVirus

antivirus

[email protected]

Microsoft Operations Manager

msmom

[email protected]

Microsoft Systems Management Server

mssms

[email protected]

The myITforum Off-Topic

myotforum

[email protected]

Windows PowerShell

powershell

[email protected]

Scripting

scripting

[email protected]

Windows Mobile

windowsmobile

[email protected]

To gain access to any discussion list, you just need to subscribe it. Subscribing is quite easy. Just send a new e-mail message to [email protected]. In the body of the message, type Subscribe, followed by the name of the list (see Table 8-1). For example, to subscribe to the SMS list, enter Subscribe: mssms into the body of the e-mail message. Be sure to leave the subject line blank. You may manage all of your subscriptions this way, by sending commands to the list server. Some other e-mail body commands that you can use are listed in Table 8-2.

Table 8-2. Some myITforum E-Mail Discussion List Commands

Command

Description

Help

Replies to the e-mail with basic instructions on using LISTSERV commands

Help "listname"

Replies to the e-mail with the contents of the help e-mail for that list

List

Replies to the e-mail with a list of all available lists



Table 8-2. Some myITforum E-Mail Discussion List Commands

Command

Description

Subscribe "listname"

Adds your e-mail address to the subscribers list of the mailing list

Unsubscribe "listname"

Removes your e-mail address from the subscribers list for the mailing list

Set mode digest "listname"

Sets your e-mail address to receive e-mail in digest mode, which will send all messages for the list combined into one e-mail message at regular intervals

Set mode standard "listname"

Sets your e-mail address to receive e-mail in standard mode (the default), which will send messages one at a time to your e-mail account

One of the other areas of interest is the Blogs section. You may browse there directly by visiting http://myitforum.com/cs2/default.aspx. Various community members post blog entries to the myITforum blogs. You may want to review many of these for content that interests you before pulling their content via RSS.

■Tip

You may view my blog at http://myitforum.com/cs2/blogs/rkruetzfeld/default.aspx, where I will be posting an index of URLs from this book. My aim is to save you from having to type those URLs.

The myITforum community is the place to discuss and share information on SMS 2003 and other systems management products. Don’t be afraid to post questions and comments in the forums and e-mail discussion lists, as the community is very welcoming and helpful.

Blogcast Repository Another great resource is the Blogcast Repository (http://blogcastrepository.com). A blogcast is simply a recorded video and audio session that demonstrates, teaches, or informs on a specific subject. This site is full of useful blogcasts on many subjects including SMS. At the time of this writing, there were 28 blogcasts in the SMS section alone (http://blogcastrepository.com/blogcasts/ 37/sms/default.aspx). You will need to register in order to view the blogcasts. Registration is free, and is free of spam. Once registered, you can browse the blogcast catalog and view any blogcasts that you desire. It’s a great learning resource, and a great resource to share what you have learned.

AppDeploy.com AppDeploy.com (http://www.appdeploy.com) is the Internet resource to go to when you need to script or repackage an application for distribution. Among other points of interest at the site is a massive library of applications, sorted by application name and vendor name. For each application listed, you’ll find a community-based thread discussing the best practices, links, scripts, and challenges met/overcome with working with the application in regard to installation scripting/repackaging.

193


194


Browse to the site, and drill into the Packages section on the left side of the homepage. You will be shown a list of recent additions and recent updates. Chances are that if you are tasked with preparing an application for deployment, someone has already done so and documented his process here. And if the application is not listed or documented here, that gives you the opportunity to be the first, and to give back to the community.

DesktopEngineer.com Darwin Sanoy’s site, DesktopEngineer.com (http://www.desktopengineer.com) is perhaps one of the best resources in the Windows Installer arena. This site offers a wealth of information on Windows Installer technology, techniques, and troubleshooting tips. I have noticed that he is starting to increase the content related to Microsoft’s upcoming PowerShell scripting language. If you have the opportunity, check out the training sessions offered on software repackaging and Windows Installer. I have heard that they are superb. DesktopEngineer.com is also RSS-enabled, with content published on a semi-regular basis.

Microsoft Of course, we need to talk about what is available from Microsoft. We have explored most of the major offerings from Microsoft in the previous chapters, but there are other goodies to be found on the Microsoft site. Browse through http://www.microsoft.com/sms to review the various areas related to SMS. One of the key offerings from Microsoft is webcasts. These are presentations from the SMS 2003 development team members and program managers detailing specific areas of technology and technical drill-downs through their products. Obviously, the Download section has a wide variety of downloadable Feature Packs, Service Packs, tools, and software development kits for SMS. One other directly related resource from Microsoft is the Microsoft TechNet website. The Systems Management Server Community page (http://www.microsoft.com/smserver/community/ default.mspx) offers a list of SMS blogs by Microsoft staff and an overview of the Microsoft SMS MVPs. Not only will you find links to documentation and information here, but also to SMS Knowledge Base articles and other sites of interest.

■Note

MVP stands for Most Valuable Professional. This is another way of recognizing individuals who have made outstanding contributions to their areas of expertise. These folks are all nominated by people like you.

If you have specific scripting tasks, you may want to check out the Scripting Guys at http:// www.microsoft.com/technet/community/columns/scripts/sgarch.mspx. Their column offers assistance in a wide variety of scripting topics that can be adapted to your needs. Another site you may find helpful is Microsoft’s Desktop Deployment page (http://www. microsoft.com/technet/desktopdeployment/default.mspx). Here, you will find information about Business Desktop Deployment (BDD) and how it interoperates with SMS 2003.



Summary So, now that you’ve read about the great SMS community and what it has to offer you, you may be wondering what you can do to help. Well, you can become an active part of the community. That part may be just subscribing to the discussion lists. You may start out by just asking questions. Next thing you know, you will be answering questions posed by others who are just getting started. You may not have developed any unique solutions, but you can provide feedback to those who have. You can comment on the commercial tools, as well as the public and community tools. That is how they will get better and stronger. Join a user group. If you can’t find a local one, start one. Make it a special interest group of another IT professional users group. Don’t worry—you can get a lot of help starting one in your area. Check http://www.myitforum.com/groups for a list of known SMS user groups.

195



CHAPTER 9 ■■■

Moving SMS into Operations

I

n this chapter, we will look at moving SMS 2003 forward into operations. We will cover the following topics: • SMS integration with Microsoft Operations Manager (MOM) • Backup and disaster recovery • SMS status message filters • SMS inventory extension • Software repackaging products

MOM Integration Since MOM 2005 is a Microsoft product, it makes sense that it can operate with SMS at some level. SMS is able to perform two key operations in conjunction with MOM 2005: • Place a system in maintenance mode. • Generate a MOM alert if a package distribution fails.

Maintenance Mode SMS is able to communicate with the MOM 2005 agent to place a system in a special mode, called maintenance mode. This mode instructs MOM to ignore any alerts that are raised by that system due to CPU load, reboot cycles, stopped services, or any other issues. You may wish to allow SMS to place a system in maintenance mode while you are conducting patching or other software distribution activities. In those cases, you want to suppress the alerts because the activities that trigger them are taking place in a controlled manner and are expected. In order to enable SMS 2003 to place systems in maintenance mode, you must select two options: • In SMS, set the Maximum Allowed Run Time option on the Requirements tab of the Program Properties dialog box (accessible from the Programs node of the SMS Administrator console). Upon the start of execution of the program on the client system, the SMS 2003 client will communicate with the MOM 2005 agent and ask it to place itself into maintenance mode for the duration of time specified for the Maximum Allowed Run Time option. If you don’t set this option or enter a value of over 12 hours, a value of 15 minutes will be used by default. • In MOM 2005, select the Disable MOM Alerts While This Program Runs check box. This option is on the MOM tab of the Program Properties dialog box.

197


198

CHAPTER 9 ■ MOVING SMS INTO OPERATIONS

MOM Alert on Program Failure MOM 2005 can generate an alert if a package distribution fails. To enable this feature, in MOM 2005, select the Generate MOM Alert If This Program fails check box on the MOM tab of the Program Properties dialog box. Once enabled, this option will monitor the status of the distribution and execution of the package and program for the client, and generate an event log entry if there is any type of failure. The log entry includes the package name, program name, advertisement ID, and failure codes. This event log entry will be picked up by the MOM 2005 system and processed according to MOM 2005’s rules to provide an alert to the appropriate operator.

System Center Product Integration Microsoft has announced a rebranding of the SMS and MOM product lines into the System Center product line. SMS 2003 will be replaced by System Center Configuration Manager 2007 (SCCM 2007), and MOM 2005 will be replaced by System Center Operations Manager 2007 (SCOM 2007). The rebranding of these products would indicate a tighter integration of functionality between them, which can already be seen in the System Center Report Manager 2006 (SCRM 2006). SCRM 2006 allows you to amalgamate multiple data stores (SMS 2003 and MOM 2005) into one centralized data warehouse. This centralized repository makes it easy to generate a variety of change management and configuration reporting options. You may think of this as a data warehouse for IT operations. For example, you could produce reports to get the following information: • Locate servers that are underutilized and provide configuration statistics to evaluate the feasibility of consolidating them. • Determine if hardware or software changes may be responsible for instabilities on a platform for higher alert volumes. For more information about SCRM 2006, visit http://www.microsoft.com/systemcenter/scrm/ default.mspx.

Backup and Disaster Recovery These days, we naturally assume that if we build something in our IT environment, someone will back it up for us. You may already have infrastructure-commissioning processes in place that handle backup and discovery recovery preparation. However, if you are part of the mid-sized or small business crowd, you may need to set up your own backup and disaster recovery preparation processes.

SMS Backup Operations SMS 2003 can automatically perform a backup of its database, but unfortunately, this task is not enabled by default. To enable it, in the SMS Administrator console, drill down through the Site Settings and Site Maintenance nodes to the Tasks mode, and then set the Backup SMS Site Server task to True. Then configure the task with an appropriate schedule. The task provides a flat file that is suitable for use with typical file archival operations such as standard file backup processes. Therefore, you should try to schedule the task to occur prior to the file backup process that may be already configured for your SMS site server. Along with this flat file backup of the SMS database, the backup task also processes two other files: SMSbkup.ctl and AfterBackup.bat. The SMSbkup.ctl file contains instructions on how to process the backup task. It includes a list of files, Registry keys, and databases that should be backed up as part of the task.



The AfterBackup.bat file allows you to chain scripted tasks to the end of the backup process. Typically, you could use this batch file to perform snapshots of your SMS backup file, such as copying it off to another location, but you may also use it to script other actions, such as health checks on your site. The AfterBackup.bat file does not exist by default, so you must create it manually, as follows: 1. Create a new text file in a text editor (such as Notepad). 2. Add any commands that you wish to perform, such as copying the SMS backup files to another network location (such as a SAN-based share). You may also want to add some form of logging. Then you can refer to the logs produced by this script to verify that the backup executed correctly and to help troubleshoot any problems. 3. Save the file as AfterBackup.bat in the SMS\inboxes\smsbkup.box folder. After the next SMS 2003 backup task executes, the AfterBackup.bat file will be processed and the commands contained within it will be executed.

Disaster Recovery Preparation Several disaster recovery tools are included with SMS 2003. But first things first. A key part of disaster recovery preparation is documentation. Document the build of your SMS 2003 hierarchy, site configurations, advertisements, packages, and reports. Any changes you make to your site should be supported by some form of documentation that another SMS administrator could follow to rebuild your site hierarchy from the ground up. Typically, you’ll create this documentation when you first build a site, but it is important to maintain some documents to reflect updates and changes. There is nothing worse than trying to follow an outdated piece of documentation. That being said, let’s get on with the tools that you can use.

Recovery Expert The Recovery Expert is a recovery tool that will guide you through the recovery process for a site. The tool is essentially a web-based interview process. It asks you questions to gain an understanding of the site failure and what collateral means you have to use in the recovery process. The following are the typical tasks for which the Recovery Expert can offer guidance: • Rebuilding failed site servers • Restoring site data for site servers • Resynchronizing data between site servers • Validating the success of the recovery process This is a useful tool, but it does need a little setup to get going. The setup process requires that you use a website to host the Recovery Expert. This is fairly easy, as you may host Internet Information Services (IIS) on your own desktop system or another working SMS site server.

SMS Site Repair Wizard The SMS Site Repair Wizard automates a variety of tasks associated with the recovery of your sites. The Recovery Expert will recommend whether or not to use the SMS Site Repair Wizard to perform the specific actions. You should always rely on its advice, and not use the SMS Site Repair Wizard independently from the Recovery Expert. During the recovery process, you may be asked to supply a reference site. A reference site is a site that exists at a lower level from the site on which you are performing the repair. Typically, when configuration changes are performed, those changes are replicated downstream to lower sites.

199


200


The lower-level site would then contain the configuration changes that may be missing from a backup of the higher-level site. The SMS Site Repair Wizard is able to read these configuration differences from this reference site and apply the appropriate changes to the site being recovered. A reference site must be a primary site in order to contain the configuration items needed for recovery. In some architectures, you may have important primary sites that have only secondary child sites below them. Since these are secondary sites, they may not be used as reference sites. You may choose to include an additional primary site below your key primary site to act as a reference site. You would not want to use that site for management; use it only for disaster recovery as a reference site.

ACL Reset Tool The ACL Reset tool will perform an access control list (ACL) reset on the file and Registry structure of an SMS site. In addition to being able to reset the ACL’s objects, this tool will also re-create missing folder and key structures that it encounters. Use the ACL Reset tool with care. Using it for purposes other than disaster recovery may cause unintended results.

Hierarchy Maintenance Tool The Hierarchy Maintenance tool will allow you to perform several troubleshooting tasks against local or remote sites, including the following: • Diagnose issues within a site • Repair sites • Dump site control images • Distribute public keys • Stop all SMS services The SMS Recovery Expert will give you instructions for using this tool. As with the ACL Reset tool, you should exercise caution in using the Hierarchy Maintenance tool for tasks not related to recovery.

SMS Status Messages As you’ve learned in earlier chapters, SMS 2003 allows you to view the status of a variety of processes and services in the form of status messages. These status messages indicate what processing steps were taken, whether the completion of these steps failed or succeeded, and what information these processes and services returned. You view these status messages in SMS 2003’s built-in viewer, the SMS Status Message Viewer. You can modify the handling of SMS status messages in two ways: adjust the thresholds that trigger statuses and set filter rules.

Status Message Thresholds You refer to the status messages for an indication of the health of various services and processes. On occasion, you will see that the status of some of these have changed from the usual green to amber (warning) or red (error) conditions. Upon drilling into the status messages, you may find expected issues, such as client installation retries, have toggled the status. To avoid such “false” alerts, and make it easier to track down real issues, you can adjust the thresholds of when a specific condition will trigger a change in status.



You can set these thresholds in the SMS Administrator console, through the Status Summarizers node beneath the Site Settings node, as shown in Figure 9-1.

Figure 9-1. SMS Status Message Summarizers node In the right pane, double-click an individual status summarizer to open its Properties dialog box. Figure 9-2 shows the Component Status Summarizer Properties dialog box.

Figure 9-2. The Thresholds tab of the Component Status Message Summarizer Properties dialog box

201


202


In the Thresholds tab of the Status Message Summarizer Properties dialog box, select the type of status messages you want to adjust from the Message Type drop-down list. Then select the item that you wish to alter by double-clicking it in the list box. You’ll see a dialog box that allows you to customize the number of messages that will result in the trigger of the threshold, as shown in Figure 9-3.

Figure 9-3. SMS Status Message Summarizer threshold values

Status Message Filtering Since SMS is tracking the health of its systems, sites, and components (to some degree), why not use that to your advantage? You may do this by adding scripted mechanisms to the SMS status filter rules. To access these rules, in the SMS Administrator console, drill down through the Site Settings node to the SMS Filter Rules node, as shown in Figure 9-4. Aside from just enabling and disabling these rules, you may double-click each one to customize the actions that are performed when the rule is triggered. The properties of a typical rule are shown in Figure 9-5. You can choose not to forward the status message to the current site’s parent site when the filter rule is triggered. This, combined with the option of not processing lower-priority status filter rules, may assist in reducing intra-site traffic. Using the Run a Program option, you may execute scripts that take specific actions, such as restarting services or sending an SMTP-based e-mail message (using a freeware tool such as Blat) to an SMS administrator recipient.

■Tip

You can get Blat from http://www.blat.net. It’s a free download and comes with a ton of options. See its documentation for a complete explanation of how this SMTP e-mail tool works and how to configure the command line.



Figure 9-4. SMS Status Filter Rules node

Figure 9-5. SMS Status Filter Rule properties

SMS Inventory Extensions You have SMS 2003 running great in your environment, so what else can you do with it? You will likely always be finding new uses for its inventory capabilities. Here, we will review popular methods of extending SMS’s inventory operations: MIF files and MOF extensions.

203


204


SMS MIF Files The Desktop Management Task Force (DMTF), which defines standards for the management of desktop systems, developed the Management Information Format (MIF) standard. SMS 2003 uses this standard for its inventory and status reporting mechanisms. There are essentially two types of MIF files: NOIDMIF and IDMIF. The difference is defined within the MIF file, which is just a text file with some structured fields in it.

SMS NOIDMIF Files The standard MIF file type that SMS uses is NOIDMIF. It’s called NOIDMIF because a unique identifier is not set within the MIF file. SMS automatically assigns this ID with the computer from which the NOIDMIF file was collected. This type of MIF is generally used to collect information from a computer, about the computer. This information may be location-type information, such as building name; assigned printer resources; or any other pertinent data about the computer that may be gathered and included into the structured MIF file. The hard part of this process is gathering the information in the first place. Placing it into the NOIDMIF file and collecting the file are relatively easy. If you are able to gather the information by prompting a user with a script, or better yet, by using a script to gather the desired information automatically, you can use a script to automatically generate the formatted NOIDMIF file for collection by the SMS inventory cycle. When creating NOIDMIF files, you must place them into the %Windir%\System32\CCM\ Inventory\Noidmifs folder. The exception is that for Legacy Clients, put the NOIDMIF files in %Windir%\MS\SMS\Noidmifs. If the classes that you define within the NOIDMIF file do not exist in the database at the primary server, the class will be created upon first receipt of such a NOIDMIF file. After that, the class will already exist and the data will be placed there automatically.

■Caution

If you make a mistake, you may be creating unintended classes within your database. Test your NOIDMIF files very thoroughly in the lab before deploying them to your production environment.

You must adhere to the MIF file structure in order to have it operate correctly or as expected. A typical format for a NOIDMIF file is as follows: Start Component Name = "System Information" Start Group Name = "Company Asset Numbers" ID = 1 Class = "CompanyAssetNumbers" Key = 1 Start Attribute Name = "Computer Asset Number" ID Type = String(10) Value = "123abc" End Attribute End Group End Component

= 1

This example creates a new class called CompanyAssetNumbers, if it does not already exist. Within that class, an attribute called Company Asset Number is created and populated with a value. The example defines the value abc123, matching an asset tag that was assigned to that system upon commissioning it in the company’s environment. By using a script to read the manually populated company asset tag number that may have been entered into the system’s BIOS, or prompting the user to enter the physical



tag number through a script, you can use that script to populate the NOIDMIF text file with the asset tag information. A more complex use of a NOIDMIF file is to collect per-user information, such as drive mappings or printer mappings, place it into the Registry, and collect it via a NOIDMIF file.

■Tip Would you believe that other people have already thought of collecting many different types of information via MIF files? Of course, that’s why the SMS community is so great. Check out the SMS Expert website (http:// www.smsexpert.com/mof/scripts.asp), where you’ll find a variety of scripts for collecting different types of information. SMS IDMIF Files SMS can also collect and read IDMIF files. Unlike the NOIDMIF files, these files have a unique identifier set, and they are not associated with a record from a computer with the SMS client. As such, they are able to serve as stand-alone records of information about other types of inventory in your organization, such as network hardware, printers, or non-Windows-based computers. When creating IDMIF files, place them in the %Windir%\System32\CCM\Inventory\Idmifs folder. For Legacy Clients, put them in %Windir%\MS\SMS\Idmifs. The following is a typical format for an IDMIF file: //Architecture //UniqueId Start Component Name = "System Information" Start Group Name = "Manufacturer" ID = 1 Class = "Switches" Key = 1 Start Attribute Name = "Switch Asset Number" Type = String(10) Value = "abc123" End Attribute End Group End Component

ID

= 1

This example creates a new class called Switches, if it does not already exist. Within this class, a device named 3rdFlrSwitch is created, and an attribute named Switch Asset Number is created and populated with the value abc123. Creating data records for devices is useful when SMS would not normally inventory or be able to recover asset information for those devices. By manually creating these records, you are able to report on their existence. You may have a script that scans for these devices and collects useful asset information, such as asset number and TCP/IP address.

SMS MOF Extensions So, you know how to extend the SMS inventory through MIF files. But what about data that may have already been collected by the wonder resource, Windows Management Interface (WMI)? WMI is a standardized interface into the Web-Based Enterprise Management (WBEM) repository. Windows has implemented this repository to hold various artifacts of system information and configuration. It is fully scriptable and expandable. By using the WMI interface, you can pull various tidbits of information out of the WBEM repository on your Windows systems. A Managed Object Format (MOF) file is a structured description of information to be retrieved from within the WBEM repository about specific managed elements of a computer system. Within

205


206


the SMS_def.mof file, you can define classes and attributes to collect from the WBEM repository through WMI. You can find this on a primary site server, within x:\SMS\inboxes\clifiles.src\hinv. This location contains the master SMS_def.mof file that is read by all clients reporting to that primary site. If your hierarchy contains multiple primary site servers, you will need to work with the location on the topmost primary site. Since this is a text file, you can open it in Notepad or any other text editor of your choice.

■Caution

Make a backup copy of your SMS_def.mof file any time you fiddle with it or make any sort of Service Pack or Feature Pack updates to your sites. This especially holds true if you have already made customizations to it.

A typical section that already exists in SMS_def.mof looks like this: [ SMS_Report (TRUE), SMS_Group_Name ("BIOS"), SMS_Class_ID ("MICROSOFT|PC_BIOS|1.0") ] class Win32_BIOS : SMS_Class_Template { [SMS_Report (FALSE) ] uint16 BiosCharacteristics[]; [SMS_Report (TRUE) ] string BuildNumber; [SMS_Report (FALSE) ] string Caption; [SMS_Report (FALSE) ] string CodeSet; [SMS_Report (FALSE) ] string CurrentLanguage; [SMS_Report (TRUE) ] string Description; [SMS_Report (FALSE) ] string IdentificationCode; [SMS_Report (FALSE) ] uint16 InstallableLanguages; [SMS_Report (FALSE) ] datetime InstallDate; [SMS_Report (FALSE) ] string LanguageEdition; [SMS_Report (FALSE) ] string ListOfLanguages[]; [SMS_Report (TRUE) ] string Manufacturer; [SMS_Report (TRUE), key ] string Name; [SMS_Report (FALSE) ] string OtherTargetOS; [SMS_Report (FALSE) ] boolean PrimaryBIOS; [SMS_Report (TRUE) ] datetime ReleaseDate; [SMS_Report (TRUE) ] string SerialNumber;



[SMS_Report string [SMS_Report uint16 [SMS_Report uint16 [SMS_Report boolean [SMS_Report string [SMS_Report uint16 [SMS_Report string [SMS_Report uint16 [SMS_Report string

(TRUE) ] SMBIOSBIOSVersion; (FALSE) ] SMBIOSMajorVersion; (FALSE) ] SMBIOSMinorVersion; (FALSE) ] SMBIOSPresent; (TRUE), key ] SoftwareElementID; (TRUE), key ] SoftwareElementState; (FALSE) ] Status; (TRUE), key ] TargetOperatingSystem; (TRUE), key ] Version;

}; In this excerpt, a class is defined, along with various other attributes and a tag for SMS_Report with a value of either TRUE or FALSE. It pays to review the SMS_def.mof file before you make changes to it. You may find that the area for reporting that you want is already defined, but it is toggled off. A simple change from FALSE to TRUE may give you just what you need.

Customizing SMS_def.mof If you browse a system with the Microsoft WMI Object Browser, you may find other classes and fields within the WBEM repository. You can copy a sample syntax from the SMS_def.mof file and customize it to access another part of the repository that you want to inventory. For details on editing SMS_def.mof, take a look at the MOF Editing Guide by Michael S. Schultz. You can download the 2.5 version of the guide for free at http://www.myitforum.com/articles/1/ view.asp?id=2169. Another free resource, isn’t this great?

■Tip

For a polished and complete look at the whole MOF editing process, see The Start to Finish Guide to MOF Editing, by Jeff Gilbert. This is a great resource that walks you through the entire process. It’s available through the SMS Expert site, at http://www.smsexpert.com/mof/guide.asp.

Would you believe that there are even more free resources on this subject? The SMS Expert site offers the Monster MOF (http://www.smsexpert.com/mof/default.asp), which is a compilation of common requests into one file. It is one monster of a customization that is easy to implement and gives you instant payback. The current customizations that the Monster MOF includes are as follows:

207


208


• Extended Microsoft reporting classes • Win32_SystemEnclosure • Win32_Baseboard • Win32_ComputerSystem • Win32_PatchState • Win32_PatchState_Extended • Data and reporting classes • Backup Exec • SMS Advance Client Cache • Extended Compaq Agent Version Information • DCOM Version • Physical Memory Location • Local User Accounts • Local User Account SID List • MOF File Revision • Network Associates/McAfee – Engine and DAT versions (7.0 support added) • Network Associates/McAfee – EPO • Trend PC-Cillian AV • Symantec/Norton Anti-Virus • Internet Explorer • IIS 6.0 • Macromedia DreamWeaver Serial Number • Microsoft .NET Framework [Disable] • Microsoft Direct X • Microsoft SQL 2000 Version • Legal notice • Processor Count • Registry Profile List • Windows XP Autoupdate • DELL Information • MS Java • Win32_PnPEntity • Win32_USBController • Speed Duplex • Extended Active Setup Installed components Information • RDP Registry Update • Start Windows XP Tour Update • System Environment Variables • SLAT for Steve Bobsky Utility



Putting the Revised SMS_def.mof into Effect So, you have made the best alteration to SMS_def.mof since sliced bread, or at least since someone added the Internet Explorer version to the Monster MOF. How do you make this change take effect at the clients? It is not just as simple as editing the file and saving it back to its original location. I came up with the following process while making a customization for collecting monitor serial numbers.

■Note

If you are interested in the customization for inventorying monitor serial numbers, take a look at the article I wrote on this topic at myITforum: http://www.myitforum.com/articles/8/view.asp?id=8489.

Once you have made some customizations to SMS_def.mof, you need to save those changes back to the SMS site and distribute those changes to the clients. Follow these steps on the SMS primary server to make the changes to the SMS site. 1. Make your changes to the SMS_def.mof file. 2. At a command prompt, change your current directory to SMS\inboxes\clifiles.src\hinv. 3. Type the command mofcomp.exe sms_def.mof and press Enter. The following text should be returned on the screen, indicating success. Microsoft (R) 32-bit MOF Compiler Version 1.50.1085.0007 Copyright (c) Microsoft Corp. 1997-1999. All rights reserved. Parsing MOF file: sms_def.mof MOF file has been successfully parsed Storing data in the repository... Done! 4. Within a few minutes, the SMS policy evaluator should take note of the new addition and create a new policy for clients to retrieve on their next policy refresh cycle. Now that the changes have been made at the SMS site, they must also be applied to the clients. Follow these steps to make the alterations to the clients. 1. Create a new SMS package containing the SMS_def.mof file from the server location, F:\SMS\inboxes\clifiles.src\hinv. 2. Create a new program for this package that will execute the following command line: MOFCOMP.exe SMS_def.mof. You must ensure the program runs hidden and is executed with administrator privileges. 3. Create an advertisement that will execute the program once for every SMS client. Once this package has been distributed to a client, that client will be able to use it and report the new information to the SMS database for use in reporting and queries. Don’t forget that this inventory information can also be included in web-based reports.

Software Packaging and Scripting Products So far, we have been talking about SMS features. Here, we’ll take a quick look at a few key products that work with SMS 2003. This is by no means an endorsement of any of these products. I merely

209


210


would like to draw your attention to them. You can evaluate them and decide if they are suited to your needs and environment.

SMS Installer SMS Installer is a free product—that is, free for anyone who has a licensed SMS installation. You can download it from Microsoft at http://www.microsoft.com/smserver/downloads/20/tools/ installer.mspx. You can use this tool to perform software repackaging, capturing what has changed on a system during the installation of an application. This may not be the ideal way to redistribute software, but it is necessary in some cases. While this is a simple repackaging tool, it does fairly well at most captures, and it may be just what you need to get started. A feature that makes SMS Installer a powerful tool is its scripting language. You can build compiled scripts that run unattended or silently, prompt users for information through a GUI, manipulate the file and Registry structure, and much more. Plus, there is an option to create a stand-alone executable to perform these actions.

■Tip

You can find many existing scripts for SMS Installer, as well as documentation for using it. A great book by Rod Trent, SMS Installer (ISBN 0-07212-447-4), is a necessity when it comes to learning how to use SMS Installer. Also see the SMS Installer Scripts sections at myITforum. Check out these links: http://www.myitforum.com/ downloads/default.asp?w=3&se=SMS+Installer (for downloads) and http://www.myitforum.com/ articles/12/section.asp (for articles).

Wise Package Studio One of the long-timers in the industry is Wise Package Studio. Microsoft licensed Wise’s technology to create SMS Installer, but ceased further development except for a Windows Installer Step-up update to it. Wise evolved its product into a mature and complex offering. Wise Package Studio now sails under the Altiris flag, but is still known in the market as Wise Package Studio. The latest Wise Package Studio is version 7. The following are some of the features of interest in Wise Package Studio 7: Patch preparation and testing: Allows you to test patches without deploying them to systems. Preflight deployment: Prior to deployment, gives you an idea whether the application will succeed or fail in your real-world environment. Repackage applications: Allows you to create Windows Installer packages of applications that you repackage. InstallTailor: Allows you to create customized transform (.mst) files for Windows Installer packages. You may obtain a 30-day evaluation version of Wise Package Studio from http://www.wise.com/ Wise/Products/Packaging/Evaluation.aspx.

FLEXnet AdminStudio SMS Edition If you have a look at the SMS downloads section on the Microsoft website, you will find one link to an external vendor’s website for software repackaging tools. That tool is the FLEXnet AdminStudio SMS Edition. Macrovision provides a free version of its product for use with SMS. I believe the premise



is that you will like the free version so much that you will pay for an upgraded version with more features. The following are some of the key features in this product: Repackager: Allows you to repackage software into Windows Installer packages. Legacy Format Conversion: Allows you to convert SMS, Novell ZENworks, Windows Installer, and Wise software packages into MSI packages. Tuner: Allows you to create and edit Windows Installer transform (.mst) files. SMS Distribution Wizard: Allows you to create the .sms package definition files for use with SMS 2003. SMS Web Console: Provides access to the SMS console through a web interface. You may obtain a free copy of FLEXnet AdminStudio SMS Edition at http://www.microsoft.com/ smserver/downloads/2003/featurepacks/adminstudio/default.mspx. You will be able to use the product for a limited time. Then you will need to register the product to continue using it, but there is no charge for registration, so it’s still free.

Summary In this chapter, we looked at moving your SMS 2003 hierarchy over to your operations group. First, we discussed associating SMS 2003 with MOM 2005. Then you saw how to enable the backup task in SMS 2003. We also reviewed the disaster recovery tools that are available. Next, we explored the SMS status message features, including how to adjust message thresholds and customize filter rules. From there, we moved on to extending SMS 2003’s inventory features through NOIDMIF files, IDMIF files, and modifying the SMS_def.mof file used to perform inventory operations through WMI. We rounded this chapter off with a brief look at a few software repackaging tools: SMS Installer, Wise Package Studio, and FLEXnet AdminStudio SMS Edition.

211


Kruetzfeld_698-6INDEX.fm Page 213 Friday, November 3, 2006 6:52 PM

Index

■Numbers

Active Directory services, checking health of, 19

1E Solutions website, 190

Active Directory sites versus SMS sites, 19

/3GB switch, using, 18

Active Directory System Discovery method, using with clients, 26

10008 and 10009 message IDs, significance of, 129 900257 patch, applying for ITMU installation, 149 900401 patch, applying for ITMU installation, 149

Active Discovery System Group Discovery method, using with clients, 26

901034 patch, applying for ITMU installation, 149

Active Discovery User Discovery method, using with clients, 26

■Symbols

Add and Remove Updates dialog box, displaying, 155

/? command-line switch

address configurations

for CCMClean.exe, 70

asynchronous RAS sender addresses, 46–47

for DCDiag tool, 19

Courier Sender addresses, 47

for NetDiag tool, 20

ISDN and X.25 sender addresses, 47

using with CCMSetup.exe, 60

standard sender addresses, 46

“ (double quotes), replacing in WQL queries, 142 ‘ (single quotes), using in WQL queries, 142

addresses, role in SMS site communications, 28–29

■A

ADMIN$ share, relationship to Advanced Clients, 58

Account Review Tool, features of, 160 accounts adding to Domain Administrators group, 70 adding to Local Administrators group, 71 managing, 184 accounts in use, assessing, 160 ACL Reset tool, features of, 200 Active Directory and computer account cleanup, 20–22 running in native mode, 39 Active Directory data publishing, configuring, 38–39 Active Directory Discovery, configuring, 57 Active Directory schema. See also schema extension extending, 36 modifying Registry for, 37 updating on Windows 2000 Server, 36–37 updating on Windows Server 2003, 37

Administer console object permission, description of, 42 Administration Feature Pack Elevated-Rights Deployment Tool in, 184 Manage Site Accounts Tool in, 184 Transfer Site Settings Wizard in, 185 Administrator console accessing, 112 add-in for, 187–188 configuring site boundaries with, 89–91 customizing, 43–44 sections of, 112 setting thresholds for status messages in, 201 ADSIEdit MMC snap-in creating System Management container object with, 39 using with schema classes, 38 Advanced Client cache, resizing, 63 213


214

■I N D E X

Advanced Client installation process, troubleshooting, 63–68 Advanced Client tab of Advertisement Properties dialog box, options on, 127 Advanced Clients. See also clients; Legacy Clients configuring for Advertised Programs Agent, 53

-age command-line switch for OldCmp, description and example of, 22 agents. See client-agent configurations alerts, generating in MOM 2005, 198 /all command-line switch, for CCMClean.exe, 70

configuring on Topology Entry Form, 15

analysis step of Capacity Planner, explanation of, 12, 16

description of, 5

AppDeploy.com, overview of, 193–194

DPs chosen by, 32 extending with SMSView tool, 189

-append command-line switch for OldCmp, description and example of, 22

imaging computers with, 63

applications, scripting and repackaging, 193

installing automatically, 59–60

Applications* folders for BDD, descriptions of, 174

network considerations for, 24 prerequisites for, 58–59 receipt of advertisements by, 31

Assess phase of patch methodology, explanation of, 145

redistributing for ITMU installation, 149

asset inventory and management features, description of, 2

roamed state of, 29, 31

assumptions step of Capacity Planner

roaming boundaries of, 32 setup log file for, 67–68 uninstalling, 69–70

description of, 12 explanation of, 15–16

advanced security, switching to, 39

asynchronous RAS sender addresses, configuring, 46–47

Advertise console object permission, description of, 42

Autorun.exe GUI, using with ITMU installation on SP2 sites, 152

Advertised Programs Agent, configuring, 52–54 Advertisement Reports, displaying in Web console, 130 advertisement status, viewing, 127–129 Advertisement.log ITMU log file, location and description of, 159 advertisements creating, 124–127 creating for updates, 159 modifying, 131 monitoring, 127–130 receipt by Advanced Clients, 31

■B b “” command-line switch for OldCmp, description and example of, 21 backup media, assessing with Capacity Planner, 17 backup operations, performing, 198–199 bandwidth. See also BITS Bandwidth Manager availability of, 23 idle usage of, 4 setting on Topology Entry Form, 15

reporting success messages for, 130

BDD (Business Desktop Deployment), obtaining information about, 194

significance of, 4

BDD folder shares, creating, 172–173

using with OS images, 168

BDD Solution Accelerator

Advertisements node, creating advertisements from, 124–127

capturing build process with, 182–183

After Running field, using with program packages, 120

copying over media for, 173–175

AfterBackup.bat file, features of, 199

configuring build process for, 176–180


■I N D E X

creating Windows PE boot CDs with, 181–182 downloading and installing, 172 installing Windows media for, 175–176 requirements for, 170–171 resources for, 170 unattended folder structure for, 174–175 using, 63 BITS (Background Intelligent Transfer Service) enabling for DPs (Distribution Points), 83

CCMSetup.exe file executing, 60 installation properties for, 61 viewing progress of, 66 CCMSetup.log file, example of, 67 CCR (client configuration record) generating, 60 relationship to VB scripts for client installations, 62

features of, 4

CCR file for failed installation attempt, example of, 65–66

network considerations for, 24

ccrretry.box folder, contents of, 65

BITS Bandwidth Manager, features of, 189. See also bandwidth

CDs creating OS image capture CDs, 164–165 creating Windows PE boot CDs, 181–182

BITS server software, downloading, 83

child primary site servers, removing, 84

Blat freeware tool, downloading, 202

child primary sites, installing, 75–77

Blogcast Repository, overview of, 193

child sites, example of, 45–46

Boot disks* folders for BDD, descriptions of, 174

class security, explanation of, 40

Boot.INF file, editing for /3GB switch, 18

classes, assigning permissions to, 40

boundaries. See site boundaries

client accounts, adding for connection accounts, 54

brackets, adding with button bar, 138 build process, capturing with BDD, 182–183 button bar, using with queries, 138

■C CAPs (Client Access Points) overview of, 4 selecting for site servers, 81 Capacity Planner steps analysis step, 15–16 assumptions step, 15–16 output step, 16–17 topology step, 12–15 using preplanning worksheet with, 12

/client command-line switch, for CCMClean.exe, 70 client discovery, methods for, 25–26 Client Health Monitoring tool configuring for pulse information collection, 98–99 downloading, 95 features of, 93–94 installing and configuring, 95–98 reporting features of, 99–103 setting up, 94 Client Health Pivot Table report, using, 99–103 Client Health Service account, configuring, 94–95

capacity planning, overview of, 12

Client Health Summary Report, using, 99

.cat file, meaning of, 164

client installation, troubleshooting, 63–68

Category field, using with program packages, 120

Client MSI package, uninstalling Advanced Clients with, 69–70

CCMClean utility

Client Push Installation method, using, 59–60

command-line switches for, 70 uninstalling Advanced Clients with, 69–70

client roaming, conceptualizing, 30

Find it faster at http://superindex.apress.com

BITS clients, types of, 24

215


216

■I N D E X

client-agent configurations

counters, clearing for status messages, 93

Advertised Programs Agent, 52–54

Courier Sender addresses, configuring, 47

Hardware Inventory Agents, 49–50

Create console object permission, description of, 42

Remote Tools Agent, 51–52 Software Inventory Agent, 50–51 Software Metering Agent, 54

■D

Client.MSI.Log file, explanation of, 67–68

Data Collection Schedule setting, using with Software Metering Client Agent, 134

clients, 93–94. See also Advanced Clients; Legacy Clients

data drivers, installing ITMU to, 149

classifying with Client Health reports, 99 installing manually, 60–61 installing with machine startup scripts, 61–62 overview of, 5–6 support for, 6 uninstalling, 69–70

DCDiag tool, command-line switches for, 19 DDPS (Desktop Deployment Planning Service), using with USMT, 170 DDR (discovery data record) updates, generating, 57 /Debug command-line switch, for NetDiag tool, 20

Code Repository, website for, 54

-delete command-line switch for OldCmp, description and example of, 22

collections. See also direct-membership collections; query-based collections

Delete console object permission, description of, 42

setting up security for, 111–113

Delete Resource console object permission, description of, 42

types of, 103–104

Dell updates, tools for management of, 160

using subselect queries with, 111

Deploy phase of patch methodology, explanation of, 145–146

definition of, 103

Command Line field, using with program packages, 120

Desktop Deployment page, accessing, 194

command-line interface, features of, 184

DesktopEngineer.com, overview of, 194

comments, adding to package programs, 120

Device Management Feature Pack, description of, 3, 183

components, viewing status messages for, 92 computer accounts, cleaning up, 20–22 computer imaging system, configuring for BDD, 176–180 computer information, collecting with NOIDMIF files, 204–205 computers, imaging with Advanced Client preinstalled, 63 Config.hta, running for BDD, 176–180 connection accounts, configuring, 54–55 console permissions, setting, 39–43 consoles, customizing, 43–44

Device MP, explanation of, 98 DHCP servers, configuring for Network Discovery, 56 direct-membership collections. See also collections creating, 104–107 description of, 103 -disable command-line switch for OldCmp, description and example of, 21 DISABLECACHEOPT=[True|False] installation property, description of, 61

container collections, creating, 104–107

DISABLESITEOPT=[True|False] installation property, description of, 61

container object type, significance of, 39

disaster recovery, preparing for, 199

Control folder for BDD, description of, 174

discovery method, executing for Client Push Installation method, 60


■I N D E X

discovery scope, specifying for Network Discovery, 55–56 discovery tools, features of, 189 discovery-method configurations

■E Elevated-Rights Deployment Tool, features of, 184

Active Directory Discovery, 57

Enhanced System Discovery tool, features of, 188–189

Heartbeat Discovery, 57

Enhanced User Discovery tool, features of, 189

Network Discovery, 55–56

error messages, altering thresholds for issuing of, 93

Windows User Account Discovery, 57 Windows User Group Discovery, 57 disk space, specifying for package programs, 121

Evaluate/Plan phase of patch methodology, explanation of, 145

DistMgr.log file, tracking package IDs with, 123

EXECMGR.log ITMU log file, location and description of, 160

Distribute console object permission, description of, 42

ExtADSch.log file, location of, 38–39 Extended Security Update Inventory Tool, features of, 160

DLL, registering with RegSvr32, 36

■F

DMTF (Desktop Management Task Force), significance of, 204

Feature Packs

documentation of installation process, 11 of SMS 2003 projects, 7 Domain Administrators group, adding accounts to, 70 domain controllers, specifying for Active Directory Discovery, 57 domain discovery, tool for, 188–189 domain groups, using, 113 double quotes (“), replacing in WQL queries, 142 DP shares, adding permissions for, 54 DPs (Distribution Points) configuring, 82 defining for packages, 119

Administration Feature Pack, 184–185 description of, 1, 163 Device Management Feature Pack, 2, 183 OSD (Operating System Deployment) Feature Pack, 2, 163–170 fields, in Topology Entry Form, 14–15 -file command-line switch for OldCmp, description and example of, 22 file-structure scanning, using ImageX tool for, 163 /fix command-line switch for DCDiag tool, description of, 19 FLEXnet AdminStudio SMS Edition, features of, 210–211

installing on specific drives, 82

/f:logfile.txt command-line switch for DCDiag tool, description of, 19

protection of, 32–33

Folder option, using with packages, 116

role of, 4

folder shares, creating for BDD Solution Accelerator, 172–173

selecting for site servers, 82–83 storage of package contents by, 123 drive arrays, configuring and housing, 17 drive mode, specifying for package programs, 122 driver files, locating for OS image capture CDs, 164

-format command-line switch for OldCmp, description and example of, 22 -forreal command-line switch for OldCmp, description and example of, 22


Distribute Software Updates Wizard, running, 154–157

217


218

■I N D E X

free tools

installation. See SMS Installer

BITS Bandwidth Manager, 189

installation process, documenting, 11

console tools, 187–188

instance security, explanation of, 40

Enhanced System Discovery tool, 188–189

instances, assigning permissions to, 40

Enhanced User Discovery tool, 189

Inventory Agent log file, opening, 154

SLAT (Security Logon Audit Tool), 188

inventory cycles, starting, 50

SMSView, 189

inventory extensions

Full Schedule method, using with Hardware Inventory Agent, 49–50

■G GC (garbage collector), using with Active Directory Discovery, 57 global roaming, explanation of, 33 Group Policy, controlling BITS with, 4

MIF files, 204–205 MOF extensions, 205–209 Inventory Tools for Dell Updates Version 3, 160 for HP ProLiant and Integrity Update Tool, 160 IPC$ share, relationship to Advanced Clients, 58

groups, nesting, 113

ISDN and X.25 sender addresses, configuring, 47

■H

IT management, relationship to permissions, 42

Hardware Inventory Agent, configuring, 49–50 hardware inventory cycle, verifying execution of, 154 health check, default scope of, 96 healthy client, explanation of, 99 Heartbeat Discovery

ITMU (Inventory Tool for Microsoft Updates). See also patches features of, 146–147 log files associated with, 159–160 setting up, 153–159 ITMU installation

configuring, 57

to data drivers, 149

using with clients, 25

prerequisites for, 147–148

help desk, relationship to permissions, 41 Hierarchy Maintenance tool, features of, 200 holding sites, relationship to upgrades, 10 HP ProLiant and Integrity Update Tool, availability of, 160

on SP1 sites, 148–151 on SP2 sites, 152 ITMU package installations and programs, reviewing, 152 ITMU scan, failure of, 147

■I

■L

IBM Systems Update Tool for Microsoft SMS, features of, 160

LAN connection speeds, setting on Topology Entry Form, 15

Identify phase of patch methodology, explanation of, 145

Legacy Clients. See also Advanced Clients; clients

IDMIF files creating, 50

configuring for Advertised Programs Agent, 53

overview of, 205

description of, 5

ImageX tool in OSD Feature Pack, description of, 163

uninstalling, 69

.inf file, meaning of, 164

using NOIDMIF files with, 204

in-place upgrades, performing, 10–11

using IDMIF files with, 205


■I N D E X

Lite-Touch deployment explanation of, 167 using with BDD, 173 -llts command-line switch for OldCmp, description and example of, 21 Local Administrators group, adding accounts to, 71 local versus remote roaming boundaries, 31–32 log files, checking, 63–68 /logbackup: command-line switch, for CCMClean.exe, 70 /logdir: command-line switch, for CCMClean.exe, 70

Microsoft’s Desktop Deployment page, accessing, 194 MIF (Management Information Format) files, contents of, 50 MIF standard, significance of, 204 MIF files IDMIF files, 205 NOIDMIF files, 204–205 Modify console object permission, description of, 42 Modify Resources console object permission, description of, 42 MOF (Managed Object Format) extensions, overview of, 205–209

■M

MOF (Microsoft Operations Framework) methodology, phases of, 145–146

machine startup scripts, installing clients with, 61–62

.mof files, exporting and importing reports into, 141

maintenance mode, placing systems in, 197–198

MOM (Microsoft Operations Manager) integration with, 197–198 using with package programs, 123

Manage SQL Commands console object permission, description of, 42

MOM 2005 agent, communication with, 197

Manage Status Filters console object permission, description of, 42

Monster MOF website, accessing, 207–208

Master* folders for BDD, descriptions of, 174–175 -maxage command-line switch for OldCmp, description and example of, 22 MBSA (Microsoft Baseline Scan Analyzer), operation of, 147 memory configurations for SQL Server, 24–25 configuring, 18 Meter console object permission, description of, 42 Microsoft Tools Update package, contents of, 152 Microsoft Updates Tool in ITMU description of, 147 executing, 153–154 query rule in, 154 Microsoft Updates Tool Sync in ITMU, description of, 147 Microsoft web resources, accessing, 194

monitor serial numbers, inventory of, 209 -move command-line switch for OldCmp, description and example of, 22 MP (management point) role, selecting for site servers, 80–81 /mp command-line switch, for CCMClean.exe, 70 /mp:<machine> switch, using with CCMSetup.exe, 60 MPs (Management Points) collecting pulse information from, 96–99 explanation of, 5 and roaming clients, 30–31 types of, 30 MSAC.exe, explanation of, 184 .msi files, importing for program packages, 122–123 MSXML Parser 3.0, using with ITMU, 148 MVPs (Most Valuable Professionals), significance of, 194


logon information, using SLAT tool for, 188

Manage Site Accounts Tool, features of, 184

219


220

■I N D E X

myITforum.com

operators, adding with button bar, 138

Blogs section of, 193

OS image capture CDs, creating, 164–165

description of, 191

OS image installation CDs

downloading BITS Bandwidth Manager from, 189 e-mail discussion lists on, 192

creating, 168–169 using, 169–170 OS images

e-mail discussion-list commands on, 192–193

capturing and storing, 163

examples of subselect queries on, 111

capturing with OS image capture CDs, 165–166

inventory of monitor serial numbers on, 209 SMS Installer Scripts sections at, 210

■N native mode, running Active Directory in, 39 nested direct-membership collections, creating, 104–107 NetDiag tool, switches for, 20 network bandwidth usage graphs, equesting, 23 network connections, managing, 18 Network Discovery, configuring, 25, 55–56 network load, considering, 23–24 network maps, contents of, 23 New OS Program Wizard, starting, 167 -newparent “<parent dn>” command-line switch for OldCmp, description and example of, 22

deploying captured images, 167–170 deploying in Lite-Touch fashion, 168 OSD (Operating System Deployment) Feature Pack features of, 163 ImageX tool in, 163 installing, 164 Windows PE (Preinstallation Environment) in, 163 OSD image packages, creating, 166–167 OSD Plus Pack, features of, 190 OSDICW.exe file, executing, 165 OSDInstallWizard.exe, running, 168, 169 output step of Capacity Planner description of, 12 explanation of, 16–17

NightWatchman tool, features of, 190

■P

NOIDMIF, effect of, 50

package IDs, tracking, 123

NOIDMIF files, overview of, 204–205

package information, sending with Courier Sender, 47

non-Windows platforms, management of, 191

packages. See also programs for packages

■O

checking status of, 123–124

objects

creating, 116–118

assigning permissions to, 41–42 unlocking, 84–86 obsolete client, explanation of, 99 offline client, explanation of, 99 OldCmp utility, command-line switches for, 21–22 -onlydisabled command-line switch for OldCmp, description and example of, 22 Operating System Deployment Feature Pack, description of, 2

defining DPs for, 119 defining programs for, 119–123 definition of, 115 specifying installation of, 120 patch management, reports available to, 160 patches. See also ITMU (Inventory Tool for Microsoft Updates) applying for ITMU installation, 149 creating advertisements for, 159 features of, 145


■I N D E X

methodologies to, 145–146 tools for management of, 160

Program Properties dialog box Advanced tab in, 122

Patchinstall.log ITMU log file, location and description of, 160

Environment tab in, 121–122

PatchUIMonitor.log ITMU log file, location and description of, 160

MOM tab in, 123

permission schemes, combining, 113 permissions altering on SQL views, 143 assigning, 40–41 assigning to objects, 41–43 considering, 52 considering for secondary sites, 70–71 setting for console, 39–43 tightening for DP shares, 54 Permitted Viewers console object permission, description of, 43

General tab in, 119–120 Requirements tab in, 121 Windows Installer tab in, 122–123 programs for packages. See also packages defining, 119–123 naming, 119 running, 120 projects documenting, 7 pilot phase of, 7–8 POC phase of, 7 publishing site-specific information, 38–39 pulse information collection

per-user information, collecting with NOIDMIF files, 205

configuring Client Health Monitoring tool for, 98–99

pilot phase, overview of, 7–8

from MPs, 96–97

ping option, enabling in Client Health Monitoring tool, 96 PivotTable, using in Client Health Monitoring tool, 100

■Q /q command-line switch for CCMClean.exe, 70

.pkg extension, meaning of, 117, 123

for DCDiag tool, 19

PMPs (Proxy Management Points)


considering, 27 explanation of, 5 POC (proof of concept) phase, explanation of, 6–7 PocketPC platforms, managing, 183 policy requests, enabling logging for pulse information, 99 preplanning worksheet, using with Capacity Planner, 12 primary sites communication with secondary sites, 72

/qb- switch, uninstalling Advanced Clients with, 69 queries using button bar, 138 using subselect queries with collections, 111 writing, 136–140 query-based collections. See also collections creating, 107–111 description of, 103 Quest Management Xtensions website, 191 quotes (“), replacing in WQL queries, 142

considering, 26 defining site boundaries for, 91

■R

installing child primary sites, 75–77

RAM

program notifications, suppressing for package programs, 122

assessing with Capacity Planner, 17 using /3GB switch with, 18 Rate Limits tab, using with sender addresses, 48


setting on System container, 38

221


222

■I N D E X

Read console object permission, description of, 42

-rsort command-line switch for OldCmp, description and example of, 21

Read Resources console object permission, description of, 42

RSS (Really Simple Syndication), significance of, 192

Recovery Expert, features of, 199 redundancy, removing with protected DPs, 33

Run a Program option, using with status messages, 202–203

reference site, supplying for Site Repair Wizard, 199–200

run mode, specifying for package programs, 121–122

regional roaming, explanation of, 33

run time, specifying for package programs, 121

Registry

Run_once.exe, explanation of, 184

editing to unlock schema update ability, 37 modifying for schema, 37 RegSvr32, registering DLL with, 36 remote diagnosis features, description of, 2 Remote Tools Agent, configuring, 51–52 remote versus local roaming boundaries, 31–32 /removehistory command-line switch, for CCMClean.exe, 70

■S /s: servername command-line switch for DCDiag tool, description of, 19 -safety “” command-line switch for OldCmp, description and example of, 22 scanning tools, features of, 160 Schedule tab

-report command-line switch for OldCmp, description and example of, 21

of Advertisement Properties dialog box, 125–126

reports

of Sender Address Properties dialog boxes, 48

Advertisement Reports in Web console, 130 importing and exporting web reports, 141 for patch management, 160 in SLAT (Security Logon Audit Tool), 188 software metering reports, 135 Web-based reporting features, 2 web reports, 141–143 resync, relationship to Hardware Inventory Agent, 49 /retry:<minutes> switch, using with CCMSetup.exe, 60 /retry:, command-line switch, for CCMClean.exe, 70 roaming explanation of, 29–30 regional and global roaming, 33 roaming boundaries, local versus remote types of, 31–32 roaming clients, relationship to MPs, 30–31 RPs (Reporting Points) explanation of, 5 selecting for site server, 78–79

scheduling methods, using with Hardware Inventory Agent, 49 schema classes, using ADSIEdit MMC snap-in with, 38 schema extension. See also Active Directory schema during installation, 23 prior to installation, 35 requirements for, 36 verifying, 38 Schema MMC snap-in registering, 36 starting, 37 schema update ability, unlocking, 37 Screenshot Captor website, accessing, 11 screenshots, documenting installation with, 11 scripted tasks, chaining to end of backup process, 199 Scripting Guys website, accessing, 194 scripts, executing with Run a Program option, 202


■I N D E X

SCRM (System Center Report Manager) 2006, features of, 198 secondary sites communication with primary sites, 72 considering, 26–27

site boundaries configuring, 89–91 modifying to uninstall Legacy Clients, 69 naming, 90 setup of, 29

defining site boundaries for, 91

site clients, assignment of, 91. See also SMS sites

installing, 70–74

site configuration options, accessing, 44–45

performing SQL Server replication to, 27

site hierarchy, designing and sizing, 12

placing PMPs at, 27 removing, 83 uninstalling, 83 security, setting up for collections, 111–113 security bulletins, tool for detection of, 160 security configurations, types of, 40 security modes, choosing, 39 security objects, granting permissions to, 40 Security Rights node, assigning permissions by means of, 40 sender addresses, configuring, 46 senders capabilities of, 45 configuring, 48

site information, accessing, 91 site lists, refreshing, 92 site management tasks, accessing, 134–135 Site Repair Wizard, features of, 199–200 site servers prerequisites for, 3 selecting CAP (client access point) role for, 81 selecting DP (distribution point) role for, 82–83 selecting MP (management point) role for, 80–81 selecting RP (reporting point) for, 78–79 selecting SLP (server locator point) role for, 79–80 SQL installations on, 4

role in SMS site communications, 28

Site Status node, accessing, 91

specifying server names for, 48

Site System account, using, 55

server administrators, relationship to permissions, 42 server memory, configuring, 18 server name, specifying for senders, 48 servers, choosing for site systems, 77–78 Service Packs, using with ITMU, 148 Settings.XML file, editing for pulse information collection, 98

site systems, adding, 77–83 sites. See SMS sites site-specific information, publishing, 38–39 SLAT (Security Logon Audit Tool), features of, 188 SLPs (Server Locator Points) explanation of, 5 selecting for site servers, 79–80

-sh command-line switch for OldCmp, description and example of, 22

SLPSetup.Log file, location of, 79

shutdown, managing with NightWatchman tool, 190

SMS (Systems Management Server) 2003, features of, 2

side-by-side upgrades, performing, 10

SMS 2003 projects

Simple Schedule method, using with Hardware Inventory Agent, 49 single quotes (‘), using in WQL queries, 142 site assumptions. See assumptions step of Capacity Planner

documenting, 7 pilot phase of, 7–8 POC phase of, 7 SMS 2003 Toolkit, downloading, 63


security features, description of, 2

223


224

■I N D E X

SMS Administrator console. See Administrator console

SMS2003ITMU_ENU.exe, executing, 148

SMS Advertisement Status. See advertisement status

SMSCLIUI.log ITMU log file, location and description of, 159

SMS Client Health Monitoring tool. See Client Health Monitoring tool

SMSDIRECTORYLOOKUP=[True|False] installation property, description of, 61

SMS clients. See also Advanced Clients; Legacy Clients

SMSFULLREMOTETOOLS=[0|1] installation property, description of, 61

classifying with Client Health reports, 99 installing manually, 60–61 installing with machine startup scripts, 61–62

SMSbkup.ctl file, contents of, 198

SMSITMU.msi, installing manually for SP2 sites, 152

overview of, 5–6

SMSMP=<ServerName> installation property, description of, 61

support for, 6

SMSNomad Branch tool, features of, 190

uninstalling, 69–70

SMSNOWINSLOOKUP=[True|False] installation property, description of, 61

SMS Companion 2006 package, features of, 190–191 SMS Expert website, accessing, 205 SMS Installer, features of, 210 SMS packages. See packages SMS sites. See also site clients versus Active Directory sites, 19 and CAPs (Client Access Points), 4 communications on, 28–29

SMSPROV.log file, using with web reports, 141–143 SMSSITECODE=XXX installation property, description of, 61 SMSView tool, features of, 189 SMSWakeup tool, features of, 190 SMSWUSHANDLER.log ITMU log file, location and description of, 159

and DPs (Distribution Points), 4

SNMP community names, specifying for Network Discovery, 56

explanation of, 3

software distribution

installing child primary sites, 75–77

features of, 2

installing secondary sites, 70–74

showing in Status Viewer, 128

and MPs (Management Points), 5

Software Inventory Agent, configuring, 50–51

and PMPs (Proxy Management Points), 5 primary sites, 26

“Software Inventory Scripts for SMS” article, accessing, 50

removing child primary site servers, 84

software metering

removing secondary sites, 83

defining rules for, 131–132

and RPs (Reporting Points), 5

overview of, 131

secondary sites, 26–27

scheduling, 132–134

and site servers, 3

Software Metering Client Agent

and SLPs (Server Locator Points), 5

configuring, 54

systems and roles for, 4

enabling, 132–133

SMS Software Metering Client Agent. See Software Metering Client Agent

features of, 131

SMS User Wizard, assigning permissions with, 41

using Data Collection Schedule setting with, 134

SMS_def.mof file

scheduling, 133–134

software metering features, description of, 2

customizing, 207–208

software metering reports, using, 135

using, 205–207, 209

software metering tasks, configuring, 134–135


■I N D E X

software repackaging tool, FLEXnet AdminStudio SMS Edition, 210–211

synchronization host, specifying for ITMU installation, 150

software specialists, relationship to permissions, 41

Sysprep tool

Solution Accelerator for BDD. See BDD Solution Accelerator -sort command-line switch for OldCmp, description and example of, 21 source file options specifying for packages, 117 specifying for secondary site servers, 72

obtaining, 165 using with OS image capture CDs, 164 System Center Capacity Planner 2006 tool, downloading, 33 System Center product line, features of, 198 System container, setting permissions on, 38 system discovery tool, features of, 188–189

Source* folders for BDD, descriptions of, 175

System Management container object, creating with ADSIEdit MMC snap-in, 39

/source:<path> switch, using with CCMSetup.exe, 60

System Status node, accessing, 91 system types, specifying for Client Push Installation method, 60

SP1 sites, installing ITMU on, 148–151

%system32%\CCM\Logs folder, contents of, 68

SP2 sites, installing ITMU on, 152

SQL Server replication, performing to secondary sites, 27 SQL Server settings, considering, 24–25 SQL views, altering permissions on, 143 SSRT_Log.log file, contents of, 185

■T TechNet website, Systems Management Server Community page on, 194 Templates folder for BDD, description of, 174 /test:testname command-line switch for DCDiag tool, 19 for NetDiag tool, 19

standard security mode, using, 39

tools. See free tools

Standard Sender, using, 28

Topology Entry Form, fields in, 14–15

Start In field, using with program packages, 120 Status Message Viewer options, setting, 93

topology step of Capacity Planner, description of, 12–15

status messages

Trace tool

clearing counters for, 93 filtering, 202–203 numbering of, 129 thresholds for, 200–202 using Web console with, 129–130 viewing for components, 92 Status Summarizers node, accessing, 93 Status Viewer adjusting settings in, 129 showing software distribution in, 128 subselect queries, using with collections, 111 suspected unhealthy client, explanation of, 99 Sync program, executing for Updates Tool, 153–154

setting up software metering rule for, 131–132 using with queries, 140 Transfer Site Settings Wizard, features of, 185 Trent, Rod (myITforum.com), 191 troubleshooting support for, 2 update deployment, 159–160 Windows PE boot CDs, 182

■U UNC access, verifying for BDD, 173 UNC path, entering for OS image installation CD, 169 unhealthy client, explanation of, 99


SP1 Scan Tools, features of, 160

SQL query statements, format for web reports, 143–144

225


226

■I N D E X

-unsafe command-line switch for OldCmp, description and example of, 22 update deployment, troubleshooting, 159–160 update distribution, setting up, 154–158 update schedules, using, 160 updates. See also ITMU (Inventory Tool for Microsoft Updates)

■W wake cycle, triggering with SMSWakeup tool, 190 warning messages, altering thresholds for issuing of, 93 WBEM, relationship to WMI, 6

applying for ITMU installation, 149

Web console, viewing status messages with, 129–130

creating advertisements for, 159

web reports. See also reports

features of, 145

importing and exporting, 141

methodologies to, 145–146

retrieving converted WQL for, 141–143

tools for management of, 160 Updates Tool in ITMU description of, 147

Web-based reporting features, description of, 2 webcast, definition of, 194 websites

executing, 153–154

1E Solutions, 190

query rule in, 154

10009-message troubleshooting, 129

upgrades

Active Directory health check, 19

in-place upgrades, 10–11

Administrator console tools, 188

performing, 10

BDD (Business Desktop Deployment), 194

side-by-side upgrades, 10

BITS Bandwidth Manager, 189

Use Remote Tools console object permission, description of, 43

BITS control via Group Policy, 4

user connections, considering for SQL Server, 24

Blat freeware tool, 202

user discovery tool, features of, 189 user logon information, using SLAT tool for, 188

BITS server software, 83 Client Health Monitoring tool, 95 Code Repository, 54 Enhanced System Discovery tool, 188

/useronly switch, using with CCMSetup.exe, 60

Enhanced User Discovery tool, 189

-users command-line switch for OldCmp, description and example of, 21

FLEXnet AdminStudio SMS Edition, 211

USMT (User State Migration Tool), features of, 170

Microsoft, 194

memory configurations, 18 Monster MOF, 207

■V

myITforum, 191

/v command-line switch

mylTforum.com, 111

for DCDiag tool, 19

OldCmp utility, 21


OSD imaging deployment, 168

VB (Visual Basic) scripts installing clients with, 61–62 for resizing Advanced Client cache, 63 View Collected Files console object permission, description of, 43

preplanning worksheet for Capacity Planner, 12 Quest Management Xtensions, 191 Registry modifications for schema, 37 schema extension, 36 Screenshot Captor, 11 Scripting Guys, 194


■I N D E X

SCRM (System Center Report Manager) 2006, 198

Windows Server 2003, updating schema on, 37

SLAT (Security Logon Audit Tool), 188

Windows Update Agent Component in ITMU, description of, 147

SMS 2003 Capacity Planner, 12

Windows Update catalog, features of, 146

SMS 2003 Toolkit, 63

Windows User Account Discovery, configuring, 25, 57

SMS Companion 2006 package, 190 SMS Expert, 205 SMS Installer, 210 SMSView tool, 189 “Software Inventory Scripts for SMS”, 50

Windows User Group Discovery, configuring, 26, 57 Windows XP installation file directories for BDD, 176

Solution Accelerator for BDD resources, 170

Windows XP Professional SP2, completing BDD Build tab for, 178

SQL Server replication, 27

Wise Package Studio, features of, 210

The Start to Finish Guide to MOF Editing, 207

WMI (Windows Management Interface)

topology step of Capacity Planner, 13 Windows Installer 3.1, 148 Wise Package Studio 30-day evaluation version, 210

relationship to MOF extensions, 205 relationship to WBEM, 6 WMI provider, unlocking objects with, 84–86 WMI SDK, downloading, 84 WQL, retrieving for web reports, 141–143

WMI Scripting Primer, 6

WQL query statements, displaying, 139

WMI SDK, 84

WUSSyncXML.log ITMU log file, location and description of, 160

WIM (Windows Imaging) format, significance of, 163 Windows, managing non-Windows platforms, 191 Windows 2000 Server, updating schema on, 36–37

WUSSyncXM.log file, location of, 159

■X /x switch, uninstalling Advanced Clients with, 69

Windows CE platforms, managing, 183

X.25 and ISDN sender addresses, configuring, 47

Windows Installer, web resource for, 194

XImage, ImageX tool as, 164

Windows Installer 3.1, using with ITMU, 147–148

■Z

Windows Installer files, importing with package programs, 122–123 Windows media, installing for BDD, 175–176 Windows PE boot CDs, creating with BDD, 181–182

Zero-Touch installation explanation of, 167 using with BDD, 173


System Center Capacity Planner 2006 tool, 33

227

Pro SMS 2003

Sms

Professional MOM 2005, SMS 2003, and WSUS

SMS 2003 Administrator's Reference: Systems Management Server 2003

1000 лучших sms-розыгрышей

SMS für dich

Nieuw sms-bericht

6000 супер SMS

Pro Windows Small Business Server 2003

SMS für dich

SMS Konig by rusadir

SMS für dich

SMS aus dem Grab

Живи играючи с sms

1001 прикольных sms-ок

Pro Apache Ant (Pro)

Pro Python (Pro Series)

Pro PHP Security (Pro)

Pro JavaScript Techniques (Pro)

Pro Perl Parsing (Pro)

Pro Perl Parsing (Pro)

Programming Microsoft Outlook and Microsoft Exchange 2003 (Pro-Developer)

Programming Microsoft Visual Basic .NET Version 2003 (Pro Developer)

Pro Apache Tomcat 6 (Pro)

Die drei ??? SMS aus dem Grab

2003)

2003)

2003)

2003)

Pro Ajax and Java (Pro)

Pro SMS 2003

Sms

Professional MOM 2005, SMS 2003, and WSUS

SMS 2003 Administrator's Reference: Systems Management Server 2003

1000 лучших sms-розыгрышей

SMS für dich

Nieuw sms-bericht

6000 супер SMS

Pro Windows Small Business Server 2003

SMS für dich

SMS Konig by rusadir

SMS für dich

SMS aus dem Grab

Живи играючи с sms

1001 прикольных sms-ок

Pro Apache Ant (Pro)

Pro Python (Pro Series)

Pro PHP Security (Pro)

Pro JavaScript Techniques (Pro)

Pro Perl Parsing (Pro)

Pro Perl Parsing (Pro)

Programming Microsoft Outlook and Microsoft Exchange 2003 (Pro-Developer)

Programming Microsoft Visual Basic .NET Version 2003 (Pro Developer)

Pro Apache Tomcat 6 (Pro)

Die drei ??? SMS aus dem Grab

2003)

2003)

2003)

2003)

Pro Ajax and Java (Pro)

Recommend Documents