In-Depth

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 for it.

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.

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.

Design Disparities

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

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 have it.

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 by this.

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 [email protected].) 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.

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.