Where do I start?
Administering SMS often involves performing repetitive tasks via the SMS Administrator GUI. How many times have you wished there was an easier way? There is, using the interfaces to SMS that Microsoft has provided. Nearly anything you can do via the SMS Administrator can be done via a script.
But where do you start? When I first started working with SMS 2.0 (back with beta 1), I asked myself that same question. According to Microsoft, all the information you need is included in the SMS section of the Platform SDK - it is the official reference to programming SMS. Granted, the Platform SDK is a great, essential reference, but it is not a step-by-step how-to guide.
So where do you start? First you have to understand the architecture. SMS 2.0 does not really have an API in the traditional sense - you won't find a list of API calls to perform each distinct task. Instead, the interface to SMS is provided via WMI, Windows Management Instrumentation. This is also documented in the Platform SDK. But again, while the Platform SDK provides a good reference, it is not a how-to-guide. Fortunately, there are some good resources available:
- The list of resources on the Windows Scripting Resources page at the Windows Scripting Solutions web site, and on other Windows 2000 Magazine-related web sites.
- Books, websites, mailing lists, newsgroups, etc. on WMI, ADSI, WSH, VBScript, and other related technologies. (Have any recommendations? If so, let me know.)
Still no idea where to start? Here's an extremely high-level overview:
Imagine that each node (folder) in the SMS Administrator console (e.g. collections, packages, advertisements) is represented by table (like in SQL Server). Then each item in those nodes would be a record, made up of a set of fields containing all the details for that item. To add a package, you would add a record; to remove a package, you would delete a record. That's not too far from the truth, but some terminology adjustments are needed. Instead of tables, the contents of SMS are exposed through object "classes". Instead of rows, each of these classes contains multiple "instances". Another complication: an instance of a particular class can contain a nested group of instances of another class, creating a hierarchy (something not as easily done with normal databases).
The complete set of class definitions for SMS is called the SMS schema, again documented in the SMS section of the Platform SDK.Prove It: Show Me
Don't take my word for it: use one of the available tools for browsing WMI. Two that are readily available are:
- The WMI Object Browser is part of the Platform SDK. To use this you need to download and install the Platform SDK on Windows NT or Windows 2000 PC (typically a 23MB download), or get an MSDN subscription to receive this on CD. Make sure you install the WMI pieces. You will then find a shortcut under "Programs/Microsoft Platform SDK/WMI" called "WMI Object Browser", which uses Internet Explorer along with some custom ActiveX controls to browse WMI.
- The WBEMTEST utility should be installed on every Windows NT and Windows 2000 SMS client machine. It can typically be found in the "WINNT\SYSTEM32\WBEM" directory. While not very fancy, this utility proves very useful when developing SMS scripts.
To use either of these tools, you first need to connect to SMS. The WMI Object Browser will automatically prompt for connection information. With WBEMTEST, you must click the "Connect" button. In both cases, you need to enter the "WMI namespace path" to your SMS server. What's a namespace path, you say? It is similar to a UNC path, but instead of referencing directories it references a location within the overall WMI schema (which is hierarchically structured, similar to the registry). In the case of SMS, this path will look something like this:
where "SERVER" should be replaced by your site server's name and "XXX" should be replaced by the site code for that server. Notice that both the WMI Object Browser and WBEMTEST allow you to specify a different user ID and password for making the connection. The SMS Administrator (which connects via WMI in a very similar manner) could do the same thing - it just doesn't implement that option.
After the connection is established, you can see a list of classes that are defined. The WMI Object Browser will automatically show this list. To get an equivalent list from WBEMTEST, click the "Enum Classes" button, then click the "Recursive" item (leaving the "superclass" field blank), then click "OK". In the displayed list, select the appropriate class (e.g. "SMS_Package"). In the WMI Object Browser, find it in the "Available Classes" list then click "Add->" and "OK". With WBEMTEST, double-click on the class name, which will show the class definition, then click the "Instances" button to see the actual object instances. Double-click on one of the instances to see its properties.Do I Have to be a Programmer?
Admittedly, this looks pretty bad so far, but with some script examples this should be much more obvious. Wouldn't you expect Microsoft to provide these examples? They do, as part of the Platform SDK. Those provided for general-purpose WMI tasks are very useful: they are simple and easy to follow. Unfortunately, this isn't the case for many of the SMS examples: they are either written in C++ (which only a Real Programmer would like), or are too complex to really decipher. In upcoming articles, I'll turn these into case studies, converting at least a few of them into the equivalent VBScripts.
In the nearer future, we'll concentrate on the basics:
- How do I connect to SMS? Definitely an essential task.
- How do I write WMI queries to retrieve SMS information?
From there, the next steps are more interesting: modifying SMS by adding, deleting, or updating instances.Suggestions?
Do you find this article useful? If so, please use the rating box below to let me know. I need to know whether the effort put into these articles is worth the time, as there are only so many hours in the day.