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.)
- 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.
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:
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.
Applications in the MMC framework take the form of snap-ins that use a COM-based interface to hook into an MMC console. (Microsoft development groups, such as the Windows team and the Exchange Server team, or independent software vendors—ISVs—write these snap-ins. A console comprises one or more snap-ins. For more information about snap-ins, see the sidebar "Win2K MMC Consoles," page 46.) Before you can use MMC snap-ins, you must load them into the MMC executable (i.e., mmc.exe). Mmc.exe provides a basic Windows Explorer-style interface, as Figure 2 shows. A tree control in the window's left pane (aka the scope pane) reveals the depth you have drilled down to; a view in the right pane (aka the results pane) displays detailed information about the current scope. The application-specific snap-ins determine the content of the results pane. MMC can also display HTML content (although you won't typically see this feature in a console). For example, you can write a script to extract data about message queues from the new Exchange Server Windows Management Instrumentation (WMI) interface. You can present that data in an HTML page and add that page to a console.
The standardization of MMC snap-ins means that application writers don't need to design and provide a lot of UI code. For example, each snap-in implements an interface method that tells the MMC how to add items to the scope pane's tree when a user double-clicks to expand a view and which text and icons to use for each type of item. Mmc.exe includes Node Manager, an in-process COM server that takes responsibility for communicating with each of the snap-ins that you load into a console.
Exchange Server systems administrators who are familiar with Exchange Server 5.5 expect to perform management tasks through the Exchange Server administration program working in tandem with several other NT management utilities, such as User Manager for Domains. These programs achieve some synergy—for example, you can create a new Exchange Server mailbox when you create a new NT user account through User Manager for Domains, and you can look for and delete a corresponding mailbox when you remove a user account—but not to the degree that Win2K accomplishes through MMC.
Splitting Management
You use the Exchange Server 5.5 administration program to manage user information (e.g., mailboxes, email addresses) and server details (e.g., connectors). However, Exchange 2000 replaces the Directory Store with AD, which results in a division of management tasks. Win2K now performs user management through the MMC Active Directory Users and Computers snap-in, whereas Exchange 2000 accomplishes server management through the MMC Exchange System Manager snap-in. (The Exchange System Manager—ESM—console is the closest thing you'll find to the Exchange Server 5.5 administration program, but the ESM doesn't perform user management and includes new facilities, such as IM.) Note too that the Exchange Server 5.5 administration program's directory import and export facilities don't exist in the ESM because Exchange 2000 uses AD instead of the Directory Store. Many administrators commonly use these import and export functions to make mass changes, such as adding a secondary SMTP address. (For information about this process, see Paul Robichaux, "Super Export and Import Tools," August 2000, and "Export and Import Mission: Possible," September 2000.) You can make mass changes to AD information, but the tools and data format that you use have changed—Exchange 2000 uses the Ldifde utility to import and export data in Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF).
After you install Exchange 2000, the Active Directory Users and Computers snap-in automatically loads code in maildsmx.dll to display additional tabs when you view a user account's properties. Three Properties tabs—Exchange General, Exchange Features, and Exchange Advanced—let administrators control settings for Exchange 2000 mailboxes. (The E-mail Addresses tab might appear to belong to Exchange 2000 but is part of the basic Win2K setup.)
The Exchange General tab defines details of the store on which the user's mailbox resides, as well as any restrictions you apply. The Exchange Features tab gives you access to an IM home server (which isn't necessarily the same server that holds the user's mailbox). Access to any additional features that you install for use with Exchange Server will also be available on this tab. (By default, IM is the only additional feature packaged with Exchange 2000. For more information about IM, see "Exchange 2000 Server's Instant Messaging," November 2000.) The Exchange Advanced tab contains settings that control the user's appearance in the address book, the user's access rights on a mailbox, and the Internet protocols the user can use to get to his or her mailbox. (Users can always use MAPI to access a mailbox.)
When you select and right-click a user, contact, or distribution group in the Active Directory Users and Computers snap-in, a context-sensitive menu appears. After you install Exchange 2000, this menu includes an Exchange Tasks option. This option launches the Exchange Task Wizard, which guides you through tasks such as moving a mailbox from one server to another, disabling access to email, and enabling a feature (e.g., IM). The wizard bases these tasks on the type of object you select. For example, Figure 3 shows the options that appear when I select my user account: I can move my mailbox, delete it completely, or enable my account for IM. (By the way, if you accidentally delete a mailbox, you can now easily recover it with a new ESM option that lets you reconnect a deleted mailbox to an AD account. For information about this useful new feature, see "Mailbox Management," October 2000.)
The Exchange 2000 installation program automatically installs the ESM console, which Figure 4 shows, on every Exchange 2000 server. From the perspective of an Exchange Server 5.5 administrator, the move to use MMC as the Exchange 2000 management framework is a double-edged sword. On the one hand, you might decry the loss of the simplicity and straightforward nature of the older administration program, especially on smaller systems. On the other hand, the new administration console benefits from MMC's consistency and offers additional functionality, such as context-sensitive menus that you can access by right-clicking a node. For example, the right pane in Figure 4 shows the databases in an SG, as well as the option menu that appears when you right-click one of those databases.
Operation Modes
Exchange 2000 organizations can function in one of two modes: native or mixed. A native-mode organization contains only Exchange 2000 servers, so it can take full advantage of newer concepts such as administrative groups and routing groups. (For an explanation of the relationships among sites and groups, see the sidebar "Sites and Groups.")
Mixed mode, which implies that some downlevel (i.e., Exchange Server 5.5, Exchange Server 5.0, or Exchange Server 4.0) Exchange Server machines exist in the organization, restricts Exchange 2000 by requiring it to comply with the older site model's constraints. (You'll need to use the ADC in a mixed-mode Exchange Server organization.)
Figure 5, page 50, shows Exchange Server 5.5's Microsoft Exchange Administrator view of a mixed-mode site. Two of the servers in the site—COMET and DBOIST-MSXL—are running Exchange Server 5.5; the other servers are running Exchange 2000. Site Replication Services (SRS) and a connection agreement (CA) that the ADC manages ensure that the Exchange Server 5.5 machines recognize the Exchange 2000 servers as peers, even though both sets of servers are running different architectures. If you look at the same site through the ESM, which Figure 6, page 50, shows, you can also see all the servers. However, the ESM offers some graphical assistance to specify the Exchange 2000 servers: The Exchange 2000 server icons are bolder than their Exchange Server 5.5 counterparts. Figure 6 also shows that the ESM uses white folder icons for Exchange Server 5.5 sites that haven't yet migrated a server to Exchange 2000 and tan folder icons for sites that contain at least one Exchange 2000 server.
You should always carry out management operations through a server's native management tool. In other words, manage Exchange Server 5.5 machines through the Exchange Server 5.5 administration program and manage Exchange 2000 servers through the ESM. You can run the Exchange Server 5.5 administration program on a Win2K workstation or server, so both administration programs can run quite happily on the same system.
Any existing Exchange Server organization will operate in mixed mode until you upgrade all the downlevel Exchange Server systems to Exchange 2000. (The switch is desirable because native mode enables more organizational flexibility, such as the ability to combine multiple routing groups into one administrative group. For information about planning a migration, see "Planning an Exchange 2000 Migration Strategy," http://www.win2000mag.com, InstantDoc ID 88630) Any medium to large organization (i.e., 20 to 200 or more servers) might run in mixed mode for a considerable length of time because of the effort required to migrate servers. Indeed, you can argue a fair case not to migrate downlevel servers at all but instead to install Exchange 2000 servers on new hardware and transfer mailboxes to new servers. (You can easily move mailboxes to new servers because Exchange 2000 servers mimic the downlevel architecture, even going so far as to run a dummy Directory Store through SRS. This mimicry convinces downlevel Exchange Server machines that they're communicating with servers running the same architecture, and that they can therefore transfer mailboxes and perform other management operations as if all the servers were in the same site.)
Installing new servers instead of migrating existing systems requires additional investment in hardware. However, this method lets your migration progress more quickly because you don't need to upgrade servers from NT to Win2K and then from Exchange Server 5.5 to Exchange 2000—a process that you can't complete in one step and that won't happen overnight. After you transfer all the mailboxes, you can decommission the older servers and use the hardware to build brand-new servers that are ready for Win2K and Exchange 2000.
A New Approach to Management
Win2K depends on an IP network and DNS; if you don't correctly configure these components, AD replication won't work. Exchange 2000 depends on AD to store and replicate all Exchange Server configuration data, including the location of every Exchange Server machine in the organization; if AD replication fails, the Exchange 2000 configuration data replication will also fail. The close dependencies between Win2K, the underlying IP network, and Exchange 2000 mean that the teams who take care of the design and deployment of these components must work together to successfully deploy Exchange 2000. This requirement makes Exchange 2000 different from Exchange Server 5.5, which you can successfully deploy over a fragmented NT infrastructure because of the relatively loose connection between the application and the OS.
The old days of installing Exchange Server on a whim and a prayer are gone; you simply must establish a solid Win2K deployment before you proceed to deploy Exchange 2000. (For more information about this necessity, see "Exchange 2000 Server over Active Directory," September 2000.) Given this requirement, good design and proper management are more important than ever. In the next two articles in this series, I'll explain how you can monitor Exchange 2000 servers, and I'll review the programming interfaces that you can use to perform management tasks.
