COMmon Ground

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 InterfaceTo 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.