Spreading the SMS 2003 Gospel

A university's IT structure is somewhat different than corporate IT's. Typically, organizations have one IT department responsible for operations throughout the business. But at the University of Iowa—as at other higher-education institutions—IT generally consists of many autonomous departments scattered across campus, held loosely together by a central IT operations area. Chris Blasen, an IT manager in the university's Enterprise Client Management department, faced the challenge of persuading the university's various IT departments to automate their software-deployment and patch-management processes by adopting a central management tool, such as Microsoft Systems Management Server (SMS) 2003. Chris and his department took a "soft-sell" approach to communicating the technology's benefits, which included developing a public SMS Web site to provide admins in the other IT areas with SMS information and tools. Senior editor Anne Grubb spoke with Chris about this innovative approach to encouraging technology adoption and how the university's IT departments and end users have benefited from SMS.

What prompted your department to start promoting the use of SMS to other IT departments around campus?
A few years ago, we were using SMS 2.0 for our student-computing labs. After Microsoft released SMS 2003, we got the idea that we could leverage SMS across campus. For example, because SMS 2003 had Active Directory (AD) integration, we could use [Windows] security to create a console specifically for the library college that let them see only their own resources.

University of Iowa has a public SMS Web site (http://spa.its.uiowa.edu/ecm/imaging/sms). Why did your department, Enterprise Client Management, develop such a site, and what's it used for?
In an educational institution like ours, the central IT department provides a lot of the infrastructure and the tools—in this case, SMS—to the other departments. Our central IT operations decided to develop the site to share information about SMS across campus as well as with other higher-education institutions and also to provide a support mechanism for all our SMS managed departments. We've had the Web site in place about a year and a half. It started out pretty small, but we've added more SMS content as we've moved along. We also have an internal SMS Web site, which isn't public. It's where our core SMS administrators manage the SMS site and contains areas that are more administrator-specific.

How many SMS site servers do you have, and how many users do you support?
We actually have only one site server, but we use AD security groups and delegation to make it appear that we have 25 SMS sites. Departments can use their console and see only their own resources, although they're all shared on one box. The reason we went with one site server was because in our environment, we have multiple domains in a forest, so that having multiple SMS site servers would cause problems because of overlapping subnets. For example, clients wouldn't have been able to talk to management points if a new site server came online.

We're currently supporting 25 collegiate departments and almost 4500 SMS clients. We've had a steady, consistent growth [in the number of SMS users we're supporting]—maybe three or four departments a month signing on. The SMS Web page has a sign-up form that users can fill out and request information to become an SMS partner.

How has the use of SMS 2003 helped the university's IT operations?
One of our key drivers for deploying SMS 2003 was so we could monitor the status of security updates on machines around campus. When the Blaster worm came out a couple years ago, it took us several months to recover from it. In our environment, users jump around [from port to port]. A user with a laptop might realize that his or her port was turned off but had no idea that the machine was infected. The user would just disconnect from a jack and plug into another. In this way, the infection had a domino effect. The admins had to go around campus and look at machines [individually] and monitor and shut off ports.

As a result of our Blaster experience, we wanted to use a management tool to monitor desktop security. SMS 2003's Web-reporting capabilities have helped us quite a bit in doing this. We run daily morning reports, which tell us what machines might not be getting updates and why. [By using the information from the reports,] we can deploy the needed updates to a collection of machines.

Once the colleges came on [to using SMS], they estimated their time savings at roughly 50 to 60 percent of their IT resources because they weren't having to run around and physically touch every machine. If they had to deploy a new version of an application, they could build a new package and deploy it. This saves time as compared with installing it manually on all these machines. [As a result of this time savings,] the departments have been able to focus on other projects that they've been wanting to implement— more strategic tasks than installing updates and deploying applications.

Another benefit is that, through SMS, we've built a repository of application-deployment packages. When we deploy a new version of Office or a user requests an application, we can use a package from the repository to deploy the application to one machine or hundreds relatively quickly. On the public SMS site, we share many of those packages with other departments, so that 25 different administrative units don't have to duplicate the effort [of creating a package], other than perhaps changing certain settings and deploying the advertisement on their own schedule.

Have you customized SMS 2003 at all for your environment—for example, integrating scripts to perform deployment tasks?
We built a custom VBScript script that looks at the machines' registry [and identifies whether] the computers have the right version of antivirus software installed and also whether they're getting their signature files when they're supposed to. We edited the def.mof [hardware inventory definition] file to integrate the script with the SMS reporting. Every morning we can see, through the Web reporting tool, whether the signature files are out of date, and if so, correct that problem. Without the daily reporting, it might be weeks or months before someone discovers that the signature files are out of date.

Are there any features you'd like to see in the next SMS version?
We'd like to see [Microsoft] change the SMS security model so that it's oriented toward the AD file structure, using the file system's user and group security. The ability to do multicasting using the Operating System Deployment Feature Pack would also be beneficial. Finally, we'd like to be able lock down management points, to make sure that an administrator can't create an independent SMS site, which creates communications issues with the SMS clients.