Examining Microsoft's SMS 2003

Whether you're creating a whole new SMS hierarchy or simply upgrading, you must decide whether to extend your AD schema to include SMS 2003 objects. Such objects will let you identify software deployments and run reports based on OUs (organizational units), as opposed to just users and groups.

We use OUs for access control within our departments, and AD simplifies managing and organizing our desktops. We also define SMS site boundaries logically to mirror AD topologies rather than being limited to IP subnet ranges. That way, we can distribute access rights to collections and packages by the management structure in our organization.

We used AD Discovery to install the SMS client. SMS 2003's handy, automatic collection updates ensure that all machines added to the OUs are accounted for. (See a list of SMS 2003's discovery methods.)

You can customize AD directory synchronization by designating schedules and directory-tree objects to transfer. Integrating SMS 2003 with AD lets your advanced clients roam from one AD site to another and facilitates the exchange of secure keys between SMS site components. Unfortunately, SMS 2003 doesn't allow different client settings among groups of machines under the same site system.

Addressing Security If you do integrate AD with SMS 2003, select the Advanced Security option in your SMS 2003 site system. Then you can perform SMS functions using local system and computer accounts, which are more secure than user accounts. Advanced Security generally requires SQL Server 2000 SP3 in Windows authentication-only mode and SMS site servers running Windows 2000 Server SP4 or above, or Windows 2003 Server in an AD native environment. If all your SMS component servers are running W2K SP4 or above, a mixed-mode AD environment will also suffice for the Advanced Security option.

If you're running Microsoft WINS (Windows Internet Naming Service) without AD, you must use SMS 2003's Standard Security mode. That works much like SMS 2.0, with local and domain user accounts running the SMS services and connection accounts for communicating between clients and site servers.

SMS 2003's advanced client, meanwhile, runs only on Windows 2000 and higher, so if you have Windows NT or 98, you'll need to run 2003's legacy client instead. Much like the SMS 2.0 client, the legacy client requires a CAP (Client Access Point) to push and receive data between itself and the site server.

The advanced client really shines with mobile and remote machines. The key is that it uses the HTTP-based BITS (Background Intelligent Transfer Service), which provides background file transfers, checkpoint restarts and bandwidth throttling. Besides letting you use local distribution points for roaming PCs, the advanced client can stage future software deployments. Since it's packaged as a downloadable Microsoft Installer utility, its installation is much more flexible than that of the standard client.Planning a major upgrade for your existing apps can be intimidating. First, SMS 2.0 shops must decide up front whether to do an in-place upgrade or an all-new installation of SMS 2003. In the Online Library included in the SMS 2003 CD, Microsoft recommends a new installation. But you can get more information on upgrading an SMS 2.0 site in Microsoft's SMS Concepts, Planning, and Deployment Guide.

The minimum requirements for upgrading to 2003 from SMS 2.0 are SMS 2.0 SP4, Windows 2000 server SP2 and SQL Server 7.0 SP3. Windows 2003 Server can run SMS on either the Standard, Datacenter or Enterprise Editions (see "Spec It Out," on page 84). If any of your 2.0 sites report to your new 2003 site, they also must be SMS 2.0 SP4 or higher before you upgrade the main site. The SMS site database runs on SQL Server 7.0 SP3 or higher. Before you start your upgrade, run the SMS setup with the /testdbupgrade switch on a copy of the SMS 2.0 site database (setup.exe /testdbupgrade SMS_). Back up your entire SMS 2.0 site by using the built-in task under site maintenance called "Backup SMS Site Server." This backs up the site database, as well as registry keys and the SMS directory structure.

Then run the Deployment Readiness Wizard (DRW.EXE) on the SMS 2003 CD. It tests the SMS 2.0 site server and creates a list of its components that either passed, failed or generated a warning.

And if you're going to modify your schema for SMS 2003, run the ExtADSch.exe tool after the upgrade. It's located on the SMS 2003 CD under SMSSetupBINI386.

SMS 2.0 clients are upgraded automatically to the SMS 2003 legacy client by default. If you have a large number of SMS 2.0 clients that can't handle the required bandwidth for the upgrade (12 MB), or if you want to go directly to the advanced client, you can stop that auto-upgrade with the Client Upgrade Control tool (Cliupgrade.exe). Refer to the CPIG for how to execute this phased-site upgrade strategy.

Parallel Universe Our upgrade with SMS 2.0 and 2003 running side by side has helped us get familiar with SMS 2003 in a production environment without affecting the existing SMS 2.0 infrastructure.

We installed a new Windows 2003 server and started with a clean slate on our database--there were no remnants of SMS 2.0 tables. We could easily upgrade our SMS 2.0 clients to 2003 by phasing them in. Wherever possible, we deployed the advanced client.

The downside is that we need additional servers and resources to maintain the two hierarchies. So this deployment method may not be feasible for a multitier SMS environment with hundreds or thousands of SMS servers.

We had to re-create queries and collections or import them into the new site, as well as re-create site boundaries and packages/advertisements. Security rights also had to be redefined for SMS 2003. We made those changes with Custom Setup rather than Express Setup, since the former enables only Heartbeat Discovery, which is just a pulse-check of the client machines.

The Express Install enables most 2003 discovery methods, including the client-push installation, the hardware-inventory client agent, the advertised-programs client agent and the remote-tools agent. But some of the enabled defaults can do more than you bargained for, like upgrade every PC in your site hierarchy. You'll get more hands-on experience with SMS if you go through Custom Setup instead. The SMS Setup wizard provides a screen for extending your AD schema. If you choose that option, make sure the account you're using for the SMS installation has also been added to "schema admins."

Upon completing our installation, we looked at the "SMSSETUP.LOG" on the root of the system drive. We were interested in the messages on the extension of the AD schema. Everything appeared to be installed correctly, but we verified this by perusing the SMSSETUP.LOG. We were anxious to know the outcome because in the lab, we had problems with classes being defined inside AD. After the lab installation, we were able to add the attributes to AD, but not the classes. We added the SMS machine account to the system container inside AD, granting it "full control." That solved the problem.

We proceeded to add IP subnet site boundaries for our clients. The client agents were also enabled and defined, along with a new domain admin account for installing the SMS 2003 client. We added this account to the client push-installation property and configured the advanced client with the three-character SMS Site code.

The next step was running the AD system discovery and defining a custom LDAP path to the desired OU. With the data-discovery records inside the SMS 2003 site system, we pushed the advanced client to 10 machines that had an SMS 2.0 client tied to another site server. We used the client-push installation wizard to deinstall the 2.0 client and install the 2003 advanced client.

Deploying the 2003 advanced client was simple. The AD system discovery was particularly helpful in pushing the client to our machines. SMS 2003 comes with tools for tackling problems arising during and after installation (see "Steering Clear of Trouble With the Right Tools,").With the maddening onslaught of security exploits that have surfaced over the past six months, keeping up with software updates and patches has become a bigger job than ever. SMS 2003's SUM (Software Update Management) simplifies this by automatically handling the distribution, inventory and reporting for security updates. We found it easy to create security update packages and advertisements to stamp out vulnerabilities. There's a wizard that walks you through the process. The advertisement installs the correct OS version of the patch for you, using inventory information culled from the workstation.

Unlike with 2.0, the update-management component is built into SMS 2003. To scan for the security updates in SMS 2003, you must download the tools from Microsoft. If your SMS 2.0 site has the SUS (Software Update Services) add-on, you must uninstall its update wizard before you go to 2003. During the upgrade, you can specify that you want to keep the old package, collections and advertisements from the original feature pack.

In our environment at the University of Michigan Health System, security-update packages--along with advertisements--had to be created on both SMS 2.0 and 2003 sites during the migration.

Another cool feature of SMS 2003 is its reporting tool, which is integrated into the SMS administration console. There are more than 160 predefined reports covering hardware, software and security data on your machines, and you can use these reports to evaluate gaps in licensing, hardware- compliance issues and security-patch deployment.

To enable the reporting feature, define a reporting point under the SMS Site System Properties (a server must run IIS 5.0 or higher to be a reporting point). The reporting mechanism also includes SMS' dashboard, a quick and easy way to display reports in a grid format. The dashboard lets you view multiple reports in a single table (see screenshot, page 85.) Getting a Grip on the Desktop

To get the most out of SMS 2003, make sure from the outset that you can implement AD integration, advanced client and advanced security in your environment. Then you can let the system handle software-update management and generate Web reports.

SMS' interface, the Microsoft Management Console, is largely unchanged, so it should make the transition from 2.0 painless. In a way, we're disappointed that Microsoft hasn't given SMS a new look and feel after three years of development. But once SMS 2003 is up and running, desktop management gets a whole lot easier.

John Kaminski is a systems administrator at the University of Michigan Health System. Write to him at Johntk@ umich.edu. Oscar A. Olivo Jr. is a consulting engineer at the University of Michigan Health System. Write to him at [email protected].