Server Operating System
White Paper
Microsoft® Management Console (MMC) is an ISV-extensible, common console framework for management applications. MMC does not provide any management functionality, but instead provides a common environment for Snap-Ins. Snap-Ins are management components integrated into a common host—and this host is MMC. Each Snap-In provides one unit of management behavior, and multiple Snap-Ins can be combined to build a custom management tool. Snap-Ins allow a system administrator to extend and customize the console to meet specific management objectives.
MMC is a core part of Microsoft’s future management strategy and will be included in the next major release of the Microsoft Windows NT® operating system. In addition, Microsoft development groups will use MMC for future management applications.
© 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, BackOffice, the BackOffice logo, Windows, and Windows NT are registered trademarks and ActiveX, NetShow, and Visual InterDev are 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
0797
Microsoft® Management Console (MMC) is an ISV-extensible, common console framework for management applications. MMC will be released as part of the next major release of the Microsoft Windows NT® operating system. When released, MMC will run on both the Windows NT (4.0 and later versions) and Windows® operating systems (current and future versions).
MMC itself does not supply any management behavior, but instead provides a common environment for Snap-Ins, which will be written by both Microsoft and independent software vendors (ISVs). Snap-Ins define the actual management behavior. Snap-Ins are administrative components integrated into a common host (MMC). The MMC environment provides for seamless integration between Snap-Ins—even those provided by different vendors. (For further details on Snap-Ins see the section on “How MMC Works.”)
A system administrator can create tools from various Snap-Ins, and then save these tools for later use or for sharing with other administrators. This approach allows the administrator to efficiently create custom tools with different levels of complexity for task delegation, task coordination, and workflow management. For example, an administrator can combine simple tasks into one tool, and then give that tool to a subordinate or trainee. The same administrator can also design different tools for daily, weekly, and monthly administrative tasks.
MMC is the result of Microsoft's internal effort to create better tools to administer Windows. The MMC development team defined a common host for many of its own tools. The MMC project’s initial goal was to support simplified administration through integration, delegation, task orientation, and overall interface simplification—all key customer problems. As Microsoft addressed that goal, it increased the project's charter to include all Microsoft administration tools, and to offer this generalized framework for management to its many ISVs as well.
MMC is a core part of Microsoft's future management strategy. Most Microsoft development groups will use MMC for future management applications in all versions of Windows and in all of the BackOffice® family of applications. The initial release of MMC has the following goals:
To provide a single host for all management tools: MMC does not replace existing enterprise console and management applications; it allows them to be packaged as Snap-Ins so that they can be accessed from a single interface.
To facilitate task delegation: Using MMC, a system administrator can group subsets of administrative tasks into tools, and forward those tools to other administrators or to subordinates for task completion.
To lower total cost of ownership for the desktop: Task delegation, logical grouping of tools and processes, and management through a single interface allows systems administrators to better organize their tools and tasks and simplify remote administration.
The Microsoft Management Console is a Windows-based multiple-document interface (MDI) application that makes extensive use of Internet technologies. Both Microsoft and ISVs extend the console by writing MMC Snap-Ins, which are responsible for actually performing management tasks.
MMC does not replace existing enterprise management applications, such as HP OpenView or IBM Tivoli Management Environment. Instead, it extends these tools by allowing them to interact with or be packaged as Snap-Ins so that they can be accessed from the MMC interface. For example, an enterprise management application could detect an event and send an alarm to a Snap-In. A system administrator would then see the event in an MMC session and would take appropriate action.
Figure 1. MMC provides a common interface for management tools, including enterprise management
applications.
MMC programming interfaces permit the Snap-Ins to integrate with the console. These interfaces provide user interface extensions only—how each Snap-In performs its tasks is entirely up to the Snap-In. MMC interfaces allow Snap-Ins to share a common hosting environment and provide cross-application integration. The console itself offers no management behavior.
Figure 2. Programming interfaces allow Snap-Ins to integrate with the console. MMC is not concerned with interfaces and behavior beyond the MMC programming interfaces.
Both Microsoft and ISVs can develop management tools to run in MMC and both Microsoft and ISVs can write applications to be managed by MMC administrative tools. Once the prerelease phase is complete, MMC will be part of the Windows Software Developers Kit (SDK) and available for general use.
Non-MMC tools can be integrated with MMC via Snap-Ins, or they can be run separately. A systems administrator can have non-MMC management programs running on the computer at the same time as one or more instances of MMC, and use the operating system to switch between them.
Additionally, an administrator can create shortcuts in the console to the non-MMC tools. These shortcuts will be saved when the MMC tool (or document) file is saved. Within MMC, administrators can create shortcuts to any executable program (.EXE), script, or URL.
At first glance, a MMC UI looks and feels much like an MDI version of Microsoft Explorer. A complete MMC console might look like the interface shown in Figure 3.
Figure 3. A prototype MMC console view.
The MMC parent frame has a master menu and toolbar. The master menu offers what is typical of an MDI parent—file and window management, along with Help.
The MDI child windows offer many differing views of a single console document. Each of these child views includes a command bar, a scope pane, and a result pane. The command bar contains both pop-down menus and buttons. The scope pane (the left pane) is a tree control that displays the tool’s namespace—the tree-formatted listing of all visible nodes, each of which represents a manageable object, task, or view. The scope pane need not be visible in all views—in this example, it is visible in only the top left child window.
Each child window’s result pane (the right pane) displays the result of selecting a node in the scope pane. In many cases it lists the contents of a folder, but in other cases it provides a management-related view (such as the performance graph in this example), which can be Web- or ActiveX™ control-based.
MMC, as pictured above, can be configured to provide powerful management tools. MMC is also designed to offer a scaled-down view that is more approachable to less-experienced administrators. In its most simple form, it can appear as a task-oriented set of icons (see Figure 4).
Figure 4. MMC icon or task view
The interface can be condensed to a single tool, like this service management window:
Figure 5. MMC single tool view
Because MMC permits customization, systems administrators can create and save multiple tools, and can use these tools to delegate specific tasks. For example, each of the views in the preceding examples can be saved to separate files as different tools. When one of these files is sent to another person, that person can open the file, and the corresponding tool (with only the UI shown in the picture) is loaded. A senior administrator could create the view in the preceding picture (a list of services on a computer), and send that view to an operator who will manage only the services on that computer. The operator receives—and can access—only the UI pictured.
Such customization is quite simple. An administrator can use the GUI Snap-In Manager (described later) to load and unload Snap-Ins on the fly. The next screen shows the administrator adding the File Service management Snap-In to the current console.
Figure 6. Adding a Snap-In to a console
The MMC console is a Windows-based MDI application that makes extensive use of Internet technologies. The console itself has no management behavior; it is a host that contains other software—Snap-Ins—that extends the console to offer the actual management capabilities.
You can picture the MMC model as follows:
Figure 7. The MMC model—the console tool (.MSC file) interacts with the Snap-In Manager to retrieve the appropriate Snap-Ins and present the UI elements.
The Snap-In Manager allows a system administrator or Snap-In developer to add, remove, and modify Snap-Ins. In addition, the Snap-In Manager allows the administrator to specify whether a particular Snap-In behaves autonomously or has dependencies on other Snap-Ins.
The Snap-In Manager saves settings into a tool or document (a .MSC file). The items at the top of the picture (the .MSC file and the UI elements) are all that a user of a given tool interacts with. The items at the bottom (the Snap-In Manager and the two Snap-Ins, “Router Monitor” and “Event Viewer”) are the elements that developers and administrators work with.
When a MMC document is loaded one or more Snap-Ins are initialized, as shown in Figure 8.
Figure 8. When the user opens a .MSC file, Snap-Ins are invoked and the UI is rendered.
These Snap-Ins are integrated to create the tool’s namespace—the ordered collection of nodes that appears in the tree view in the scope pane. The namespace is a master tree that represents what the tool can do. It resembles a tree view of the files and folders on a hard drive. The namespace can include all manageable aspects of a network—computers, users and groups, and so on. It can include objects, views, and tasks.
MMC child windows are views into this master namespace (as pictured below). This is akin to having multiple instances of Explorer looking at the same hard drive. Each view can be rooted at a different portion of the tree, but they all point to the same master data source. If data is displayed in multiple child windows and that data is deleted in one view, it will disappear from the other views also.
Figure 9. MMC child views into the master namespace
Each MMC tool is built of a collection of instances of smaller tools called MMC Snap-Ins. One Snap-In represents one unit of management behavior. A Snap-In is the smallest unit of console extension. Technically, a Snap-In is an OLE In-proc server that executes in the process context of MMC. The Snap-In may call on other supporting controls and DLLs to accomplish its task.
Snap-Ins extend MMC by adding and enabling management behavior. This behavior can be added in a number of ways; for example, a Snap-In might add elements to the viewable node namespace (Microsoft’s Directory Service Management Snap-In will enable the network directory to be viewed in MMC), or it might simply extend a tool by adding context menu items, toolbars, property pages, wizards, or Help to an existing Snap-In.
An administrator can assemble multiple Snap-Ins (from multiple sources or vendors) into a tool (this could also be called a document). The tool is what the administrator actually uses to manage the network.
After assembling a tool from various Snap-Ins, the administrator saves the tool in a Management Saved Console (.MSC) file. Later, the administrator just reloads the file to instantly recreate the tool. The administrator can also mail the .MSC file to another administrator, who can then load the file and use the resulting tool. If the second administrator does not have all the necessary Snap-Ins installed on his or her computer, MMC uses the Windows NT version 5.0 Directory Service to download the needed Snap-Ins when the second administrator loads the .MSC file. (Note that this auto download feature will be available in Windows NT version 5.0 installations only.)
MMC permits total customization by the user; an administrator can construct the ideal tool from any available Snap-Ins. An administrator can create multiple tools, and load and unload them when needed. (Although it is possible to run multiple tools simultaneously on one computer, each tool requires its own instance of MMC.)
With MMC, a single “tool” does not necessarily have only a single purpose or function. It is more likely that a regularly used tool will contain management functionality for several aspects of a network—the Directory, replication topology, file sharing, and so on. It is called a “tool” because it runs in one instance of MMC, and can be saved in one .MSC file. Note that administrators of large systems will most likely need more than one tool, most likely arranged by categories of tasks they perform. This facilitates delegation and simplifies maintenance should the network change or grow.
To create a tool from Snap-Ins, an administrator must first obtain the Snap-Ins. If the administrator is working in a Windows NT 5.0 environment and the Snap-Ins are available on the network, the administrator can use the Directory Service to download them with a pre-existing .MSC file (as indicated above), and can then regroup them into a new tool or he can download them one by one.
In a non-Directory Service environment, vendors need to supply individual installation programs.
Every Snap-In provides some external functionality to administrators. In addition, each Snap-In supports one or both of the following internal modes (these modes are transparent to the user except in Snap-In Manager, where the user will be asked to decide which mode the particular Snap-In will have.)
A stand-alone Snap-In provides management functionality even if there are no other supporting Snap-Ins. Snap-Ins designed for this mode cannot rely on any other Snap-Ins being present.
An extension Snap-In provides functionality only when invoked by a parent Snap-In. An extension Snap-In can extend given node types only. It declares itself as being a subordinate to nodes of certain types, and then for each occurrence of those node types, the console automatically adds the related Snap-In extensions.
For example, an extension Snap-In might be a “Log Pretty Print” Snap-In, providing users with several ways to print out log files (such as the
Windows NT Event Log). With this Snap-In installed, every log object in the namespace would be extended with the “Pretty Print” context menu item.
Extension Snap-Ins can provide a variety of functionality. Some can actually extend the console namespace (for example, a Snap-In that provides system information about computers would add that information to the namespace under each computer in the namespace), while others simply extend context menus or specific wizards. For more information, see the section, “Console Extensibility Mechanisms,” later in this document.
Many Snap-Ins will support both modes of operation, offering some stand-alone functionality and also extending the functionality of other Snap-Ins. For example, the Windows NT event log Snap-In reads the event logs of computers. If the computer management Snap-In's computer object exists in the console, the event log Snap-In automatically extends each instance of that computer object and provides the appropriate event logs. Alternatively, the event log can also operate in stand-alone mode, in which case an administrator must manually provide a computer name when the Snap-In is opened, and the Snap-In simply provides the event logs of this one computer.
Microsoft plans to define the following modes of extensibility for Snap-Ins. Every Snap-In must provide at least one of the following types of functionality.
| Mechanism | Description |
| Namespace Enumeration | Participates in the enumeration of elements within a container. Multiple Snap-Ins can register to extend behavior in this way for a given node. As with many of the mechanisms in this table, the Snap-In has the option of altering the enumeration based on the context information passed to it when it is opened. |
| Context Menu Extension | Adds items to the context menu of a node or object. Multiple Snap-Ins can register to extend behavior in this way for a given node. |
| Create New Menu Extension |
Adds items to the Create New menu structure on the context menu of a node or object. Multiple Snap-Ins can register to extend behavior in this way for a given node. |
| Tasks Menu Extension | Adds items to the Tasks menu structure on the context menu of a node or object. Multiple Snap-Ins can register to extend behavior in this way for a given node. |
| Toolbar and Toolbar Buttons Extension |
Adds an entire toolbar or button (if a toolbar already exists) on the window hosting the node. Multiple Snap-Ins can register to extend behavior in this way for a given node. |
| Property Page Extension | Adds one or more property sheets to a Property page. Multiple Snap-Ins can register to extend behavior in this way for a given node. Note that Property sheets are of a fixed size. |
| Mechanism | Description |
| View Menu Extension | Adds views to the View menu for the primary Snap-In. The primary Snap-In can provide multiple views (multiple result panes). |
| Wizard Chaining | Adds one or more wizard pages to a Wizard frame. Multiple Snap-Ins can register to extend behavior in this way for a given node. (This feature will be available in Windows NT version 5.0 installations only.) |
| Help Extension | This will be based on HTML Help. |
In all cases, the Snap-In has the option of altering the returned enumeration based on the context information passed to it at Open time. This permits a Snap-In to register as an extension and offer conditional behavior. For example, the computer management context menu can choose to offer “Open Display” only when it determines that it is being asked to open the control panel Display application on a local machine (because the Display application is not remoteable).
Other than the Create New and Tasks menu extensions, all others are general user interface extension mechanisms. The Create New and Tasks menu extensions are used to group operations in a way that permits integrated, task-oriented command structures. Had the console offered only a generic menu extension interface, there would be little consistency in the usage model. In MMC each node will have a Create New menu and a Tasks menu. Through this extension registration mechanism, all of these menu items and corresponding functionality are collected into a single UI point of usage.
MMC provides several key benefits to administrators:
Because MMC itself provides the windowed environment, MMC is well suited to the ISV who wants to spend more time building real management functionality and less time building and rebuilding a respectable windowing framework for their tools. By writing to the MMC specifications, an ISV will save development time, build in compatibility with other management tools, be able to extend existing management tools written for MMC, and offer an integrated look and feel.
Microsoft’s commitment to MMC is pervasive and ongoing; ISVs who choose to make MMC a part of their management strategy can do so confidently. The MMC APIs will be part of the Windows SDK. In addition, Microsoft is committed to supporting MMC as the way to build Windows-based administration tools, and is using the console to build all upcoming Windows NT administration tools. In the future, the Administrative Tools program group in the Windows NT Start menu will become little more that a collection of saved MMC tools.
MMC will be shipped in the next major release of Windows NT, and versions of MMC will also run on Windows NT 4.0 and Windows 95. (Version 1 is scheduled to ship this year.)
Developers should begin building all administrative tools using MMC. The single largest benefit of MMC is that it enables you to build tools quickly. Even better, because MMC will eventually become part of the SDK, you can build a Snap-In once and ship it either stand-alone, bundled with another product, or as an extension of yet other products (for example, a reporting product can run stand-alone, can ship with Microsoft Exchange Server, or can extend an already released ISV product).
Because tools are shipped as documents, you can, as part of your many “canned tools,” make use of Microsoft Snap-Ins—for example, you can ship a tool that uses Microsoft’s file server manager, log viewer, or other Snap-Ins.
MMC supports integration with the tools that Microsoft and other ISVs offer. You also benefit from the work done by Microsoft to define standard methods of task delegation, task orientation, tool integration, and tool customization.
Microsoft will be working with vendors in the near future to coordinate Snap-In creation and integration.
MMC offers both UI and APIs that can integrate multiple tools. MMC was designed specifically to address the issues of integration, delegation, and task orientation, to be general enough to be reusable by most tools, and to offer simplicity for simple usage scenarios and advanced features for complex management scenarios.
The MMC APIs were designed around the core concept that tools are documents (able to be created, saved, and passed around), and that people should be able to create and customize many new tools. Another key goal was to enable ISVs to build Snap-Ins that can entwine them with the Snap-Ins provided by others, yet enable the user to experience a single tool. A user using such a tool doesn’t even realize that it is composed of Snap-Ins created at different times by different vendors. Extensible help and “about” dialogs maintain product identity and give exposure to the companies creating individual Snap-Ins.
The MMC UI addresses simple and advanced scenarios and all those in between. Microsoft believes that administration occurs over a wide spectrum of experience levels, rather than in a few defined roles (such as user, operator, and administrator). With MMC, senior administrators can create an infinite number of tools—with varying levels of complexity—and pass these tools on to less experienced people who will actually use them. MMC enables the administrator to build a tool that is perfectly tuned to the ability and role of a specific user and to the needs of a particular network.
Enterprise consoles are defined as the administrative products that support the enterprise, most often by managing the computer network. These products typically focus on network management with some extensions for system management. Because of their focus on global heterogeneous management, these products are rarely “best of breed” in their ability to manage individual client types. There is both a need and a great opportunity to integrate Windows-specific administration tools with these heterogeneous enterprise consoles. Here are two possible scenarios:
Because most enterprise consoles are supported on Windows NT-based system, it’s possible to have MMC be the tool of choice to manage Windows-based clients. For example, imagine looking at the physical map view of one of these consoles and seeing a Windows NT Server-based computer flashing red. When the administrator opens a Windows NT Server-based object, an MMC saved tool is launched. This takes advantage of the strengths of the enterprise console in managing the heterogeneous network and the strengths of MMC and associated ISV Snap-Ins in managing the Windows-based platform.
Given MMC’s ability to host Snap-Ins, it’s easy to envision portions of enterprise console applications making themselves available through the MMC user interface. If you examine what comprises an enterprise console implementation, the bulk of the offering is base management infrastructure and services: inventory, device auto-discovery, software distribution, alert collection and suppression, help desk, and so forth. The UI associated with this behavior can quite easily be offered as MMC Snap-Ins. In fact, Microsoft’s future approach will be to have Microsoft System Management Server hosted within MMC. The same applies to other Microsoft BackOffice products.
While building management applications using Internet technologies can be successful, there are many aspects of management that are not addressed by the Internet. For example, large enterprise management consoles may one day converge on using HTML as their presentation UI, but they will always need support to perform network device auto-discovery. MMC is designed to be a premier Windows-based platform with a strong level of support that addresses all of the needs of our users.
Our implementation allows Snap-Ins to use well-targeted COM interfaces for perform the more traditional tasks. For rendering, Snap-Ins can use many implementation technologies—including traditional list views, HTML, Java, ActiveX, and special purpose ActiveX controls (such as a performance-monitoring graph).
We believe that a reasonable portion of the MMC UI will be Internet technology-based, but there is still a long road ahead before Internet technologies can adequately perform some of the more advanced management tasks. Features such as multiselect, advanced window management, simple user customization, and advanced drag-and-drop are impossible or extremely difficult to implement using alternate technologies. We will support new efforts as they are defined and offer tangible benefits to administrators.
Looking to Microsoft's own future, Microsoft® Visual InterDev™ Web development system, Active Server Pages, NetShow™ networked multimedia software, and many of the other recently demonstrated technologies are or will soon be supported. Because MMC provides its browsing by hosting the Internet Explorer control, you can be assured that all of the features of the current version of Internet Explorer will be supported in MMC.
Today's control panel is not well structured. Some Control Panel applications (such as Color and Schemes) are designed for use by the typical user, while others (such as Devices and Services) are targeted at the administrator. In future releases, the Windows team will simplify the Control Panel by migrating administrative functions to MMC Snap-Ins. As part of this migration, these management tools will be enhanced to support remote administration.
The MMC API offers much of the behavior provided by the Shell extensions. However, MMC adds the ability to build tools (through the document persistence model). Therefore, the bulk of those APIs required changes. The biggest changes are needed because MMC extensions are per-tool, not per-computer or per-user, so MMC extension data is stored in each .MSC file. Other key differences include the following:
MMC needs more control of the integrity of the context menus. (MMC needs to restrict where Snap-Ins can place context menu items.) The shell does not permit this level of control.
MMC must allow property page extension on a per-object basis rather than per-object class.
The shell does not offer an appropriate toolbar extension.
MDI is not supported in the Explorer shell (this limitation is described more fully in the next section of this paper).
Perhaps the most important consideration was the code size of the shell itself. While MMC’s requirements could have been added to the shell interfaces, that would have increased the shell code size for all users rather than just for the type of administrative user that MMC targets.
While these key differences necessitated a different set of programming interfaces, the APIs are similar—if you are currently developing to the shell extension interfaces, a migration to MMC is straightforward.
Microsoft Internet Explorer 4.0 takes the Microsoft Internet Explorer and integrates it with the Windows shell. The resulting UI is in some ways very similar to MMC. This was the intent of the Windows administration team from the start—to reduce the time needed to learn new tools.
The key difference between MMC and the shell is that MMC is an MDI-based application and offers features that are not needed nor often requested by users for the shell. For example, managing multiple views is an essential concept in management applications but is not required in an end-user shell. Another key difference is that MMC treats management applications as documents. This means that as a user, you can choose which tools will appear in your environment and where. There are easily 50+ such tools used to manage Windows NT Server and the BackOffice family, without even touching on the even more numerous ISV product offerings. Because of this, tying tools into the Windows shell as namespace extensions is somewhat problematic.
The Windows administration team will continue to follow the shell trends and continue to integrate the MMC UI into the Windows shell. The interfaces provided by MMC are such that these UI changes should have little or no impact on the component Snap-Ins.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/backoffice or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS). To access information via the World Wide Web, go to http://www.microsoft.com and select Microsoft BackOffice.
Document. See Tool.
Extension Mode Snap-In. A Snap-In that provides functionality only when invoked by a parent Snap-In. Extension Snap-Ins can add nodes to the namespace, or just extend existing nodes with new menus, toolbars, property pages, wizards, or Help.
.MSC file. A “Management Saved Console” file that constitutes a tool. Once an administrator has assembled a tool using various Snap-Ins, the administrator can save the tool in a .MSC file, which can be opened and used again later. A .MSC file can be passed on to another administrator. Any administrator can open the .MSC file in MMC, causing the tool to be loaded. See also Tool.
Multiple Document Interface (MDI). An interface that supports multiple simultaneous views, or windows. SDI, or Single Document Interface (Internet Explorer, for example), does not support multiple views.
Package. A collection of Snap-Ins collected into a unit for shipment by a software vendor.
MMC. Microsoft’s general, ISV-extensible common management console scheduled to ship in the next major release of Windows NT. The MMC console itself is a Windows-based multiple document interface (MDI) application. MMC itself provides no management behavior, but instead provides a common environment for the Snap-Ins, which provide the actual management functionality.
Mode of Extensibility. Behavior that a Snap-In provides, extending the console with more functionality. Microsoft has defined several modes of extensibility, and every Snap-In must provide at least one of those modes.
Namespace. A tree-formatted, ordered listing of all the nodes available in the current tool. The display of the namespace is similar to a folder and directory structure on a hard drive. See also Node.
Node. Any manageable object, task, or view. Examples of nodes include computers, users, and Web pages.
Slate. The code name for the Microsoft Management Console. (This is unrelated to the online magazine of the same name).
Snap-In. Software that makes up the smallest unit of console extension. One Snap-In represents one unit of management behavior (for example, the Windows NT event log viewer is a functional unit of management and thus a good candidate to become a Snap-In). Technically, Snap-Ins are OLE In-proc servers.
Stand-Alone Mode Snap-In. A Snap-In that provides functionality even if loaded alone in a console that has no other Snap-Ins.
Tool. An assembly of multiple Snap-Ins into a single console. A tool contains and provides the entire management behavior represented by all the Snap-Ins contained in the tool. A tool can be saved (in a .MSC file) and reloaded. A tool is also called a document.