Microsoft Systems Management Server (SMS) is a big topic. I discussed its basics and talked about strategies and implementation principles that you could use with it in Part 1 in the October issue of Windows NT Magazine. Now, let's talk about the capabilities of SMS, how you can use it, and what you can expect if you implement it for your enterprise.
The ability to register hardware across your network may be justification enough for purchasing SMS. With it, the administrator can automatically inventory hardware and operating system software (see Screen 1) based on each user's preferred configuration and collect it automatically, at regular time intervals, or at logon. SMS can locate and collect information on the specific hardware drivers located on a particular workstation by creating a query, packaging it, and scheduling it. SMS supports these types of inventory registration on MS-DOS, Windows and Windows for Workgroups (WFW), Windows NT, OS/2, and Macintosh clients.
You can also inventory or audit software across the network, but it's not nearly so automatic. The administrator must use queries and packages to collect specific data about software installed on client machines. Although software-tracking tools are available within SMS, you should consider how appropriate it is to use them. Administrators should gather only the information they need and not fill their databases with unnecessary client-software tracking data. The mechanism and tools for collecting this information for every program on every workstation are available, but the optimal implementation only inquires about needed data.
Another key feature of SMS is its ability to distribute updates to drivers or fixes to applications; this capability makes distributed workstation management a reality. One of SMS's key advantages over other software installation products is its querying ability (see Screen 2). For example, you can "test" an operating-system version level to determine whether a particular fix has been applied to a client machine before distributing a fix for a defective executable. (You should run individual queries manually before packaging them; you can also concatenate complicated query "test" procedures for software distribution.)
You can use this feature to distribute full software installations, as well as updates and patches (see Screen 3). SMS enables you to install software using packages (wrappers bundled around a normal setup or install procedure), which can be located in a source directory anywhere on the network. An install procedure could copy files to a user's hard drive, run local setup programs, create shared network installations, and add program items and groups to the Program Manager. SMS also enables you to use a batch file for these purposes, and it has lots of scheduling options--defined when the job is created--for delivering software packages. For example, a package could be scheduled for either optional or mandatory delivery to workstations at night or at some other convenient time.
If you use the distribution feature, you're likely to find the Program Definition Files (PDFs) very useful (see Screen 4). PDFs are templates, similar to the INF files of Windows applications, that help you create custom packages to install software quickly. You can edit these files, if you wish, to customize them further. The documentation for the distribution feature includes information on all but one of these mechanisms: The generation of batch files to customize and automate software installation is barely mentioned.
Help Desk Support and Remote Control
SMS can help hardware technicians to troubleshoot hardware conflicts. It enables you to take a hardware inventory, catalog hardware driver versions, and perform tasks via remote control. Taking control of the user's keyboard, mouse, and monitor over the network can dramatically decrease the time and cost required to determine the cause of hardware problems; it can also reduce the amount of user downtime. The real-time memory-allocation maps for DOS and Windows applications are especially useful. And you can access information on hooked interrupt vectors and more.
SMS's remote-control features can provide the core of your Help desk support (see Screen 5). In addition to gathering historical hardware and software information, you can test real-time workstation object allocation to levels as deep as Windows memory usage via hooked interrupt vectors. You can take control of the user's desktop over the network and, for example, walk that user through the process of using a new Excel macro to help generate a monthly report. All the while, the user is watching the process, perhaps listening over the phone. Help desk calls can be resolved more quickly if you can reproduce the users' problems right in front of them on their own PCs.
Probably the most significant and under-marketed feature of SMS is its Network Analyzer (see Screen 6). This protocol analyzer is as full-featured as any you've ever used. And it's integrated with the NT Performance Monitor, providing an easy-to-use tool that can quickly track down network problems without additional hardware. SMS is not a physical network-management product, but it does contain that type of functionality.
Large companies have the means to perform traditional network-management tasks from a central site to the ends of their WAN circuits. Smaller companies often do not. However, if you already have a network that has protocol analyzers or if you work with a communications group that does, I'd recommend that you use the SMS Network Analyzer as well. Its ease of use, integration with NT, and distributed software may provide benefits, even over more traditional network-analysis tools.
You need to be aware of what level of performance is acceptable to both the administrator of the SMS system and its users. For example, if Microsoft SQL Server is already a managed part of your network services, then your system has probably been tuned to perform well for SMS. If SQL Server is newly installed, you will probably need to adjust some things--memory, in particular. In the SQL Server setup, the default memory allocation is 6MB. Increasing this value will dramatically increase the number of transactions per second that SQL Server can process. Depending on the installation and the number of transactions expected, 40MB may turn out to be more reasonable.
The NT Performance Monitor tool can help you to see how effectively your SQL database engine is performing. For example, if you monitor the SQL Server counters during transactions as you allocate memory to the SQL Server process, you can see how tightly NT and the server services, such as SQL Server and SMS, are integrated. You might also consider using SQL Server indexes to speed up database performance. If certain fields are queried on a regular basis, you can index them to improve performance.
Enterprise Management and Fault Tolerance
To help keep your system up and productive, you can store the location information about distribution-server packages in two different files on two different servers. Thus, if one server is not available, client systems can connect to the other to install software packages. However, you should clean things up after the software has been distributed; you can recover vast amounts of disk space.
Cleaning up involves deleting the package source directory and deleting the package's location from its workstation properties; you must delete the transmission packages manually. Once a job has been activated and SMS Executive has created the transmission package, the package source file is no longer needed. You can delete it also.
Issues of Concern
With SMS release 1.0, you face several issues that might make implementation more difficult, depending on the features used. Some of these issues are handled in SMS 1.1 (see the sidebar "Dealing with the Issues").
- DHCP/WINS with SMS: One problem Microsoft seems to be ignoring is how to use SMS in an NT network where TCP/IP addresses are served by Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name System (WINS). If a WFW workstation with a leased address is registered in the hardware inventory database and a new address is leased for it, the address in the inventory is not corrected. Not only that, but remote control won't work on that workstation either. Microsoft encourages enterprise-wide integration of server products but develops and ships two key server technologies that don't work together. It doesn't make sense. Acknowledgment of the issue by Microsoft with an explanation, limitations, and a workaround would be good.
- One machine appearing more than once: There also seems to be a bug allowing one machine to show up two or more times in the inventory. The SMS ID may be different on each occurrence but all the other information is the same, including the machine name and the adapter address. It's impossible to figure out what's wrong because there's no documentation on the logic involved in keying, identifying, or updating the hardware for the inventory.
- Why NOT? The first question many administrators want answered is what NOT is on a client machine. Unfortunately, the NOT operator is missing from query operations.
- How big is this server? The amount of space you allocate for the database is a consideration. SMS querying uses the SMS SQL database for temporary storage, so the amount of space required will depend on the number and size of the queries run against the database. If you're using SMS to distribute and install software on machines across a number of sites, you must plan for adequate disk space and for the location of that disk space. The source file for the software package may be located on a number of servers across the enterprise. As distribution and installation continue, versions of the package will exist in multiple disk locations. In addition, there will be a transmission package, a de-spooler location, a distribution server, and, finally, the package on the target machine. But the files are compressed, and depending on the compression used for the software installation components, the transmission package--a single compressed file composed of all source components--may be half the size of the source files. The distribution server holds a decompressed image of the package as it existed at the source location.
- Documentation: The documentation is not as good as it could be for a product as complex as SMS. Areas that need explanation range from using batch files for package delivery to planning and architectural considerations. I've had a hard time finding specific functions that SMS could not perform, but I've done so without any clues from the documentation. Most large enterprises will struggle with support and maintenance problems until Microsoft provides more complete documentation for SMS and places the emphasis on proper planning procedures.
No Big Deal
- MIBs vs. MIFs: Systems people who have learned to understand and utilize Simple Network Management Protocol (SNMP) message information blocks (MIBs) are unhappy with the advent of the Desktop Management Task Force's (DMTF's) management information files (MIFs) as a conflicting specification. However, the two specs can be seen as complementary, since MIFs do not need to replace the functions that MIBs serve. Rather, they more easily fill a void in MIBs. Information generated in a MIF format is self-describing. There is enough information in a MIF to understand the name, type, and grouping characteristics of the data without any external databases. No coordination of object names, types, and tables is required between the MIF generation and the person who writes the management product. The structure of a MIF is based upon the component, group, and attribute model.
- Reports: SMS allows you to store an overwhelming amount of data. An issue that many people raise is that SMS doesn't provide reports for that data. Microsoft has left the reporting to tools better suited to the task. (Microsoft Access is a good choice for understanding and presenting the data collected via SMS.) However, Microsoft does provide a utility to create database views (SMSVIEW.EXE) for easy analysis.
- Again, how big is this server? Considering the overall benefits provided by SMS, size should not be an issue for most installations. Microsoft is right not to be apologetic for the scaleability and price/performance of NT and its integrated server products.
The Shadow Knows
SMS isn't going to hide in the shadows forever. As Microsoft moves to a more tightly integrated operating environment, the importance of distributed support for software and hardware control will continue to increase.
This new level of distributed client/ server computing requires an application capable of bringing together all the aspects of an enterprise network, from network performance analysis to software installation and remote control. SMS offers it all in one package. With proper planning, a deployment of SMS can increase productivity for both your users and your administrators.
|Microsoft Systems Management Server 1.0|
|Requirements: SQL Server 4.21, 66-MHz 486, 32MB RAM, 100MB disk space, Network Adapter|
|Contact: Microsoft * 206-882-8080|