Stefan Suesser faced a potentially daunting challenge: As the server expert
on his IT department's infrastructure design team, he had to craft a way to
migrate his company from Microsoft Systems Management Server (SMS) 2.0 to SMS
2003, since no third-party SMS 2.0–SMS 2003 migration tools exist. Stefan
works for Computacenter, a well-known European provider of IT infrastructure
services. Its central IT department, located in Kerpen, Germany, supports around
220 servers in the data center (most running Windows Server 2003), in addition
to servers at the branch offices. With so many servers, SMS migration wouldn't
be a trivial affair. Fortunately, Stefan was well qualified to script a migration
solution, having achieved 100 percent in the advanced categories of VBScript
and Windows PowerShell at Microsoft's 2007 Scripting Games. In a recent conversation,
Stefan explained to me the components of his solution and how it works.
Why did you decide to upgrade to SMS 2003?
Computacenter Germany introduced SMS 2.0 in 2001. Over the years, we [realized] the design of our SMS 2.0 implementation was less than optimal, so we came up with a plan to start from scratch, implement a new and simplified SMS 2003 infrastructure, and leverage new features such as Advanced Client, software update management, Active Directory (AD) integration, and protected distribution points. Software updates and patches were a major concern because Computacenter used a homegrown patch-installation mechanism that didn't scale to our needs; if we had stayed with SMS 2.0, a major redesign of the tool would have been necessary.
Computacenter has a number of SMS experts. We did the concept and planning for the new SMS 2003 infrastructure together with colleagues from Computacenter's consulting division, and central IT managed the implementation and migration by itself.
How much scripting experience did you have before coming up with this solution? Have you created other scripting solutions for your environment?
I have years of experience in programming and started using VBScript in 2000. Over the years, I've created a number of large and small scripting solutions. In 2000, when SMS 2.0 wasn't in place yet, I created a scripting solution leveraging Windows Management Instrumentation (WMI) that took hardware and software inventory on the clients and saved the results in an object-oriented database—we called this tool “SMS Light.” Then I created an offline patch-scanning and installation solution that Computacenter colleagues could download to update their clients while not connected to the corporate network. This tool is still maintained and currently supports Windows Vista, Windows XP, and Windows 2003.
How long did it take to develop the migration tool?
How does it work?
The development of the migration toolkit, which consists of a number of files
and scripts, took me about six weeks, including testing. When we started migrating the SMS content, our new SMS 2003 infrastructure was already in place—we had a newly installed and configured site server and distribution-point servers in all our larger branch offices, and AD discovery was configured so that all the domain users, groups, and computers were already in the SMS 2003 database.
First, I decided to use an XML file to store information about the SMS objects, obtained via Windows Management Instrumentation (WMI). To use the WMI namespace on the SMS site server, you
have to connect to the \\root\SMS\site_xxx namespace, where xxx is the site
code of your SMS implementation. You can then use all the available classes to read or manipulate SMS objects. We used VBScript scripts to connect to and manipulate objects in WMI, but you could use any tool that reads or writes to WMI, such as WMI CIM Studio. We used scripts that connect to the WMI namespace on the “old” SMS 2.0 server, connects to the relevant WMI class (for example, SMS_Collection to read information about SMS collections), then reads the relevant data and writes it into the XML file—collections, packages, programs, and advertisements together with attributes such as ID, descriptions, and so on. During the migration, scripts again connect to WMI on the new SMS 2003 server, read the needed information from the XML file, and use WMI generic methods such as SpawnInstance_ to create the new objects. This is where an XML file is handy because you can store the objects with their relationships better than you could with an Excel spreadsheet or something similar.
Then the manual work started. We had to decide which objects we wanted to keep and which could be deleted. The SMS database was filled with objects that were necessary in the past but were no longer needed; they just hadn’t been deleted after their use. In cases where we were unsure whether objects were needed, we migrated them to the new system. Additionally, little things such as “descriptions” or “comments” on the SMS objects were poorly maintained. Because some of this information is displayed to the user, we wanted relevant text on these attributes instead of blank spaces or meaningless entries. This is actually work that nobody else can take care of—neither a tool nor a consultant. You have to decide by yourself which objects are those you need and which you don’t need. This step wasn’t technically required for the migration, but we wanted to clean up the system.
The script that re-creates the collections on the new SMS 2003 server reads the information from the XML file to do its magic. It writes back the resource ID of the newly created collections into the XML file. After all collections are created, the script restores the original hierarchy of collections.
We actually did some modifications on the collections after we had read the information from the SMS 2.0 server, such as on membership rules. For example, our admins used direct-membership rules most of the time, meaning that users and/or groups were entered as collection members directly. The problem here is that the members are specified using their resource ID, the unique ID that represents an object in the SMS database. When you migrate as we did, these resource IDs will all change in the new SMS 2003 database, so that the old collection membership rules will be unusable. We scanned through the XML file to change all direct-membership rules to query-based rules, so that the membership is independent of any SMS 2.0 specific information. I want to stress that this was an important step and also one of the reasons why no commercial SMS [2.0 to 2003] migration tool is available. If you don’t change the direct-membership rules of the SMS collections, you can re-create them on the new system, but the actual members of the collection are unpredictable.
We used another script to export all packages and advertisements into Managed Object Format (MOF) files. MOF files are text files, so you can manipulate them and recompile them on the new SMS 2003 server to create these objects. When exporting packages and advertisements, we had to change some of the attributes that are specific to the old SMS site. For example, we had to out-comment the package ID (this is specific to the old SMS site and will be re-created on the SMS 2003 server).
We then used a script that leverages mofcomp.exe, the MOF compiler, on the new SMS 2003 site to add the packages into SMS. This script writes back the new package ID into the XML file. We had to update the advertisement MOF files with the new collection ID and package ID, information already stored in the XML file. After the script updated the MOF files, we again used mofcomp.exe to add the advertisements to SMS and wrote back the new advertisement ID into the XML file.
So far, the packages were created but not available on any of the new distribution-point servers. We created a script to distribute packages, in several flavors: It could distribute all packages to a given distribution point, just single ones to all distribution points, or single packages to a single distribution point server. And, as one of the last steps, we had to change the download behavior of the advertisements so that clients remote to the distribution point would download and run the program. (The default setting is that SMS clients remote to the distribution point don’t run the program at all.)
These steps describe the migration tool set in general—there were other
necessary steps that dive deeper into the SMS nuts and bolts. The entire migration
requires you to perform one step after the other in the right order—for
example, you have to create the packages first, then change the advertisement
MOF files with the new package ID before you can create the advertisements.
How long did the migration take?
The migration took only about an hour in production! We tested the tool set several times in our lab, so we were pretty sure the migration would run smoothly. The script execution was pretty fast, and most of the time was needed to distribute the packages to the new distribution-point servers. Without the migration tool set, our administrators would have had to create all the SMS objects manually—with more than 1,000 objects, this would have been a long and error-prone process.
Are you planning to migrate to the next version of SMS,
System Center Configuration Manager 2007?
Yes, we're currently evaluating Configuration Manager 2007. When performing
an upgrade, we want to do an in-place upgrade and hopefully won't need to use
the migration tool set. However, although I haven't tested it, I assume my tool
set can be used with Configuration Manager 2007 because the WMI classes are
still the same.
See Associated Figure
End of Article
Register
