Server Operating System
White Paper
This short White Paper is intended for Independent Software Vendors (ISVs) who wish to build Microsoft® Management Console (MMC) snap-ins for applications written for the Windows NT® version 5.0 operating system. This paper focuses on the new Windows NT 5.0 administration model and how snap-ins can be designed to take advantage of that model. It does not provide overview information on MMC, nor does it provide reference information on application programming interfaces (APIs). For background information, please read the White Paper titled Microsoft Management Console Overview before you read this paper.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, the BackOffice logo, IntelliMirror, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
This paper introduces you to the new Microsoft® Windows NT® version 5.0 operating system administration model, and shows you how the Microsoft Management Console (MMC) and management components called snap-ins fit into that model. If you haven’t read much about MMC, you should first read the White Paper Microsoft Management Console Overview. After that, come back and read this paper.
Microsoft Management Console (MMC) is designed to centralize and unify the experience of anyone trying to configure or monitor computers and applications, whether they are responsible for a single workstation or an entire network of computers. MMC is a set of application programming interfaces (APIs), a user interface shell (the console), and a set of guidelines. MMC is a tool host—it provides no management functionality of its own. Individual components, called snap-ins, provide all of the functionality, and most snap-ins will be designed by independent software vendors (ISVs).
MMC provides a way to build better administration tools—tools that scale up and down, tools that integrate seamlessly into the operating system, and tools that can be repackaged and customized to a high degree. In this case, a tool is more than a single application. A tool can be made up of one or more snap-ins, and, in turn, each snap-in can be made up of additional extension snap-ins. This modular structure allows the system administrator to significantly reduce costs associated with systems management by grouping snap-ins into custom tools that provide only the desired view and set of options. The administrator can then save each custom tool as an MMC saved console (.msc) file, and send it to whomever is delegated to perform the administrative tasks associated with that console. This functionality allows administrators to create special tools for end users and to delegate specific administrative tasks to specific administrative groups.
MMC and the Windows NT 5.0 administration model represent a shift in focus from earlier models. It doesn’t matter how cool your tool is if nobody can figure out how to use it or if it’s not flexible enough to meet the demands of a large organization. MMC does have some new and helpful features, but its primary value is in its overall design, how easily it fits into the operating system, how simple it appears to a user, how easy it is to repackage for building solutions for specific administration problems, and how well it scales. It is somewhat challenging to design a tool that looks and feels like it’s an integral part of the operating system. MMC, however, greatly simplifies this effort. If designed carefully, your administration tool should fit right in and its use should be fairly intuitive. It should also be able to leverage existing tools, helping you avoid reinventing the wheel.
Most of the difficult work in building a snap-in comes long before you write a single line of code, and that’s the part of the process this paper will help you through. If you already have the SDK, put it away for a while. You’ll need it well after you’ve completed the design phase of your tool. The same is true for the paper on user interface guidelines. It will be helpful only when you determine where your tool will reside, what other tools it will communicate with, and the functionality you intend for it to have.
The Windows NT 5.0 administration model is different from previous versions. The new administration model is based primarily on the Active Directory and the new distributed services (DS) paradigm. The Active Directory provides a new model for managing, tracking, and finding all objects in a domain or in several domains combined. Objects include, but are not limited to, printers, files, users, applications, and servers. The Active Directory provides a global namespace for objects and named organizational units for delineating administration policies, passing on administrative rights, and easily locating objects. For more information on the Active Directory see the White Paper titled Active Directory Technical Summary.
The Active Directory plays a key role in another initiative at Microsoft—the effort to reduce the total cost of ownership of computer systems. Specific to the administration model is the Zero Administration for Windows initiative, which seeks ways to reduce the difficulty and cost of managing computers and networks. The primary goal of the Zero Administration for Windows initiative is to reduce the workload of a typical information technology (IT) group. Its main theme is “No Touch” administration, which allows the system administrator to manage the user’s machine without ever physically touching the user’s desktop computer. Zero Administration for Windows includes various hardware initiatives, operating system and application setup technologies, Group Policy administration and application management, and the IntelliMirror™ technologies.
While both the Active Directory and Zero Administration for Windows initiatives are major players in the new administration model, the third major factor is the manner in which users and administrators will access the administrative functionality. In Windows NT 5.0, Microsoft’s goals were to have administrative tools include a standard user interface and tool integration, while being simple enough for novice users and scalable for the Enterprise. Microsoft also needed to support much of the existing model—Users have repeatedly stated that they do not wish to relearn common tasks. Therefore, administration in Windows NT 5.0 is done through a tiered model that progresses from the general user to the Enterprise administrator, while taking advantage of existing mechanisms and slowly introducing the user to the new tools. These user levels are described next.
For the general user to the novice administrator, the administrative model includes:
In addition to the features listed above, for the novice administrator the administrative model includes MMC Task Pads, which introduce additional functionality and simplified views of the base administrative tools.
In many cases the Task Pads—and the Tasks Context Menu in MMC—call the same wizards that the user accesses from the Control Panel.
For the power user and advanced administrator, the administrative model includes the features listed above as well as the common, unified tool host—MMC.
The Enterprise administrator can use the existing base tools as well as create custom tools that leverage the delegation capabilities of the Active Directory. The administrator can use the DS Admin snap-in as a launch point for other tools.
A key item in how administrators manage the system is how snap-ins are discovered and invoked. Snap-ins are attached to the objects they work with. They are invoked by the Manage option on the context menu of computer icons (for example, the My Computer icon on your desktop), by many DS objects, or from the Administration Tools menu. When you want to manage an object, instead of finding the administrative tool, you begin with the object itself. This makes administration and configuration more intuitive from the start.
The rest of this paper describes in some detail how some of the more powerful snap-ins were designed. The next section, “Discovery: The Computer Management Snap-In,” describes how administrators discover and use the primary snap-in used to configure a single computer. This section explains how this one snap-in is implemented and describes a location where you might consider adding your own extensions. The section “Snap-In Design” presents some of the issues you should consider when planning how your snap-in will fit into the Windows NT 5.0 administration model, including details on how Microsoft designed the Event Log Viewer and Domain Name Server (DNS) snap-ins.
The Computer Management snap-in is a system administrator’s primary computer-centric configuration tool. It is designed to work with a single computer, and all of its features are fully remotable, allowing an administrator to troubleshoot and configure a computer from any other computer on the same network. This snap-in delivers the information to the administrator in a customizable format that lends itself to custom views and can be forwarded to other administrators easily. And, with a very small amount of development effort, you can extend this snap-in and ensure that all administrators will be able to get the functionality they need to manage your application.
You can think of the Computer Management snap-in as a remote Administrative Tools folder or remote toolbox. It not only provides access to the base Windows NT Workstation tools (viewing events, creating shares, managing devices, and so on), but also dynamically discovers what server services and applications there are to administrate. Administrators can access this snap-in as follows:
Each of these access options is described next.
In Window NT 5.0, as in previous versions, the My Computer icon resides on the desktop. The Computer Management snap-in adds the new Manage option to the icon’s Context menu. (See Figure 1).
Figure 1. Manage Option
When you click Manage, the Computer Management snap-in starts, with the focus on the local computer. When started from the Context menu, the snap-in defaults to the TaskPad view. (See Figure 2).
Figure 2. TaskPad View of Snap-in
You can use the View menu to switch to more advanced functionality. (See Figure 3).
Figure 3. Functionality Available from View Menu
There are three nodes in the namespace that are provided by the snap-in: System Tools, Storage, and Server Applications and Services. The features of these nodes are provided by extension snap-ins. The next subsection describes the guidelines that you should use when extending these nodes to add functionality for your application.
The System Tools node contains the tools that exist on Windows NT computers, and specifies whether they are for workstation, server, domain controller, or client-side usage. These tools include the Event Viewer, Service Management, Device Management, and Diagnostic snap-ins.
This node contains all of the snap-ins related to disks; for example, the Disk Administrator and Offline Storage Management.
This node is used by snap-ins that optionally install on the system or are only installed on Windows NT Servers. Traditional end users would not interact with these snap-ins with normal, everyday system use. This is a really interesting node as it is dynamically populated depending on which computer the snap-in is focused. For example, if the computer is a DNS server, a node will automatically appear for DNS management. (See Figure 4.).
Figure 4. Server Applications and Services Node with DNS Management Tools Installed.
The Administrator Tools folder, which is available on the Start menu, is similar to the version in Windows NT 4.0, with the exception of a few items. The big change is that the items listed are no longer stand-alone executables, but are saved, read-only .msc files (also known as tools or consoles). (See Figure 5.)
Figure 5. Administrative Tools Menu
Items in this folder are placed on the Start Menu bar as part of the generic All User profile. This ensures that only those items placed there when policy is established are present and that only those with administrative privileges can change them.
Another big advantage that MMC offers is in the handling of administrative tool customizations. When a user saves a customized console, the .msc file gets saved in his or her profile in the My Administrative Tools folder. If your network has enabled roaming profiles, then no matter what Windows NT computer you are working on, your profile always follows you—which means your customized toolbox also follows you. Policy can also be used to assign custom consoles to an individual’s My Administrative Tools folder. And, with the Code Download Manager that will ship with the Active Directory, even if you are at a workstation that doesn’t have the snap-in you need installed, the snap-in can be found and installed for you.
Note that Windows NT 5.0 introduces another key change to the Start Menu. Moving forward, the items located in the Control Panel are suited for end users’ preferences and simple configuration only—more complex administrative and configuration tasks will be accomplished through snap-ins.
The Directory Services Administration snap-in (DS Admin) is the main administrative tool for the Active Directory and for all Windows NT 5.0 distributed services.
In a newly installed Windows NT 5.0 domain or in a Windows NT 4.0 domain that has been upgraded to Windows NT 5.0, the Active Directory schema consists of four items: the domain object and three organizational units—one each for computers, users, and the system. The system node holds the containers for remote procedure call (RPC) and Winsock services. (See Figure 6.)
Figure 6. DS Admin Showing Domain Schema for a Newly Installed System
Windows NT 5.0 includes two customized views of DS Admin, each in a separate .msc file—one view focuses on computers (Server Manager for Domains) and the other focuses on users (User Manager for Domains). Both versions appear in the Administrative Tools folder on the Start menu. They replace the old stand-alone tools and initially look the same to users, but they actually are customized views of the DS Admin tool.
The DS Admin snap-in can be extended in much the same way as the Computer Management snap-in. In addition to the extensions that are possible with MMC, the Active Directory schema itself is extensible.
One of the ways Microsoft extended the DS Admin snap-in was with a context menu extension on computer objects that added the Manage option. (See Figure 7).
Figure 7. Context Menu Extension to Add the Manage Option
There are many questions to ask when designing a snap-in—more than you probably want to consider. Beyond thinking about the functionality your tool should provide, you need to think about how your tool will be used. What are the most common operations your users will want to perform?
You also need to think about the kind of service your application is providing. Is it a distributed application or does it reside on only one computer? This will help you to determine whether or not you should extend the DS Administration snap-in in addition to the Computer Management snap-in. If you are designing a snap-in to work with a distributed application, object, or information source, it is likely that you will need to provide some configuration services in the DS, possibly by extending both the DS schema and the DS Administration snap-in.
You should give some thought to related services as well. If there’s a direct connection between your tool and another, you may want to extend the other tool’s snap-in or extend the same snap-in that the other tool extends.
Finally, what kind of users will use your snap-In? Will they be only highly trained IT personnel? Or do you expect users with little or no training to use your snap-in as well? This will help to determine whether or not you need to provide more than one view, such as a filtered view or TaskPad for end users and a more powerful view (such as an extension to the Computer Management snap-in) for administrators.
The remainder of this section walks you through some of the decisions Microsoft made when designing the Event Log Viewer and DNS snap-ins. This approach is intended to give you an idea of how to proceed in designing your own snap-in and how all of these questions can lead you to design decisions.
The Event Log Viewer snap-in presents an interesting case for snap-in design. Since the Event Log Viewer has been around for a long time, there are numerous expectations about how it should work—many of these based on experience with the old executable version of the tool. In addition, many applications make use of the Event Log Viewer. The Event Log Viewer legacy was too pervasive to completely disregard when designing the snap-in version. Microsoft conducted usability testing on some entirely new ways to implement this important service, and finally threw them out because users had too many expectations. However, the need to maintain much of the legacy look and feel made some of the new design decisions easier because the legacy requirements narrowed many of the more difficult design options.
Because the Event Log Viewer is a simple, single computer-centric tool, its snap-in version is a stand-alone snap-in that extends the Computer Management snap-in. The Event Log Viewer was already a remotable tool, so it easily fit in with the other features of the Computer Management snap-in. (The Computer Management snap-in already contained the Event Log, as well as other management features.)
The Event Log Viewer snap-in was easy to implement because it only needs to know the name of the computer to do its job; it obtains the name from the Computer Management snap-In.
There are several ways that people use the Event Log Viewer. Help desk personnel and other trouble-shooters use it to view information on failed services. Independent software vendors (ISVs) extend it by adding information to specific messages or add value to it by creating specialized reports for administrators.
To meet these needs, Microsoft leveraged the MMC extension mechanism clipboard formats, and published two formats for Event Log information—the EventReport format and the LogView format.
The EventReport format shows individual records and allows ISVs to add property pages to records and items to context menus. It also allows applications to obtain records more easily by providing a current record interface.
The other format, called LogView, allows ISVs to add new filtered views to the Event Log Viewer. These views reside in the scope pane and are containers for individual records that can be created for specific applications or services. For example, SQL Server™ could use the LogView format to install a filtered view showing only those messages related to SQL Server.
Figure 8. Event Viewer Snap-In
DNS is a distributed service, and in most cases, more than one computer acts as a DNS server. Because it deals with multiple computers, it is obvious that a DNS snap-in should extend the DS Administration snap-in. It also should extend the Computer Management snap-in because the DNS service itself needs to be configured on individual computers. (See Figure 9.)
Figure 9. DNS Snap-in Extension Design
However, research showed that in most enterprises, DNS was managed by administrators whose entire job was DNS management. So, a stand-alone DNS snap-in was built as well and linked to the Computer Management extension.
Figure 10. Standalone DNS Snap-in
DNS is also implemented as a Windows NT Service, and these services occasionally need to be stopped, paused, and restarted. The designers of the DNS snap-in wanted to expose these options as tasks for the administrator. The snap-in was able to leverage the Microsoft Services snap-in for this functionality. By passing the service name in the proper clipboard format, the Services snap-in can populate the Task context menu with the functionality as shown in Figure 11.
Figure 11. Task Context Menu
One big question, however, is how are servers identified as DNS servers? The Active Directory provides this functionality. DNS servers are published in the DS by adding service connection points. This is a big improvement because historically there was no good way to reach all DNS servers on a network. Administrators had to manually track lists of DNS servers. A trouble-shooter might not know that a server he or she was working on also had DNS installed. By identifying DNS servers, the Active Directory allows the Computer Management snap-in to automatically expose a DNS node when the focus is on a DNS server. And, when working with the DS Administration snap-in (or any DS tool, such as the Find dialog), an administrator automatically receives a current list of all DNS servers. This allows DNS administration to be much more efficient and accurate.
Now that you have some ideas about designing your Snap-In, the following steps may offer further help.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
For more information on the Zero Administration for Windows Initiative and the Intellimirror features, see http://www.microsoft.com/msdn/pdc/nt5beta/Zero Administration for Windows.