Resource discovery and enhanced client agents provide improved capability

Microsoft designed Systems Management Server (SMS) to be a panacea for the problems involved in managing distributed microcomputers. SMS 1.2 was a step in the right direction but not a total solution. (For information about SMS 1.2, see Tim Daniels, "SMS 1.2," May 1997.) Many third-party systems-management products tried to address SMS 1.2's shortcomings. Standalone programs (e.g., high-performance remote-control programs) and packages with built-in software metering became popular. In an effort to offer a full-featured suite of systems-management applications, Microsoft developed SMS 2.0. In this article, I discuss the client features in the release to manufacturing (RTM) version of SMS 2.0.

Resource Discovery
SMS 2.0 stores manageable network devices (e.g., networked computers, routers, bridges, hubs, printers) as resources in its database. Because systems management extends beyond network devices, SMS also collects user accounts and global groups from Windows 2000 (Win2K) Server and Windows NT Server domain controllers. This collection occurs through a process called discovery. Six categories of discovery exist: NT or Novell NetWare logon, user account, user group, network, heartbeat, and SMS server.

Logon discovery. Computers are the primary resource in SMS, and the software uses three types of logon discovery methods to detect computers. Under the SMS Administrator console, these discovery methods are Windows Networking Logon Discovery (logon to an NT Server domain controller), NetWare Bindery Logon Discovery (logon to a NetWare bindery server), and NetWare NDS Logon Discovery (logon to NetWare Directory Services—NDS).

User account discovery. User account discovery doesn't require a client computer logon. This discovery method enumerates domain user accounts in the SAM database on Win2K Server and NT Server domain controllers. It doesn't discover user accounts on Win2K Server and NT Server non-domain controllers, other domain controllers such as LAN Server or LAN Manager servers, or NetWare servers.

User group discovery. Like user account discovery, user group discovery doesn't require a client computer logon. User group discovery finds global (but not local) groups in the domains you specify in the SMS Administrator console. As in user account discovery, this method discovers groups only on Win2K Server and NT Server domain controllers.

Network discovery. Network discovery finds networks (e.g., TCP/IP subnets, IPX networks), SNMP-enabled devices, computers reporting to DHCP servers, computers broadcasting their presence through NT's Browser service, and computers broadcasting shares (running the server service) on the network. Network discovery doesn't require network logon to discover computer resources or domain membership. You can configure this discovery method to collect all information or just a subset. For example, if you're also using logon discovery, you might not need to configure network discovery to find computer resources.

Heartbeat discovery. Heartbeat discovery updates data you've previously collected about network computer resources. After you make a computer a client (which I discuss later), heartbeat discovery communicates with inventory client agents on the computer to update the SMS resource database. This discovery method is most useful for computers that rarely log on to the network, such as email servers or print servers. If you don't enable heartbeat discovery, automated database maintenance routines will remove discovered computer resources that don't log on to the network regularly. Therefore, you need to enable this discovery method if you're running computers that log on infrequently.

SMS server discovery. SMS server discovery finds computers that are functioning as SMS site systems. (A site system is a Win2K, NT, or NetWare server that provides services to SMS.) SMS uses three methods of SMS server discovery to find Win2K, NT, and NetWare server site systems: NT SMS server discovery finds Win2K and NT site systems, NetWare Bindery SMS server discovery finds NetWare bindery site systems, and NetWare NDS SMS server discovery finds NetWare NDS site systems. You can't configure this discovery method.

Resource Management
Some discovery methods SMS uses to find network resources overlap in function. For example, you can discover a computer through either logon discovery or network discovery. To avoid duplicate resource entries in the database, SMS uses key characteristics of the discovered resource, such as the IP address, to create one entry that appears in the SMS Administrator console. SMS classifies discovered resources by attribute. This grouping lets you manage resources by characteristic. For instance, a DOS computer can be a resource in the SMS database. However, an SMS 2.0 client agent isn't available for DOS. Thus, based on the computer's OS attribute, you can't install SMS client agents on the resource.

Client Agents
SMS 2.0 includes client agents for 16-bit Windows client computers (i.e., Windows 3.1, Windows 3.11, and Windows for Workgroups—WFW) and 32-bit Windows client computers (i.e., Win2K, NT 4.0, NT 3.51 running Service Pack 5—SP5, and Windows 9x). SMS 2.0 client agents aren't available for OS/2, DOS, or Macintosh computers. If you need to provide client computer support for these types of computers, you can make an SMS 1.2 site server a child in an SMS 2.0 site hierarchy. The SMS 2.0 database will gather inventory information from the SMS 1.2 site, but you need to run most SMS 1.2 client management tasks from the SMS 1.2 Administrator tool.

Resource discovery doesn't exist in SMS 1.2. The only way computers become part of an SMS 1.2 system is through hardware inventory, which typically occurs when a user logs on to the network. Because of how SMS 2.0 makes computers and other network resources part of the system, SMS 2.0 is more powerful than SMS 1.2. SMS 2.0 collects far more information from a wider variety of network devices and objects (e.g., domain user accounts).

SMS 2.0 uses the term client computer to define all computer resources in the SMS system that run the SMS client core component and the individual client agents. SMS 2.0 client agents include Advertised Programs (which supports software distribution), Remote Tools (which supports remote-control and realtime diagnostic functions), Hardware Inventory, Software Inventory, Software Metering (which tracks and controls software usage—a new feature in SMS 2.0), and Event to Trap Translator (which converts Win2K and NT events into SNMP traps). In SMS 1.2, a computer must run at least the Hardware Inventory agent to be part of the site. In SMS 2.0, a computer's network must be in the SMS site's boundary for the computer to be part of the site. Site assignments in SMS 2.0 are based on IP subnet or IPX network address.

Defining site boundaries based on network segments aligns well with Win2K's Active Directory (AD). In SMS 1.2, a site boundary is based on security, administration, and client computer function. In SMS 2.0, a site boundary is usually based on network performance. That is, SMS 2.0 sites are groups of resources with fast, reliable network access to the site server. A site server automatically assigns resources on its network to the site. You can also configure other networks to be part of the site; this function is called assigning resource boundaries.

Both 16-bit and 32-bit Windows client computers support client agents. In addition, 32-bit client computers support the Windows Management service whose foundation is in Web-Based Enterprise Management. WBEM is an enterprise-management standard that several companies (i.e., Microsoft, BMC Software, Cisco Systems, Compaq, and Intel) created and support. The Desktop Management Task Force (DMTF) controls WBEM standards. For more information about WBEM, see Greg Todd, "What Is WBEM?" July 1998. To see a presentation about Microsoft's WBEM initiatives, go to http://www.microsoft.com/hwdev/presents/winhec98/ winhec16a/tsld001.htm.

The Windows Management service, which is Microsoft's implementation of WBEM on 32-bit Windows client computers, enables extended local-inventory data processing, so the server receives only Hardware Inventory and Software Inventory changes. SMS 2.0's client agents are less intrusive than SMS 1.2's agents are, and they enable faster network logons. On a 32-bit Windows computer, the Advertised Programs wizard is in Control Panel and doesn't appear unless SMS 2.0 is advertising software that is ready for installation on the client computer.

All computers can become client computers in SMS 2.0 through logon to a Windows or NetWare network. Win2K and NT computers also support background client installation via a method called the Windows NT Remote Client Installation; this installation method doesn't require a network logon. Finally, users can manually run the client installation process (smsman.exe) to become SMS 2.0 client computers before the software discovers them as resources.

Advertised Programs. The Advertised Programs client agent informs users when you target files or software installations for their client computer. SMS 2.0 creates a package (i.e., files to install) and a program (i.e., the installation routine). Then, the software uses an advertisement to distribute the package and program to collections of client computers in the site hierarchy.

A collection is a group of resources in the SMS site that meet specific criteria you define, such as computers running Win98. An important difference between an SMS 1.2 software-distribution job and an SMS 2.0 collection of client computers is that a collection can be dynamic. If you add a client computer that meets the site's collection criteria, SMS automatically adds the client computer to the collection and targets the computer for advertisements that you've previously defined for that collection. You don't need to recreate the job, as in SMS 1.2, to keep client computers updated with software. You can also add a user or group to a collection. Then, when the user whose account is part of the collection logs on to a client computer, software installs on the computer.

SMS 2.0's distribution function can refresh existing software distributions based on a schedule you configure in the SMS Administrator console. In addition, programs can be dependent on other programs. This feature lets you control the order in which SMS installs programs on client computers. SMS 2.0 includes SMS Installer, which lets you build automated installation scripts for your applications. (For information about SMS Installer for SMS 1.2, see Michael D. Reilly, "SMS Installer," April 1999.)

In SMS 1.2, NT client computers can use the Package Command Manager (PCM) service to install packages in the background. Microsoft added this service after SMS 1.2's release; thus, you must install the service separately from the software's main client computer installation. SMS 2.0 also supports background package installation on Win2K and NT client computers running the Advertised Programs client agent.

Remote Tools. The Remote Tools client agent provides realtime access to SMS 2.0 client computers. Realtime support includes remote control, file transfer, remote diagnostics, remote reboot, remote execute, and chat. Screen 1 shows a remote-control session, and Screen 2 shows a file transfer session.

SMS 2.0's Remote Tools client agent is similar to SMS's 1.2's Help Desk utility. However, SMS 2.0 solves several problems that forced many SMS 1.2 administrators to seek other realtime access solutions. For example, SMS 1.2 provides little information when a connection attempt fails. In SMS 2.0, a Remote Tools session with a client computer initiates through the SMS Administrator console. When SMS tries to connect to the client computer, a status window such as the one in Screen 3, page 132, shows the results of the attempt. This information lets you troubleshoot failed connections.

Another problem with SMS 1.2 is a lack of sitewide control over the Help Desk function. In SMS 1.2, the user at the client computer chooses the level of realtime access. Thus, users can select the Permissions Required setting to prevent access (even by administrators) to their unattended client computers. In SMS 2.0, the administrator controls whether a user can change the Remote Tools client agent settings.

Other sitewide controls include limiting the Remote Tools features; for example, you can enable remote control but not remote reboot. You can also control whether a user is visibly or audibly aware of a Remote Tools session. Unless you enable user notification, users aren't aware of Remote Tools sessions that are running.

The Remote Tools client agent enhances performance and expands the protocols you can use. You can control the type of compression that occurs during realtime client computer access—Run Length Encoding (RLE) compression, which compresses screen data by 40 percent, or Lempel-Ziv-Welch (LZW) compression, which provides even better data compression. Only client computers with CPUs faster than 100MHz can effectively use LZW compression. You can configure the Remote Tools client agent to automatically select the best compression setting based on the client computer's CPU. The client agent supports Win2K and NT accelerated screen transfer. SMS 2.0 offers NetBIOS support over all protocols, native IPX support, and Winsock support for TCP/IP.

Hardware Inventory. The SMS 1.2 Hardware Inventory client agent supports a wider variety of client OSs (i.e., NT, Win98, Win95, Windows 3.11, Windows 3.1, WFW, DOS, OS/2, and Mac) than the SMS 2.0 Hardware Inventory client agent supports. In addition, an SMS 1.2 site server can report the inventory it collects to an SMS 2.0 site server. However, you'll want to use the SMS 2.0 Hardware Inventory client agent in environments in which client OS support intersects 16- and 32-bit OSs, because the 32-bit Windows agent collects more hardware information than the SMS 1.2 Hardware Inventory client agent collects.

The SMS 2.0 Hardware Inventory client agent collects classes of data that the sms_def.mof text file defines. You can use SMS 2.0's MOF Manager or a text editor to modify the sms_def.mof file and collect additional hardware inventory data. You can also create IDMIF or NOIDMIF files to add custom hardware inventory data to the SMS database. IDMIF and NOIDMIF files are Management Information Format (MIF) files whose format complies with DMTF standards. For more information about MIF files, see the SMS 1.2 or 2.0 documentation, or see Mark Eddins and Greg Sternig, "Systems Management Server Customization and Integration," March 1998 and Mark Eddins, "Customizing Systems Management Server," January 1997. SMS 1.2 also uses IDMIF and NOIDMIF files to extend inventory data collection. You can run hardware inventory collection on a simple recurring schedule (e.g., monthly) or at specific times on a recurring schedule (e.g., monthly starting at 8:00 a.m. on May 2, 1999).

The 16-bit Hardware Inventory client agent collects inventory data in a binary file (*.raw) that the site server converts to a MIF file for processing. The 16-bit client agent can collect only a subset of the hardware inventory data that the sms_def.mof file defines. Therefore, when you view hardware inventory data in the SMS Administrator console, you'll see less information in a 16-bit client computer's hardware inventory than in a 32-bit client computer's hardware inventory.

The 32-bit Hardware Inventory client agent runs in the background and interfaces directly with the local WBEM repository. This enhancement lets the Hardware Inventory client agent process more information locally than the 16-bit Hardware Inventory client agent can process. For example, when the computer's configuration changes, the Hardware Inventory client agent sends only the changes rather than the entire hardware inventory to the site server. Background processing lets you use the computer while inventory processing runs. You might be aware of inventory processing when the agent accesses your hard disk and you notice increased disk I/O.

SMS's Resource Explorer lets you view the hardware inventory. You access the Resource Explorer from the SMS Administrator console. The inventory displays in a treeview, as the left pane in Screen 4 shows. When you select an object in the left pane, the object's details open in a window in the right pane.

Software Inventory. In SMS 1.2, the Software Inventory client agent collects information only about files that you specify in the SMS Administrator. You must provide at least the filename so the agent can look for the file. SMS 1.2 also includes a primitive software-auditing feature that lets you include a list of files to identify on the client computer, but this feature is tedious to configure and can significantly increase SMS client logon time. In contrast, SMS 2.0's Software Inventory client agent collects information about files based on their prefix. For example, the agent uses the name winword to identify Microsoft Word files. By default, SMS collects software inventory for all files with .exe extensions. Then, the Software Inventory client agent correctly identifies software by reading file header information even if a user has renamed the file's prefix. Because the agent runs in the background, you don't have to wait for the software inventory to complete before the logon process completes. SMS's software inventory scheduling features are identical to its hardware inventory scheduling features.

As in SMS 1.2, you can collect files from the client computer. The site server then stores the collected files for viewing. Unlike in SMS 1.2, you can control the maximum size of collected file data per client computer. This control is important, because you must know how much storage space you need for the files.

To optimize software inventory and file collection, the Software Inventory client agent passes only changes to the site server. This method reduces the network and site server's loads for processing incoming inventory. In addition, an SMS 1.2 Software Inventory client agent can report data to an SMS 2.0 site server if you make the SMS 1.2 site server a child in the SMS 2.0 site hierarchy.

You can view software inventory through the Resource Explorer. SMS 2.0 classifies software by manufacturer and title. The left pane in Screen 5 shows the Resource Explorer's manufacturer tree. The window in the right pane shows the software properties of the object you select in the left pane.

The Resource Explorer provides a powerful method for accessing inventory data on client computers in a site. To view collected file properties and contents, access CollectedFiles in the Resource Explorer tree. To view files that SMS can't identify, access UnknownFiles. To determine when the Software Inventory client agent performed the most recent software scan on a client computer, access LastSoftwareScan.

SMS 2.0 includes Seagate Software's Crystal Info (formerly Crystal Reports). After you install Crystal Info, you can use the software to access summary inventory data about all the client computers in your site. To design and access summary inventory reports, you use the SMS Administrator console's Reports folder, which Screen 6 shows.

You can use Crystal Info to display reports on information in the SMS database, regardless of whether the inventory agents provided the data. For example, you can determine the status of packages you advertised through the software-distribution mechanism. In addition, Crystal Info includes a product-compliance report that you can use to determine the Year 2000 (Y2K)-compliance level of products in your site. The SMS database includes a list of Microsoft products and their compliance levels. You can add products to the compliance database and define their compliance levels. SMS contains predefined Y2K-compliance queries that Crystal Info can use or that you can use to build collections. Then, you can use collections to distribute software updates to client computers running noncompliant software.

Software Metering. SMS 2.0's Software Metering client agent runs on a client computer and reports software activity to the SMS License Server service to control or simply monitor software usage. (The SMS License Server service isn't related to the NT License Logging service.) You define settings in the metering database to configure this client agent. Unlike SMS 2.0's other client agents, Software Metering runs only on 32-bit Windows OSs (i.e., Win2K, NT, and Win9x).

SMS Software Metering supports callback queuing. If a user attempts to run software that the maximum number of client computers are already using, the Software Metering client agent places the request to use the software in a queue. When the software becomes available, the agent notifies the user. This feature is optional and requires extra processing on the site system running the License Server service.

Mobile computing users can take advantage of SMS Software Metering by checking out software before disconnecting from the network. The software license then belongs to the mobile user until a particular amount of time passes (which you can configure) or the user checks the software back in. This system also supports license balancing if you have multiple SMS License Server site systems. Screen 7 illustrates use of the SMS Software Metering program to configure a product for licensing.

Event to Trap Translator. The Event to Trap Translator client agent converts Win2K and NT events that you specify in SMS into SNMP traps. You can then forward these traps to a network-management system that provides SNMP-based network monitoring and analysis. In this way, SMS can augment the data that a network-management system such as HP OpenView receives.

No Stones Unturned
Microsoft was thorough in updating SMS. Three additional improvements are Network Monitor, Network Trace, and Health Monitor.

SMS's improved Network Monitor includes the Monitor Control tool, which you use to continually monitor your network for unauthorized access or significant network events (e.g., an IP router failure). You can then use Network Monitor Experts to analyze the packets you capture, and you can determine, for example, the average server response time for servers on a network segment. You can also use Network Monitor to monitor network traffic on remote segments.

SMS's new Network Trace utility helps you determine whether your site servers and other SMS site systems are operational. You use this feature to create a site view of your network and the SMS site systems connected to it.

Health Monitor provides a Microsoft Management Console (MMC) snap-in for centralized monitoring of Win2K and NT client computers running the Health Monitor client agent. Health Monitor can monitor hardware and Microsoft BackOffice activity.

SMS 2.0 fixes many of the problems that turned network administrators away from SMS as a systems-management solution. Resource discovery extends SMS's reach, and enhanced client agents provide improved capability. If you're already using SMS 1.2, SMS 2.0's ability to work with the previous version makes migration smooth. SMS 2.0 has been a long time coming, but it's worth the wait.