Microsoft Systems Management Server: A Well-Kept Secret
Microsoft Systems Management Server (SMS) has been shipping since fall of 1994, yet surprisingly few people realize the significance of this product. SMS is beneficial for network resource management in small and large environments, departmental and enterprise-wide installations, and development shops and user communities.
Plan, Plan, and Plan Some More
Due to the broad scope and complexity of SMS, there are no easy rules or guidelines published to use to plan for and maintain your implementation. However, it's been proven time and again that any major project rollout in an enterprise benefits most from using a development discipline or a set of clear time-scheduled events based on objectives and milestones. This is the mindset that administrators and managers need to have when deciding on a course of action for SMS. Its implementation is no less complicated than any other in-house development project.
Consider the following fictional scenario, where a systems team is attempting to start SMS without the proper planning and user education:
An inexperienced, minicomputer systems administrator (SA) obtains a box of shrink-wrapped software called Microsoft BackOffice from the project manager. Assuming that manuals are most effectively used for reference, the SA leaves them wrapped up, but tears open the CD package. After a day of PC hardware adjustments, trial and error (". . . name? What name? The server name? . . ."), the SA manages to load Windows NT Server onto the new PC hardware delivered yesterday, also by the project manager.
What's next? A CD directory labeled SMS. After a few hours of accepting default choices, entering uncertain answers to the installer's questions, following on-screen pop-up instructions related to loading additional required software called Microsoft SQL Server (also on the CD), and adding an NT user account, the SA finally has SMS installed and running.
Now, job complete, the SA is off for three days of vacation with a sense of major accomplishment. Meanwhile, the project manager deals with 182 phone calls from users who think that every machine on the network has been invaded by a virus, because nothing works anymore.
The moral of the story is, BackOffice in general--and SMS in particular--is not PC or personal use software. It is a set of server-based services and tools that enable the deployment and management of true client/server systems across an enterprise LAN or a WAN. It has also been called an exercise in distributed client/server systems. BackOffice includes the Windows NT Server operating system, SQL Server database, SNA Server for connection and integration with IBM SNA environments, and SMS. Never in the history of client/server systems has there been a more comprehensive foundation for running your business. But SMS requires a great deal of planning.
Administrators and IS managers know that a major issue in managing distributed PCs is the frequently unacknowledged cost of supporting them. Nearly two-thirds of the cost of PCs is related to end-user technical support, software installation, and hardware configuration management. SMS can help to alleviate many of these costs, but even so, plans to customize, integrate, and deal with the political implications of taking back what has been lost with the advent of distributed computing--such as centralized management--should be worked out in advance.
A planned pilot program is the key to success in implementing SMS. The pilot should consist of one or two specific features that will prove beneficial to your organization; you can expand from there. For example, you should ask the following questions: What is our prime motive for moving to SMS? Will a report on hardware assets be significant to my CEO? Will the ability to remotely control a client workstation for user education on the new Excel macros in our order-entry process boost the productivity of our Help desk technicians?
Our fictional project manager's motive was to start a forward wave of computer technology in the company, with rapid application development and higher user productivity. This might be your motive, too; you may be focused on increasing application performance and improving the availability of business-critical information.
What's in It for You?
What exactly is SMS, and what's in it for you and your company? SMS is a server product consisting of services to help you manage network objects: processors, disk drives, software, user interfaces (UIs), etc. It is designed to perform on large LANs, possibly connected by many different types and bandwidths of WAN links. SMS enables you to manage distributed systems as if they were local or centrally situated. The product is both broad and complex in its scope. It operates with SQL Server databases, taking advantage of integrated NT Server architecture and features. And like all Microsoft server products, SMS adheres to the Windows look-and-feel UI standards with iconized access to features and tools (see the sidebar "SMS--At a Glance"
). In addition, the product is tightly integrated with NT and takes advantage of its scalability and tools.
Two main features of SMS enable customization at several levels. First, because SMS uses SQL Server, an open, client/server DBMS, other systems can use standard database calls to integrate SMS data. Second, through Microsoft's participation in the Desktop Systems Management Task Force (DMTF) standards committee during the SMS development cycle, the product describes objects in a manner that adheres to the specification for Systems Management Information Files.
How can you leverage these features? It can be frustrating while performing network software and hardware auditing to find that key data is missing from the inventory information that SMS has collected, such as email names, machine asset numbers, etc. However, much of this data can be filled in from management information files (MIFs).
MIFs provide the mechanism for administrators to customize the client information collected at inventory time. It's documented in Appendix G of the Administrator's Guide. However, the MIF generator and the inventory-collection process for MIFs are optimized for use with a separate data-collection tool for user-entered data. You also have the option of adding custom data by joining a new SQL Server table with views from SMS. External data sources can be used with, for example, Access to join views as well.
In addition, the SMS Administrator Tool is an application based on the Win32 API that runs on NT, enabling UI extensions to take advantage of the complete Win32 API set. A Software Developer's Kit is in the works; it documents APIs enabling you to develop custom code. This will be particularly useful for development shops that want to integrate SMS functionality and include value-added features in their software deliverables.
Microsoft professes that the SMS administrator need not be a SQL Server expert. But beware; someone in your organization should be fully trained if you plan to use SMS to its full potential and stay out of trouble! Upon installation, you can get by with most of the default parameters used to install SQL Server. The defaults work effectively for SMS as an evaluation or a small pilot project. But as the database and services grow across your enterprise, SQL Server administration will be required.
Since SQL Server is a database engine, you can locate it on any NT Server machine with full network connectivity. In the long run, that configuration will prove more efficient for several reasons. Database administration can be performed better on a machine dedicated and tuned to SQL services. Such a configuration may also mean maintaining and backing up fewer SQL databases. It allows you to scale specific performance and scalability targets for both the SQL Server processes and the SMS functions needed according to its processing.
SQL Server is not the only expertise you need for SMS. Remember, it all runs on NT Server. Enterprise domain strategy, the security model, and trusted domains all impact how you design the hierarchy of distributed SMSes, with "parent" and "child" sites to perform functions relative to the "central" site (see Figure 1). As in any enterprise system, don't overlook the importance of NT system administration tasks, such as backup and disaster-recovery planning.
To succeed in your enterprise rollout of SMS, you must know the details of local and remote LAN components and all the WAN links to be utilized. A network topology map is critical, as is knowing the bandwidth and saturation of the circuits and what protocols are in use. You'll want to understand which clients access which servers--and when--locally or across the WAN for network resources. Consider the server platforms in use and which servers SMS may utilize (e.g., for software source files). In addition, there may be third-party services you need to integrate, such as Macintosh services, DECNet file services, and NFS for UNIX integration. Fortunately, NT includes support for Simple Network Management Protocol (SNMP) and NetView, allowing integration with OpenView, NetView, PolyCenter NetView, and NMC Vision. You may already be using one or more of these tools for traditional physical-network management.
As distributed client/server systems have blossomed out of mainframe and minicomputer shops, the centralized control of users' desktops and all the applications that they used quickly dissipated and then entirely disappeared. Yet with SMS, we are back to where we can regain full control of the desktops across the corporation. This ability enables SAs to know exactly what hardware and software assets exist on each user's desktop or to take full control of the user's desktop from an administration workstation. It could also mean controlling or correcting users' application problems without ever leaving the administrator's console.
Will your users appreciate this capability? Probably not. First, they are accustomed to the lack of mainframe-style control by now. And second, they are terribly possessive of their PCs--even if they do belong to the company. Your users may be offended by having an administrator look over their shoulders and into their desktop systems.
To gain the acceptance of the user community, some political planning is imperative. Executive-level decisions dealing with the company's overall philosophy toward PC assets must be made prior to the rollout of SMS. These decisions may include which features to implement, from how to distribute applications to who will be allowed to run the network analyzer or remotely control users' desktops. Once the philosophy is determined and the features defined, communication of the policy to the user community with management support will facilitate acceptance of the policy.
Growing the Pilot
For a pilot or an evaluation, you need to plan an SMS primary-site server and limit support to less than 100 workstations. You should choose a function that will impress the usefulness of this product on your business, such as hardware inventory. As the function proves successful with the pilot set of clients, the primary site may grow to manage many thousands of machines. You can back up your SMS's SQL database via SQL administration tools and then restore the database to another SQL Server machine, reconfiguring the site server to use this new SQL Server. Beyond the pilot, clear steps should be laid out to increase the hierarchy of processes, services, features, and clients.
By this time, systems analysts and network administrators have seen the benefits to deploying SMS. It helps them effectively accomplish their objectives. Major benefits are likely to be apparent to the IS manager as well. Executives want to understand the cost implications of the features. For example, consider the cost of just one PC client-software upgrade on 100 client workstations at 10 remote locations. In technician-setup hours alone, it could take 300 hours at $20/hour or $6000. Add about $6500 for travel expenses, and you reach a total of $12,500. Compare that to the cost of SMS software and client licenses! Executives who are conscientious about employee productivity gains can measure downtime decreases for individual users based on Help desk responses using the hardware information. Remote-control features in SMS let the network administrator quickly resolve problems so the users can return to productive work.
Users will accept the benefits of SMS if the company's policy is communicated early on. They will soon appreciate being able to obtain faster, more accurate technical support through the Help desk or systems administration. They will be more satisfied with automated or unattended software updates that they can apply at their own convenience. The initial intrusions, if properly managed, will pay off, even for the users.
Not Just for PCs Anymore
SMS won't be a secret for long. The product's features and benefits for managing an enterprise have the potential to expand true distributed client/server systems to a new level. Any business building tiered, client/server solutions can expedite delivery and support for systems with this technology.
However grand the potential and rich the features, the key to success with SMS is realizing that it's bigger than a PC application. Only in doing vital planning up front will SMS provide maximum benefit to your company.
In Part II . . .
The second part of this exploration of SMS will run in the November issue of Windows NT Magazine
. It will address the key issues that system administrators should be aware of before tackling this highly complex system. Further information will include hardware and software registration for auditing purposes, distributed software management for installation and updates, software patch distribution, Help desk support, network analysis, fault tolerance, performance, and other issues related to SMS.
Contact Info Microsoft - 206-882-8080