Microsoft Systems Management Server 2003 : Queries (part 1) - Query Elements

As you know, the premise behind any database query is the return of information based on a set of criteria. In other words, you define what information you’re trying to obtain in the form of a query statement. The query engine then searches the database for entries that match your criteria. The query result then displays the data that matched your criteria.

The same is true for SMS queries. To define a simple SMS query, you would specify an SMS object to search on, one or more attributes of the object, an operator of some kind, and a value. For example, suppose you’re querying for computers with processors greater than 700 MHz. In this case, computer is an object, processor is an attribute of the object, greater than is the relational operator, and 700 MHz is the value.

You can use SMS queries for a variety of purposes. Generally, we think of queries as a means of reporting on data in the database. Indeed, we might use SMS queries to find all the computers that meet a certain memory, disk space, and platform requirement before sending out a package to them. And as we’ve seen, queries are particularly useful in defining collection memberships. Collections whose members are based on the results of a query can be updated periodically to keep them current. Any programs advertised to a collection are automatically made available to the collection’s members. As the query runs and updates the collection, new members automatically receive any advertisements that targeted the collection, and deleted members no longer receive the advertisements.

You can generate SMS queries a couple of ways. The easiest way to create and run a query—and the easiest method to learn—is using SMS Query Builder, which is built into the SMS Administrator Console. This interface provides you with a point-and-click method for building your query. You could also write the query statements yourself; however, this method entails learning a query language—specifically, WMI Query Language (WQL).

Unlike other SQL Server databases, SMS relies on the Windows Management Instrumentation (WMI) layer to expose its database information to the SMS Administrator Console and other tools. Therefore, you can’t use regular SQL queries or commands to extract data from the SMS database. Instead, you’re specifying WMI object classes and attributes that the query uses to access and search the SMS database. For example, most of the queries that you create and use for collection membership will likely be based on the SMS_R_System discovery class, which contains discovery record properties such as IP Address, OperatingSystemNameandVersion, and Name, and on the SMS_G_System set of inventory classes, such as SMS_G_System_Processor, which includes processor data such as Name and ResourceId, and SMS_G_System_x86_PC_Memory, which includes memory data such as TotalPhysicalMemory.

Consequently, it’s not recommended that you access the SMS database using regular SQL queries. What you need is a tool that can connect to WMI to access the SMS Provider and collect the information you require. You can use any third-party utility that’s WMI Open Database Connectivity (ODBC)–compliant for this purpose. For example, you could use a reporting tool such as Microsoft Excel 2002 or Microsoft Access 2002 with the WMI ODBC drivers to report on SMS data. For more information about how to access a SQL database using a third-party tool, refer to the documentation for that tool.

SMS 2003 loads 21 predefined queries, as shown in Figure 1. As you can see, these predefined queries are fairly general in scope and are meant to be more globally oriented, perhaps as the target of an advertisement. However, you can certainly create your own queries—for example, to assist with certain management tasks, including populating and updating collections and viewing client status messages.

Figure 1. Predefined queries in SMS 2003.

Query Elements

Before we review the steps for creating a query, let’s take a look at the individual elements that make up a query. The relationship between these elements is illustrated in Figure 2. As mentioned, you begin your query definition by selecting a WMI object class to query on. However, when you use the SMS Query Builder, these objects use friendly names that make it easier to select the correct object and attribute. We’ll gear our discussion toward these friendly object names.

Figure 2. The relationship between objects, their attribute classes, and the attributes of each class.

SMS provides several object types for generating queries. An object type has specific attribute classes that describe it. For example, the System Resource object type is defined by its memory, environment, logical disk, processor, and network attribute classes, among other elements. An attribute class is essentially a category of attributes and contains an attribute list. For example, the System Resource attribute class includes the IP Addresses, IP Subnets, NetBIOS Name, Operating System Name and Version, and SMS Assigned Sites attributes.

Table 1 lists the more frequently used object types, some of their attribute classes, and a short list of attributes.

The criterion type defines what you’re comparing the attribute with. The six criterion types are listed in Table 2.

Along with the criterion type, you will select a relational operator and supply a value to search for. This value can be null, numeric, a string, or a date/time. The list of relational operators is pretty much what you would expect: Is Equal To, Is Not Equal To, Is Greater Than, Is Less Than, and so on. However, the kinds of operators that are available depend on whether the attribute is null, numeric, string, or date/time. Table 3 outlines the subtle differences between these operators.

(Unit is a date or time unit—millisecond, second, minute, hour, day, week, month, or year.)

When string values are used in a query, the exact string must be provided, without quotation marks, unless the quotation marks are part of the string. If you use either the Is Like or Is Not Like relational operator, you can use wildcard characters as part of the string. Acceptable wildcard characters include those shown in Table 4.

For example, if we wanted to query the database for all SMS clients that contained the string FIN in the client name, we might use the value %FIN%. String operators are not case-sensitive unless the SQL code page you’re using uses case-sensitive comparisons.

In real life, your queries will probably be more complex and will consist of several query statements. These statements are connected using logical operators and are grouped for evaluation using parentheses. The three primary logical operators used with SMS queries are AND, OR, and NOT.

An AND operation finds all data that matches two query statements connected by the AND operator. AND operations generally result in a more restricted search since every expression must be satisfied to generate a result.

An OR operation finds all the data that matches any portion of the two statements connected by the OR. As you might expect, OR operations generally result in a broader search since any expression may be satisfied to generate a result.

A NOT operation finds all the data that doesn’t satisfy the statement preceded by the NOT. For instance, in our sample query we might have wanted to exclude all the computers running a version of Windows earlier than Windows 2000 for upgrade purposes.