Figuring Out the Pieces of Microsoft Management Console
Microsoft set a lofty goal of creating a consistent interface to help you manage a variety of network tasks. MMC takes us partway there; here's what works— and which pieces still are missing.
- By Catherine Moya
- February 01, 2000
One size fits all. That’s a statement like “the
check is in the mail”—we’re wise to treat
it with skepticism. Is it possible to create a single
interface to host all the myriad administrative tools
for the Windows environment, or is it preferable to have
specialized tools for specialized functions? Can we have
it both ways, or does any deviation from the standard
weaken the concept of a common interface?
Microsoft’s intended scope for Microsoft Management
Console (MMC) is astounding when you look at how many
different products are supposed to fit into the MMC interface.
Can it be done? Can MMC be all things to all programs?
Microsoft Management Console was the centerpiece of the
keynote address at TechEd in 1997. The concept seemed
benign enough, although did we really mind having separate
tools for User Manager for Domains and Server Manager?
On the other hand, the ability to create customized management
consoles sounded interesting.
Since that time, more and more applications are appearing
with MMC snap-ins as the management interface. In SMS
2.0, the old SMS Administrator interface has been abandoned
for an MMC snap-in. Internet Information Server (IIS)
4.0 uses it, as do SQL Server 7.0 and MS Online Analytical
Processing (OLAP) services. The BackOffice Resource Kit
4.5 uses MMC as the interface for all tools. Even Independent
Software Vendors (ISVs) like Hewlett-Packard are writing
And of course, MMC is at the center of all management
in Windows 2000. Microsoft intends it, in fact, as the
administrative interface for everything eventually, a
huge mandate by any standards. Since you’ll be facing
this tool more and more often as a network administrator,
we’ll start by explaining what MMC is and what it
can do for you. We’ll then look at how it’s
being implemented, and finally, some of the larger questions
that this interface begs.
So What is MMC?
Administrators take care of many different tasks on the
network, from day-to-day operations to fixing problems.
This, of course, means different things with different
products. For an operating system, administration includes
jobs like adding user accounts, configuring the hard disks,
and assigning rights and permissions to files. For an
application like SQL Server, administration could be backing
up or creating new databases. For IIS, administration
could encompass creating a new virtual directory. The
idea behind MMC is to provide administrators with a consistent
interface to do lots of different administrative tasks.
Thus, the “management” in Microsoft Management
Console means the ability to work with or manage all your
administrative tasks in one place.
MMC is essentially just a container for small tools called
snap-ins. It can also contain Web pages, folders, and
ActiveX controls. The container itself doesn’t provide
any administrative capabilities. The snap-ins are the
management tools provided by various applications and—in
the case of Windows 2000—the operating system itself.
Snap-ins can’t run outside of MMC.
Each snap-in uses a window structure similar to the Explorer
interface. The left side of the window shows a container
tree; the right side shows the contents of each container.
MMC is what’s called an MDI, or Multiple Document
Interface. This means it’s possible to have multiple
windows, all attached to the same console. (An example
of a Single Document Interface is Microsoft Internet Explorer,
where each session can display only one window at a time.)
The idea is that, as an administrator, you can take one
or more snap-ins and create custom management consoles
for your lesser admins. Each custom console would be saved
as a Management Saved Console file with an .MSC extension,
showing only the options and views that each administrator
should work with. This lets MMC create very specific consoles
for the skill level and job description of every administrator.
The .MSC file can be given to another user or administrator
and automatically invoked to re-create a specific management
environment. You could send it in an email message or
copy it directly to a user’s Start Menu. Theoretically,
if the required snap-ins aren’t installed in the
computer where the .MSC file is being run, MMC will download
the required components.
|It’s easy to add something
to an NT user’s Start Menu or Desktop
across the network—assuming you have
sufficient rights, of course. Start Windows
Explorer and go to Tools | Map Network
Drive. In the path, type:
Admin$ is a special hidden share that
always points to the directory where
Windows is installed, regardless of
what drive letter it’s on. Only
administrators have access to this share.
Once you have a drive letter mapped
to the Admin$ share, use Explorer to
find the Profiles directory on that
drive. Under Profiles, locate the user
you want or select the All Users profile
directory. You can paste an executable,
a shortcut, or an MMC .MSC file directly
into the user’s Desktop folder,
or anyplace you like on his or her Start
Menu. It shows up immediately.
What sort of consoles might you create? If you have an
admin who needs to distribute software through SMS, you
might create one .MSC file that has the SMS packages and
collections containers but nothing else. You might have
another administrator who works with queries. You could
create another .MSC file with the SMS queries container,
the SQL 7.0 snap-in, and some of the specialized query
tools included in the BackOffice Resource Kit 4.5 (BORK)
(see Figure 1).
|Figure 1. An example of a customized
Microsoft Management Console .MSC file.
It’s important to note that MMC isn’t intended
to impose security on your users. It’s more like
a giant menu in which you can turn on the display of some
options on and turn off others—but those options
aren’t disabled entirely. That’s left to the
security of the application you’re running.
While MMC doesn’t enforce security, it does provide
administrative control over the menu-like options. MMC
uses different modes to determine what users can and can’t
do within the console. If MMC is opened in Author Mode,
all manner of changes can be made to the console. The
administrator can opt to save the console so it opens
in User Mode and limit it to three types of access: full
access, delegated access with multiple windows, and delegated
access with a single window. (In the next version, MMC
1.2, Microsoft uses the term “limited access”
instead of delegated access.)
With full access, users can’t add or remove snap-ins,
but they can move through the entire console tree and
open new windows with their existing snap-ins. With delegated
access, users can’t add or remove snap-ins; they
also can’t display any windows not previously saved
with the console. With the multiple windows option, more
than one window can be saved as part of the console. In
our queries .MSC example, we might save the BORK tools
in one window and put the SQL database and SMS query container
in another window.
These administrative controls don’t provide any
sort of security. If users can gain access in Author Mode,
they can rerun the SMS Site Database Connection Wizard
snap-in and give themselves access to more than just the
queries. As we’ll discuss later, Windows 2000 can
use Group Policy Objects (GPOs) to prevent users from
starting MMC in author mode at all.
Microsoft has many plans for version 1.2, which ships
with Win2K. One hopes the new version will follow the
stated design philosophy better than the current version.
We have several significant examples of differences between
design and implementation.
In a white paper entitled simply, “Microsoft Management
Console: Overview,” Microsoft claims that “the
MMC environment provides for seamless integration between
snap-ins.” While this is undoubtedly the goal, the
reality falls short. For example, the Proxy Server snap-in
is a problem child. If you run MMC 1.1 and open .MSC files
created with 1.0, MMC will ask if you want to update to
the 1.1 MSC format. If you do, and the document contains
Proxy snap-ins, you’ll never be able to administer
Proxy from that file again because the three DLLs fail
to initialize. In discussions with Microsoft about this,
we were unable to arrive at a workaround.
There are other disparities between the design and the
realization of that design. Ideally, the .MSC files are
supposed to allow you to package up any snap-in and send
it to any computer. According to the white paper overview,
“If the second administrator does not have all the
necessary Snap-Ins installed on his or her computer, MMC
will automatically download the needed Snap-Ins when the
second administrator loads the .MSC file.” Download
from where? The document doesn’t specify.
We found this same sentence in a few documents with the
same name but different dates. In the document at www.microsoft.com/MANAGEMENT/MMC/overview.htm,
copyright 1996, there’s a footnote that says, “Auto-download
is not implemented now; it will be in a release after
the Professional Developers Conference.” A later
copy of the document, dated 1998, makes no such disclaimer.
Has it been implemented? And as far as we can tell, no.
We tried with SQL, SMS, the BORK, and IIS—none of
them will run unless that application is installed on
the computer on which you’re trying to run the .MSC
Right-clicking on something in the tree while in Author
Mode presents an option for “New window from here.”
This menu option is supposed to create a window with that
node as the top of a new tree. Figure 2 shows how this
feature presumably works. Note that in the top window,
you can see all of the SMS options. The bottom window
shows the result of invoking “New window from here”
on the Collections node in the tree. Unfortunately, the
change isn’t preserved. No matter how many “New
windows from here” we opened, when we reopened the
console, we got the full tree again in each one of those
windows. This is the best case to hope for; there are
documented cases of this option hanging your system with
IIS and Terminal Server (as reported in KnowledgeBase
article Q194393, “New Window From Here Option in
MMC May Cause Fatal Error”). We have anecdotal experience
with it hanging our SMS systems.
|Figure 2. The “New window
from here” option doesn’t stick and can
actually hang your system.
Saving .MSC files in User Mode is supposed to prevent
mischievous lesser admins from changing their consoles.
In reality, getting access to Author Mode isn’t difficult.
Once the user has started the .MSC file, he or she can
right-click on the console’s title bar and bring
up the User Options. From there, the user can select the
option to “always open console files in Author Mode.”
(See Figure 3). And it does. Also, if MMC is started with
the /A switch, that automatically invokes Author Mode.
|Figure 3. Getting access to Author
Mode is a fairly easy matter, even for those who shouldn’t
Usually in the Windows interface, the mouse can be used
to access an object quickly and effectively. In this regard,
certain snap-ins are a giant step backward. In the SMS
snap-in, if you want to start one of the SMS Tools, you
must first right-click the tool, then select “All
tasks” from the context menu, then finally select
the tool you want to start. Whatever happened to good
old “double click?” (See Figure 4.)
|Figure 4. Steps required to open
an SMS tool don’t necessarily follow the clicking
practices we’re accustomed to.
Another pet peeve from users of various snap-ins is how
hard it can be to find what you need in the interface.
Granted, the SMS 1.2 interface was far from perfect, but
at least everything was fairly visible. In SMS 1.2, you
had to use the File | Properties option to see all the
site configuration settings. Once you found them, there
was a clear button to set the parent site. In the 2.0
snap-in the method for joining a child site to a parent
site is also set in the site properties. But the only
way you can see those properties is to find the precise
node in the tree and bring up the properties page. Even
trying to explain which node to select is monumentally
difficult without using pictures. Trying to remember where
these options live can be every bit as difficult. In Figure
5, we show you how to accomplish this action in SMS 1.2
using the old interface. Figures 6 and 7 show you the
process in MMC. Ouch!
|Figure 5. Joining two sites in
SMS 1.2 was fairly simple: File | Properties, then
click a button.
|Figure 6. Doing the same in SMS
2.0 is a bit more complex. First, locate the precise
node in the tree and bring up a Site properties page...
|Figure 7. …Then join two
sites in SMS 2.0.
Because MMC is so visually based on the tree, it’s
difficult to adapt this interface to comply with Microsoft’s
own accessibility standards. Part of the Microsoft design
guidelines for the Windows interface require that it be
accessible without a mouse. With the SQL Server snap-in,
among others, this is badly implemented. If you could
use a mouse, you could simply click on the server you
want to administer and bypass all other servers. Without
the mouse, you have to arrow through the hierarchy of
servers; MMC insists on actually connecting to every server
you touch. If you have several servers, you can’t
just move through the list, it’s arrow-wait-arrow-wait
and then arrow again. In researching this article, we
tried to move through a list past a server whose SQL Server
service was stopped; we got two error messages regarding
an inability to connect, then a Dr. Watson error message.
Another Achilles heel in the current implementation of
MMC: It’s a single-threaded application. All snap-ins
share that thread. What this means to us is that if a
snap-in hangs or is simply very slow, nothing else can
be done with MMC until the snap-in finishes or MMC is
restarted. Consider what this means to the administrator
who would like to multi-task. If a snap-in is taking a
long time on the task—such as a database backup in
SQL Server—it’s necessary to open several instances
of MMC. One suggestion from Microsoft is to create small
MSCs, each containing a single tool—one for Enterprise
Manager, one for SMS, one for IIS—which sort of brings
us back to where we started.
In many places, the MMC documentation states that it
will run on Windows 9.x. MMC does, but most snap-ins don’t.
This is akin to hiring a chauffeured car to take you on
a mountain trip in winter. You ask, “Can the car
handle icy winter roads?” The answer is yes. But
when you get there, you find the car can but the driver
can’t. Many administrators are frustrated and confused
Who’s Behind the Wheel?
Taking a step back, it’s important to remember our
initial description of MMC—it’s just a container
for snap-ins. It’s easy to “shoot the messenger.”
In this case, the messenger is the MMC envelope that wraps
up a hodge-podge of different utilities written by different
program groups or different companies, often without much
regard for consistency. So who “owns” MMC?
There’s an actual MMC product group at Microsoft.
They’ve recently been moved from the BackOffice team
to be part of the Windows group. We’ll hope this
gives them a better chance to integrate MMC with all the
Windows products. (Suggestions and comments to the team
can be addressed to firstname.lastname@example.org.) Even though
there’s a crew for MMC, the snap-ins are still written
by different application teams at Microsoft, or by different
vendors, or by independent programmers. And there isn’t
much to go by in the way of standards. Microsoft Press
has a book in the works that will be a snap-in author’s
guide and will provide some sort of interface guidelines.
But at the moment, there are no other guidelines to MMC
standardization. That’s too bad, because it’s
possible that these standards will address many current
concerns. But even when standards are in place, will they
be followed? Perhaps a better question than “Who
owns MMC” is “Who enforces MMC?”
Even with standards in place, designers of snap-ins will
still have a great deal of autonomy. For example, it will
be up to each application to decide whether or not the
snap-in will run on the Windows 9x platform. Even though
MMC will run on Windows 9x, is that helpful if there are
no snap-ins? MMC provides support for drag and drop, but
it’s up to the snap-in creators to use this feature
within their applications. In SMS, this has forced us
back a step from the days when we could drag a package
and drop it over a group to initiate software distribution.
And if the SMS designers decide to hide the settings for
joining two sites under a bushel, can any standard be
crafted that could forbid them? If they did, would it
be enforced? As Bill Cosby is credited with saying, “I
don’t know the key to success, but the key to failure
is to try to please everyone.”
The Future of The Beast
Since this article is being written well before Windows
2000 is scheduled to make its debut, it’s difficult
to say for certain which new MMC features will ship with
it. As Microsoft says in all of its beta disclaimers,
we “cannot guarantee the accuracy of any information
presented after the date of publication.” But we
can tell you what Microsoft is saying about the beta version
of MMC 1.2.
MMC is at the center of all management in Windows 2000.
Old friends from NT 4.0 like Event Viewer and Performance
Monitor have been given a once-over to adapt them to the
MMC interface. Many new tools to manage Active Directory
have been added, and they, of course, also use MMC.
One important feature for managing security is the ability
to control who can get into Author Mode. Rather than leaving
the weak restrictions in place from the NT 4.0/Win9x platforms,
Windows 2000 can use Group Policy Objects (GPOs) to determine
who gets Author Mode access. Even for users with access
to Author Mode, GPOs can be used to set lists of permitted
snap-ins and restricted snap-ins; GPOs can be configured
to permit all snap-ins except the restricted ones, or
they can restrict all snap-ins except the permitted ones.
In the next release of MMC, “taskpads” are
supposed to be more widely implemented. A taskpad is a
simplified window of task-oriented information. It uses
a dynamic HTML (DHTML) page to show shortcuts to other
tasks, groups of tasks by function, and simplified task
lists. While these features are available to programmers
in MMC 1.1, in 1.2 ordinary users will be able to customize
their MMC environment with their own taskpads. They’ll
also be able to maintain “favorites” inside
their .MSC files.
One feature we probably won’t see in MMC 1.2 is
printing. MMC doesn’t provide print services to snap-ins;
instead the snap-in itself is required to handle printing
tasks. This is an additional burden placed on snap-in
developers, many of whom may never have considered the
intricacies of printing before. Generally, we assume that
the application will provide this service; for example,
if I’m creating a solution in Word using VBA, I depend
on being able to invoke the print method in Word. MMC
offers no such service. What we’ll get in MMC 1.2
is the ability to export the data displayed in MMC to
a text file.
The export feature will be enhanced by the ability to
customize the columns configuration in a details list
view. We should be able to rearrange columns or hide them
completely. Certain snap-ins may also provide filtering
by using drop-down list boxes under the column headings.
As noted before, these will be options that snap-in developers
may or may not choose to implement.
We’re also looking forward to a design change in
the next release. Microsoft Certificate Server comes with
the option pack and is used in public key/private key
encryption. In the current version, the .MSC created by
the installation of Certificate Server is stored in \winnt\system32.
This isn’t good, since storing things in the system
directory isn’t secure. The only items there should
be system files, which should be protected from casual
access, accidental deletion, and viruses. In Windows 2000,
the system directory is more closely guarded and this
.MSC file will be placed somewhere more appropriate.
Snap-Ins: The Developer's Perspective
|As part of its philosophy
of having everything managed through MMC,
Microsoft has made snap-in development
available to a wide audience. Kits are
available for download that ease the development
of custom snap-ins.
Snap-ins can be developed with Visual
C++ or Visual Basic tools available
VC++ programmers can download the 2.1M
SDK; VB developers should try the ActiveX
Designer for Visual Basic (1.1M), in
beta at the time of this writing. While
downloading, take a look at www.microsoft.com/management/MMC/devinfo.htm
for some TechEd PowerPoint presentations;
while the most interesting stuff is
lacking (there are many slides that
say “demo”), they’re
I downloaded and installed the VB kit.
After my install, I was able to make
a new project type: a SnapIn. I found
several forms and controls in my project,
but I had little to no idea what to
do with them. Fortunately, the setup
program also gave me some samples to
look at. The FileExplorerSample.vbp
project creates a snap-in that acts
a lot like Explorer; it allows the user
to navigate through directory hierarchies.
The snap-in designer setup registers
this new snap-in. Therefore, after setting
up the designer, you can create a new
MMC document and add in the FileExplorer
snap-in. The software asks several questions
when you do this: Should network drives
and computers be browseable? Should
the user be able to delete or rename
After the configuration, the snap-in
is ready for use. Take a few minutes
to work with it—not so much because
you’re going to want to use the
tool, but to see what it does in order
to look at the VB project and see how
it’s coded. Find VBSnapInsGuide.chm;
this is the compiled HTML help document.
Reading the doc and looking at the
project makes the target audience clear.
Although the VB tool is impressive in
the amount of complexity it hides, it’s
obviously aimed at accomplished VB developers.
Skills in scripting Office applications
with VBA won’t be enough to understand
what’s happening with a snap-in.
ActiveX knowledge is required, especially:
- How ActiveX DLLs interact with the
system, including how to register
them with regsvr32.
- How project compatibility works
and what its implications are.
- How ActiveX controls are used on
My favorite book covering these topics
is Dan Appleman’s Developing
COM/ActiveX Components with Visual Basic
6: A Guide To The Perplexed (SAMS,
1998, ISBN 1-56276-576-0, $49.99).
As you experiment, remember: The snap-in
development kit is beta code. My testing
resulted in many illegal operations,
but produced no lasting ill effects.
The most frustrating thing for me was
that my snap-ins would sometimes appear
in MMC’s add/remove snap-in dialog—and
sometimes would not. This is OK for
beta code, but the final version will
have to be far more stable if it is
to be widely adopted.
Now that I can write my own snap-ins,
I’m paying close attention to the
good and the bad in the snap-ins I use.
By doing this, I hope to learn what
to do and what not to do. It’s
important to remember that MMC gives
the snap-in, and therefore the snap-in
designer, a lot of power.
For example, it’s possible to
write a snap-in that has an overly long
timeout while trying to connect to a
remote computer. Because all of the
snap-ins are sharing a single thread,
nothing else can be done with that instance
of MMC until the snap-in releases the
thread. This is somewhat analogous to
the situation we had with 16-bit Windows,
in which a single application could
hang the entire system. If Microsoft
fixes the bugs, supports the kit with
documentation and examples, and doesn’t
break our snap-ins with future MMC versions
(like what happened with the Proxy Server
snap-in and MMC 1.2), this might be
a very useful tool. Time will tell.
Too Simple to be Powerful?
According to Microsoft literature, MMC provides several
key benefits like task orientation, customization of consoles,
integration, extensibility, and overall interface simplification.
The task orientation is definitely a plus. Being able
to customize the .MSCs for admins of different abilities
and job descriptions is a boon. Allowing users to create
their own taskpads in MMC 1.2 will add even more flexibility.
But until the “New window from here” option
works reliably and consistently, one of our major customization
options hovers just out of reach.
Integration in MMC is a good idea, as long as someone
can keep all the snap-ins from stepping all over each
other. Who will watch the sandbox to make sure everyone
plays together? How will extensibility be maintained when
we’re dealing with so many variables? Granted, ensuring
compatibility of management apps isn’t as far-reaching
a task as ensuring compatibility of applications within
an OS, but it confronts many of the same problems. How
do you change one thing without breaking everything else?
And if the application programmer doesn’t follow
the rules and something blows up, it’s the container
that ends up looking bad. On the MMC home page (www.microsoft.com/management/MMC)
Microsoft maintains a snap-in gallery where ISVs can have
their snap-ins posted. According to Microsoft, any submitted
snap-ins can then also be tested to make sure they’ll
still work as changes are made to the MMC container. But
all it takes is one change from the ISV or one change
from a service pack, and everything goes poof.
Overall, interface simplification is an admirable goal,
but it begs the question—is there such a thing as
being too simplified? While management tasks are presumably
becoming more straightforward, the programs behind them
are becoming more complex. An analogy can be made to cars
over the past few years. You can get a car now that doesn’t
need a tune-up for years. Doors, windows, seat operation—all
of these are power-driven and packed with features. But
what happens when something breaks? It isn’t as simple
as grabbing a wrench and popping the hood anymore. We’re
seeing the same thing with our OSs and applications. SQL
Server may be auto-tuning, but what happens when it doesn’t
auto-tune things correctly for a particular application?
The Windows 2000 MMC provides a snap-in for managing
user accounts, but it doesn’t give many options outside
the wizards. The SMS MMC provides a special switch to
start the admin console with additional node information
not present in the default settings. Perhaps this is something
that should be more widely used and documented. If the
management interface is too simplified, administrators
will have to turn to other means to get the job done—tweaking
the registry, using ISQL, or writing scripts. The more
simplified the interface, the more frequently we’ll
have to abandon it for truly tough tasks. And the more
frequently other vendors will step in and write different
management tools, tools which may or may not use MMC.
While this doesn’t negate the value of having simple
tools for simple tasks, it takes us further from the goal
of having a true unified management interface.
We’re not saying that Microsoft—or any other
software company—has to be perfect. But when it sets
a task for itself, like creating a comprehensive and consistent
interface, how effectively can it deliver? Will Microsoft
really come through with a one-size-fits-all Microsoft
Management Console? The check is in the mail.