COMmon Ground

With its central interface, Microsoft Management Console makes managing administrative tools a “snap.”

• By Michael Chacon
• November 01, 2001

One of the most common complaints with the Windows NT 4.x environment involves administrative tools. Many of the applets necessary to manage servers, workstations, services and devices are spread throughout various interfaces, menus and the control panel. As the number of components grows to support even more new devices and services, this steady increase of necessary administrative tools only continues, creating serious clutter in the management workspace. This clutter is a direct contributor to the increasing cost of ownership of the network.

In one effort to address this problem, Microsoft came up with the concept behind the Microsoft Management Console (MMC), which was first introduced in Windows NT 4.0 Option Pack for Windows NT Server. It was the prototype for the administrative model for what was then referred to as Windows NT 5.0, which we now all know and love as Windows 2000.

The MMC is a COM-based extensible container that provides an environment for other COM objects called snap-ins, which supply the actual functionality for specific administrative tasks. The MMC is actually a very good example of a COM-based application. It’s built upon the idea that future unknown or unimagined value can be added to an application by having the particular new COM object use well-known interfaces that present an environment to host the object and then forward the functionality to the user.

Let’s Interface
To accomplish this, the MMC exposes a set of COM interfaces for the snap-ins. The snap-ins implement the functionality desired and expose it via the MMC COM interfaces. This relationship is what provides the commonality across snap-ins to the user and makes the work of creating a snap-in easier for the developer. For example, the MMC exposes an interface that allows a snap-in to add help files to the MMC help menu as well as controlling columns and other graphical tools in the GUI. On the snap-in side, there’s an interface to extend the menus of the MMC and to add control bars for customized functionality. The result of this flexible architecture allows a wide variety of functionality to be created, while providing a central and common interface for organizational and customized purposes.

While the MMC appears to be a simple shell, a quick poke under the covers reveals a more complex environment. As you can see in Figure 1, when the MMC.EXE is loaded, it calls a plethora of DLLs that are loaded to support its integration into the Win32 environment.

Figure 1. When the MMC.EXE is loaded, it relies on many DLLs to create the host environment for snap-ins. (Click image to view larger version.)

The ones you would expect are all present, including NTDLL.DLL, which is the focal point between application mode and kernel mode. This isn’t too surprising, as executables invariably depend on the DLLs that make up the operating system. All of these DLLs along with MMC.EXE combine to create a host environment for the snap-ins or COM objects. This host environment doesn’t provide most of the administrative functions. Instead it provides built-in functions that snap-ins can call. The snap-ins and the MMC have a symbiotic relationship that allows the administrator to build custom management tools that can then be distributed to other administrators. More about that later.

The complexity of the snap-ins, or COM components, is also demonstrated by a look at the same process once a snap-in is loaded into the MMC as shown in Figure 2.

Figure 2. Once a snap-in is loaded into the MMC, the number of DLLs involved expands drastically. (Click image to view larger version.)

All of the DLLs in Figure 2 were called just by loading the defragmenter snap-in (that comes with Win2K) into the MMC shell. I cut off the screen at the top of the window that shows the original DLLs in the previous graphic. You can get a clearer view of the specific DLL that contains the snap-in by running a utility from the www.sysinternals.com Web site called the Process Explorer. With this tool you can see the description and version of each DLL and, as shown in Figure 3, you can see the DFRGSNAP.DLL, which is the primary snap-in that’s loaded into the MMC in this example.

Figure 3. A utility called Process Explorer can give you a clearer view of a specific DLL, including a description and version of each. (Click image to view larger version.)

Feeling Functional
There are several versions of MMC in the Windows world. MMC 1.0 was the first version introduced in the Windows NT 4.0 Option Pack. MMC 1.1 was introduced with SQL Server 7.0 and System Management Server 2.0. A consistent platform was made available when MMC 1.1a was published to consolidate the first two versions for the NT 4.0 and 95/98/Me platforms. It’s still available for download on the Microsoft Web site.

The current version is MMC 1.2 and is delivered standard with the Win2K images. MMC 1.2 added more functionality, particularly for the Win2K environment. The most important functions are the following:

• Console Taskpads. This allows the administrator to create a simplified view of the snap-in tools for distribution to delegated administrators. More on this shortly.
• Column Persistence. This allows the user to save customized views such as column width, column reordering, column selection and sorting. These views can be saved in an .MSC file, which is the binary configuration file snap-ins use to pass information to the MMC process during initialization. The snap-ins are called by the MMC as parameters that are stored in .MSC files. It also permits filters to be placed upon views to narrow the amount of information presented to the user.
• Exporting List Views. This allows you to send the views to a text file for distribution to other parties. This function is useful for the documentation of configuration information or for communicating troubleshooting information to support agencies.
• Microsoft Installer Integration. This provides interoperability with Active Directory to automatically distribute the DLLs necessary to complete the COM architecture for all the snap-ins referred to in a particular .MSC configuration file. When an administrator creates an .MSC for a delegated administrator and sends it to him for use at his machine, that machine may not have all of the necessary files to run the MMC with the particular snap-ins specified. With the Microsoft Installer integration, when the .MSC file is executed, any files not present will be automatically downloaded to the machine without any action or training for the delegated administrator. Of course, as with any application, the MSI magic is dependent upon the installation package created, including the .MSI file that contains an installation database. Also, the policy for the target machine must have “Download missing COM components” enabled, which is disabled by default on Win2K machines.
• Policy Integration. This allows the administrator to prevent groups or users from accessing specific snap-in functionality without having to create and keep track of different versions of .MSCs to provide the same level of control. The MMC group policy options are fairly self-descriptive: Restrict Author Mode, Restrict Access to specified snap-ins, and Grant access to a list of permissible snap-ins.

As you can see, MMC 1.2 is very specific in taking advantage of the new features in the Win2K architecture. Some examples of .MSC files and their locations from various add-on applications are shown in Figure 4.

Figure 4. The current MMC version, delivered with Windows 2000, is MMC 1.2. These are some examples of .MSC files and their locations from various add-on applications. (Click image to view larger version.)

MMC 1.2 can also be used in the NT and 95/98/Me environments by downloading IMMC.EXE from http:\\support.microsoft.com/support/ mmc/mmcdown.asp. This will install the files necessary for the MMC to run. However, the Win2K administrative snap-ins won’t function from a 95/98/Me machine. If you want to run MMC for this purpose, you’ll need something like Terminal Server to administer the Win2K environment.

It’s Evolutionary!
MMC isn’t standing still. MMC 2.0 is about to be distributed in the Windows XP code set due for release this year. One change is the increased modularity of the MMC and COM implementation. This is manifested by a user mode console, which allows the user to save changes automatically without a prompt to save the changes when exiting. In addition, the main console file can be distributed as Read Only to protect it from unruly behavior. However, the user’s changes can still be saved, as the console state and user state are stored separately. The MMC also has a Disk Cleanup mode via the File | Options menu to remove the user state for a fresh start without affecting the original .MSC configuration.

The biggest and most interesting addition to version 2.0 is the Automation Object Model. This allows developers to interact with the MMC without having to write a snap-in or extension. For example, the Process Viewer from the www.sysinternals.com site could be written to interact with the MMC so tools like this can be included and distributed with the .MSC.

Of course, what would a discussion about Windows be without a nod to the registry? Snap-ins must register with the registry in order to be added to a console file. The two main keys are HKLM\Software\Microsoft\ MMC\Snapins and HKLM\Software\ Microsoft\ MMC\NodeTypes. With this background and architectural overview of the MMC in place, next month I’ll discuss how to configure MMC and create specialized .MSC files that can be used to distribute management functions to delegated administrators in your Win2K network.