Managing Exchange 2000, Part 1

The Microsoft Exchange Server 5.5 administrative model has worked well since its introduction with Exchange Server 4.0 in 1996. However, the model's integrated approach can't deliver the flexibility and control that large enterprises require. The model, which isn't particularly open, builds on the Messaging API (MAPI) programming interface—an interface that has failed to capture much support in the administrative sphere, largely because MAPI targets only Exchange Server.

Exchange 2000 Server does almost everything differently from Exchange Server 5.5, so I wasn't surprised to discover that its administrative model is nothing like Exchange Server 5.5's. To its credit, Microsoft has attempted to add flexibility and powerful programming capabilities and to more closely integrate Exchange 2000 management into Windows 2000's basic management framework. At the same time, the new version of Exchange Server seeks to serve a huge market that ranges from single systems serving as many as 100 users to multinode clusters supporting tens of thousands of users in corporate messaging environments.

These diverse goals make for a tall order, and Microsoft's work isn't complete yet—although the early signs are promising. To successfully manage an Exchange 2000 deployment, administrators need to understand all the new features in both Win2K and Exchange 2000. To assist you in this task, I offer a three-part series about managing Exchange 2000—beginning with the basics about Exchange 2000's new management goals, the new product's place in the Win2K management architecture, and Exchange Server management during the transition to Exchange 2000.

Exchange 2000 Management Goals
After you've used Exchange Server 5.5 for a while, managing your Exchange Server organization is fairly straightforward. The finer points of adjusting connectors and accomplishing directory replication—especially across distributed networks—can take time to fully master, but Microsoft has tuned the basic Exchange Server architecture through the past three releases to eliminate most annoying glitches. In Exchange 2000, Microsoft needed to preserve all the advantages of Exchange Server 5.5 and at the same time create a new management architecture that

• supports the partitioning of roles between Exchange Server for server management and Active Directory (AD) for user management.
• provides one management interface that small, midsized, or large systems can fine-tune as needed.
• provides flexible programming interfaces to let enterprises develop monitoring and management tools or integrate Exchange Server into third-party tools—or vice versa. (You can integrate Exchange 2000 into a NetIQ management environment, or you can build tools to use some of the Exchange 2000 programming interfaces. This flexibility simply doesn't exist in Exchange Server 5.5.)

Figure 1 shows the Exchange 2000 management architecture. (Client interfaces are at the top of the diagram.) In an Exchange 2000 environment, you must integrate this messaging management model with the following Win2K components:

• Directory management—This task comprises basic AD management, including replication. Directory management also involves designing and deploying organizational units (OUs) and Group Policy Objects (GPOs), as well as synchronizing AD and the Exchange Server 5.5 Directory Store through the Active Directory Connector (ADC) in mixed-mode environments and synchronizing AD with other directory services as necessary.
• Network management—This task involves IP design and deployment, which includes DNS and DHCP operation as well as WINS operation for backward compatibility.
• Services management—This task entails verifying that Exchange Server and other dependent services, such as Microsoft IIS, are operating correctly.
• Server management—This task includes process monitoring (e.g., reviewing event logs and IIS logs) and performance monitoring.
• User account management—This task comprises creating user accounts, contacts, and groups; enabling Exchange Server services such as Instant Messaging (IM); creating and allocating email addresses; and generating address lists.
• Application management—This task entails managing Exchange Server components, including storage groups (SGs) and databases, public folders, connectors, and administrative and routing groups.
• Storage management—This task involves creating and implementing the appropriate storage architecture (e.g., placement of important files for maximum performance) for Exchange Server and other applications, protecting the Exchange Server and AD databases and transaction logs, and creating, implementing, and verifying backup policies and disaster-recovery plans.

Creating one monolithic system-management application to handle all these tasks and accomplish all Exchange Server's goals would be difficult and entirely inappropriate. Not only would the utility be huge but it probably wouldn't do a good job at any particular task. You'd also have exactly the same problem you have in NT: a lack of cohesive management utilities. (For a description of this problem, see the sidebar "The Need for a Management Framework.") And in NT, a systems administrator to whom you grant permissions to perform a specific job inherits access to many other objects. For example, someone who needs administrative permissions to set up a new printer often ends up with the ability to change passwords.

The MMC Solution
Microsoft Management Console (MMC) is Microsoft's solution to the systems management problem. MMC manages Exchange 2000—and all the new Microsoft BackOffice applications—as well as basic Win2K management tasks such as starting and stopping services. Microsoft first introduced MMC as an option in NT and now uses it as the basic framework for Win2K management tasks, including application management. MMC sets a standard for application-specific tasks so that you can manage all tasks in the same way through the same interface. In one respect, you can compare this approach to the way Microsoft delivers the same multiple-document interface (MDI) and common menu bar to Microsoft Office applications such as Word and Excel. The idea is that once you can work with one Office application, you can work with all the others. MMC also uses an MDI but manages applications rather than documents or worksheets.

   Previous  [1]  2  Next