Managing Exchange 2000

Updated : October 17, 2001

By Tony Redmond

This article is from the February 2001 issue of Windows 2000 Magazine.

Basic know-how for a smooth start

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 Windows 2000 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 Windows 2000 management architecture, and Exchange Server management during the transition to Exchange 2000.

On This Page

Exchange 2000 Management Goals
The Need for a Management Framework
The MMC Solution
Splitting Management
Operation Modes
A New Approach to Management

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: Exchange 2000 management architecture

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 Windows 2000 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 Need for a Management Framework

Windows NT and the early versions of Microsoft BackOffice applications come with a curiously loose collection of management utilities. For example, no obvious connection exists between User Manager for Domains (which you use to create a new account), the Exchange Server administration program (i.e., admin.exe—which you use to define a new email address for a mailbox), or Performance Monitor (which you use to monitor system performance). Each utility has a different idea of the perfect UI. The utilities' only common feature is that they all perform some type of management operation. This lack of similarity requires you to master each utility separately, which in turn drives up the overall cost of systems management.

The reason for such a fragmented landscape is understandable. Microsoft didn't design NT or the original version of Exchange Server for the enterprise. These products' administration tools are best suited for small to midsized companies in which one person or a small group of people typically looks after everything (e.g., the network, storage, user accounts, messaging, database maintenance). In these circumstances, you don't need to worry about dividing work between people, so a management utility such as the Exchange Server 5.5 administration program is appropriate. In enterprise-level deployments, a clear distinction usually exists between different teams' duties, so management tools need to be granular and flexible. (That need is one reason why such a large market exists for third-party NT management utilities.)

Windows 2000 differs greatly from NT in this respect. The emphasis on providing basic OS functions (e.g., setting up file and print shares)—the original reason for many NT deployments—has firmly shifted toward the ability to build and operate an infrastructure for applications. Many parts of the overall system interact with applications, including Exchange 2000 Server.

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 Windows 2000 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 Windows 2000 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 "Windows 2000 MMC Consoles") 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.

Figure 2: MMC architecture

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 Windows 2000 accomplishes through MMC.

Windows 2000 MMC Consoles

Many of the options previously available on the Windows NT Control Panel are now available as Windows 2000 Microsoft Management Console (MMC) snap-ins, which you can access through the Administrative Tools menu. A console is a set of snap-ins that Windows 2000 treats as an administrator's workspace. Windows 2000 stores each console's details in a Management Saved Console file, which has an .msc extension and which you can distribute and share as you would any other file. When you use an .msc file, you're actually starting up the MMC executable (i.e., mmc.exe) and passing the name of the .msc file as the first parameter in the command line. If you start up mmc.exe without a parameter, you begin with a blank console and can then load the snap-ins you want to work with.

Microsoft provides Windows 2000 with a comprehensive set of consoles. These standard Windows 2000 consoles manage basic elements such as services running on the local computer and local file shares as well as discrete applications such as DNS and Active Directory (AD). Note that some of the AD consoles appear under Programs, Administrative Tools only when the server acts as a domain controller (DC). However, the AD snap-ins are available on all servers, and you can quickly combine these snap-ins into a customized console on any server. Of course, if you fire up a console on a server that isn't a DC, the server will need to connect to a DC before it can access any AD data. Table A lists and describes the snap-ins that Exchange Server administrators can use. (For more information about MMC and snap-ins, see Kathy Ivens, "The Mighty Windows 2000 Management Console, Part 1," September 2000, and "The Mighty Windows 2000 Management Console, Part 2," October 2000.)

TABLE A Principal MMC Consoles That Exchange Server Administrators Can Use

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. Windows 2000 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 Windows 2000 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.)

Figure 3: The Exchange Task Wizard

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.

Figure 4: Managing Exchange 2000 through the ESM console

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.")

Sites and Groups

Microsoft Exchange Server 5.5 sites serve many purposes. Sites establish boundaries for routing: Connectors belong to a site, and Exchange Server 5.5 uses connectors to join sites. Sites serve as centers for directory replication: Objects belong to a site, and Exchange Server replicates objects between sites. Associating objects with sites leads to security boundaries: Administrators set permissions within a site, and these permissions reside in the Exchange Server directory. Finally, you perform administrative work on a site basis: Sites own objects such as servers, connectors, and mailboxes, and only accounts that have the necessary permissions to add, modify, or view the objects can administer the objects.

In Windows 2000, Exchange Server configuration data resides in a set of containers within Active Directory (AD), and administrative groups and routing groups are simply containers waiting to hold other Exchange Server objects (i.e., servers) inside. Exchange 2000 Server uses administrative groups to determine who manages servers and how (e.g., the policies that apply to servers inside each group). Exchange 2000 uses routing groups to define how messages are routed between servers and outside the organization. The combination of administrative and routing groups delivers more flexibility and control than the Exchange Server 5.5 architecture delivers, but you can realize the true power of administrative groups and routing groups only when Exchange 2000 is in native mode. In a mixed-mode organization, legacy Exchange Server machines use a combination of one administrative group and one routing group to represent each site. You can't change this structure until you move the organization to native mode—a one-way operation that you can reverse only by restoring all the organization's servers to the state they were in before the move. (For more information about administrative and routing groups, see "From Sites to Groups," June 2000.)

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: Exchange 5.5 Administrator displaying a mixed-mode site

Figure 5 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 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.

Figure 6: Exchange 2000 displaying a mixed-mode site

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 Windows 2000 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." 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 Windows 2000 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 Windows 2000 and Exchange 2000.

A New Approach to Management

Windows 2000 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 Windows 2000, 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 Windows 2000 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 Managing Exchange 2000 Server, Part 2, I'll explain how you can monitor Exchange 2000 servers, and in Managing Exchange 2000 Server, Part 3, I'll review the programming interfaces that you can use to perform management tasks.

About the Author

Tony Redmond is a contributing editor for Windows 2000 Magazine, senior technical editor for the Exchange Administrator newsletter, vice president and chief technology officer for Compaq Global Services, and author of Microsoft Exchange 2000 Server: Planning, Design, and Implementation (Digital Press). For answers to your Exchange questions, send an email message to exchguru@win2000mag.com.

The above article is courtesy of Windows 2000 Magazine. Click here to subscribe to Windows 2000 Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to order