In-Depth

Major Messaging on Exchange 2000

Exchange 2000 is as different from Exchange 5.5 as Windows 2000 is from NT 4.0. This feature briefing will bring you up to date on this big new release.

• By Bill Wade
• June 01, 2000

As everyone knows, Windows 2000 is a significant upgrade to Microsoft’s cornerstone operating system. But the fundamental improvements in Win2K have another side—BackOffice products can reap the benefits of its rich new features. Nowhere is this more evident than in the next version of Microsoft’s messaging system. Exchange 2000 makes a great leap forward in Microsoft messaging technology, taking advantage not only of Windows 2000 (to such an extent that it requires Win2K Server to run—no Windows NT for this product), but also improving existing functionality and adding additional messaging services. In this article, we’ll show you some of the highlights, based on Release Candidate 1.

AD: A Good Thing for Exchange

One of the most significant new services provided by Windows 2000 is Active Directory, the distributed, standards-based directory that is the security subsystem of Win2K. This full-functioning directory service provides a central source for enterprise directory information. Here’s evidence of the fact that Exchange 2000 takes full advantage of AD—Exchange no longer has its own directory. Rather, all directory services, both mail recipients and configuration information, are stored in AD. Is this a good thing? Absolutely! Let’s look at why.

First, functionality. In addition to the operational impact of having a single repository for enterprise data, there are several key technical benefits of AD. Those include granular access control, an extensible directory schema, and improved lightweight directory access protocol (LDAP) support.

Next, granular access control. With AD, each object has its own access control list (ACL). This allows you to set the permissions for each object and in turn control access to the directory at a detailed level. With this capability, you as the Exchange administrator can store important information in the directory that can be accessed only by certain users, administrators, or applications. For example, as employees come and go, you may want your Human Resources department to create and delete users in AD. However, you don’t want HR personnel to be able to add additional SMTP address definitions for users, or to change a user’s storage limits. AD lets you define attribute-level access for this type of security structure.

Schema extensibility is another plus. AD schema extensions are available for use with Exchange applications, users and other programs in the enterprise. The advantage of a single directory schema such as that used by AD, Exchange, and other enterprise applications is the commonality it brings to different applications.

And then there’s performance. By having a single directory across the enterprise that provides directory services to multiple applications, you’ll experience an overall increase in performance and efficiency.

In Windows NT 4.0 and Exchange 5.5 environments, there are two directories: the NT domain directory and the Exchange 5.5 directory. Each replicates information to different servers in a variety of ways. As a single directory, AD eliminates this unnecessary redundancy. Furthermore, AD can be segmented into multiple domains, with a Global Catalog providing insight across domains. This gives organizations the opportunity to control where domain data is replicated, while still giving applications and users access to other domain data via the Global Catalog. This contrasts with Exchange 5.5, where the entire Exchange 5.5 directory is replicated to every Exchange server in the organization. Last, AD replicates attribute level changes, whereas Exchange 5.5 replicates at the object level. This means an overall reduction in the amount of replication traffic when you compare similar Exchange 5.5 and Active Directories.

Ease-of-use is another argument for incorporating AD in Exchange 2000. Using AD as a directory service provides a single administrative framework for the enterprise. AD users, managed through the Active Directory Users and Computers MMC snap-in, include Exchange 2000 attributes. This means that a single tool can be used to manage AD users and Exchange mailboxes. With this type of framework, a line has been drawn between Exchange recipient management and configuration management. Recipient management is done through AD management tools, whereas Exchange configuration management is done through Exchange management tools.

Finally, consolidating directories can simplify things greatly under AD. Consolidation unifies objects of similar type; the most obvious is the user object and the mailbox object. Others include Exchange distribution lists that have become AD mail-enabled groups. Exchange custom recipients have become AD mail-enabled contacts. Unifying these objects has several advantages. For example, with Windows NT 4.0 and Exchange 5.5, if a user joined the Engineering group of an organization, the NT administrator would have to add the user to the NT group Engineering to grant the user access to Engineering resources. The Engineering distribution list manager would have to add the user to the Engineering distribution list. When using AD, the user would only have to be added to the mail-enabled security groups Engineering to have access to Engineering resources and to receive messages sent to the Engineering group.

Architectural Changes

Along with moving its directory to Windows 2000, Exchange has undergone several other significant alterations. These include architectural changes that affect how messages are stored and transported across the enterprise.

Information Stores

In Exchange 5.5, a single information store service manages two information stores, one private and one public. There’s no practical limit to the size these information stores can reach. (Well, actually, there’s a 16-terabyte limit.) Consequently, Exchange information stores can grow quite large if unchecked and can be the limiting factor that requires multiple servers. The information store can grow so large that it can’t be backed up or restored from backup in a reasonable amount of time.

With Exchange 2000, it’s possible to have multiple public and private information stores on a single server. This means that very large Exchange 5.5 information stores can be divided into multiple Exchange 2000 information stores, which can be mounted and dismounted, backed up, and restored independently of each other.

Figure 1. MAPI, which isn't technically a protocol, allows for client access directly to the information store.

Information stores are divided into storage groups. With Exchange 2000 Release Candidate 1, there can be up to four storage groups per Exchange 2000 server. (It was possible to have 15 storage groups in Exchange 2000 beta 3, but that number appears to have been reduced for the final product.) Each storage group has a single set of transaction logs for the information stores in that storage group.

Each storage group can host up to six information stores. However, Microsoft recommends that no more than five information stores be created per storage group. When the Exchange database utility ISINTEG is run, it needs to be able to mount a temporary information store in the storage group. If six information stores exist in the storage group, one of the other five information stores will have to be dismounted before ISINTEG can run against the troubled database.

As with previous version of Exchange, Exchange 2000 offers a variety of client access methods to the information store:

• NNTP: Before you can install Exchange 2000, you must have installed NNTP on the Win2K server. NNTP provides NNTP clients access to public folders. You can create discussion threads to specific public folders for external use; internal users can access the public folder with Outlook 2000 or Outlook Web Access.
• SMTP: Exchange 2000 uses SMTP as its primary protocol for moving messages throughout the organization. Exchange 2000 extends the Windows 2000 SMTP stack to support Exchange-specific commands for communicating routing information and more.
• HTTP, POP3, and IMAP: As with previous versions of Exchange, POP3 and IMAP4 client access is supported. However, POP3 and IMAP4 have moved out of the information store and to Internet Information Server 5.0.

Protocols

Another significant architectural change to Exchange 2000 is in the area of transport protocols. In Exchange 5.5, most client access protocols were hosted in the Information Store. With Exchange 2000, client access has been moved from the information store to IIS 5.0.

Front-end/Back-end Servers

Here’s an added benefit of having IIS host the protocol stacks for Exchange 2000: the ability to define Exchange 2000 front-end and back-end servers. This configuration offers a new concept for Exchange: the ability to route client traffic (except MAPI). An Exchange 2000 front-end server relays client access protocols (again, except MAPI) to the appropriate back-end server. This way, a user need only know the name of the front-end server that will route the client protocol to the user’s back-end server.

Dismantling Sites

Up to this point, Exchange sites have defined three important components of product design. Site boundaries define:

• How messages are routed through the organization (point-to-point between servers within a site and across connectors between sites).
• A security context. Sites are a primary security context, used to apply an administrative model to the messaging environment.
• A portion of the namespace. Sites, under Organization, are a building block for the Exchange X.500-like directory.

Each of these components is evaluated when you’re defining an Exchange site topology and may have different and conflicting design considerations. The best site topology for messaging routing may be very different than the ideal site topology for administering the messaging environment—yet there can be only one site topology.

Exchange 2000 breaks up the concept of a site into three individually designed and manageable components, as shown in Figure 2. With sites broken up into separately configurable components, Exchange 2000 offers much more configuration and management flexibility. (The amount of flexibility depends on whether Exchange 2000 is running in Native Mode or Mixed Mode. To support coexistence, Mixed Mode Administrative Groups and Routing Groups are coupled to closely resemble Exchange Sites.)

Figure 2. Exchange 2000 has dismantled the Exchange site into Routing Groups, Administrative Groups, and the Active Directory namespace.

Administration the Way You Want It

Exchange 2000 configuration objects are divided into manageable groups called Administrative Groups. Objects such as servers, public folder trees, policies, and routing groups are assigned the same ACL permissions as the administrative groups they’re contained in. You can create administrative groups, independently of routing groups, to implement the administrative model you want (when in Exchange 2000 native mode).

Microsoft Management Console

Gone is the Exchange Administrator tool. As with all Windows 2000 applications, the Microsoft Management Console (MMC) is used to administer Exchange 2000. A series of snap-ins allows for varied administrative interfaces that you can customize for various tasks. An added bonus is right-click menus, as shown in Figure 3.

Figure 3. The Exchange System Manager (a set of MMC snap-ins) replaces the Exchange Administrator tool.

Administrative Group Rules

There’s less flexibility with Exchange 2000 RC1 Administrative Groups than there was in Beta 3. Servers must be installed in an Administrative Group and can’t be moved between administrative groups. The administrative group into which a server is installed is used to build the server’s distinguished name (DN). Changing the DN of a server, or any object for that matter, is no trivial task. This functionality was introduced in Exchange 5.5 Service Pack 2; Microsoft plans to offer a similar tool after Exchange 2000 is released.

Administrative Group Strategies

New to RC1 is the Administration Delegation Wizard. This wizard steps you through applying permissions to the administrative group, as shown in Figure 4. With this tool, you can take an administrative model that fits your organization and apply it to the Exchange 2000 portion of AD.

Figure 4. The Administration Delegation Wizard steps you through applying security to your Exchange organization.

Administrative Groups offer flexibility that will allow organizations to re-evaluate how they’re currently managing their messaging environments. For example, many organizations have a central IS group that’s responsible for the overall administration of the messaging structure. There are additional administrative roles at remote locations that are responsible for the local servers, public folders, and the like. In this type of environment, it’s possible to create an Administrative Group for the central IS group that contains all Routing Groups, Public Folder hierarchies, and policies for the organization. (Note that the server can only reside in a routing group outside the Administrative group when Exchange 2000 is in Native Mode.)

Only administrators in this group would be able to manage routing groups, their connectors, and so forth. The remote locations would then have their own Administrative Groups, containing their local servers, allowing those administrators to perform local administration of those objects. This is shown in Figure 5.

Figure 5. An Exchange 2000 administrative model that centralizes routing groups and public folder hierarchies in a centralized Administrative Group, with remote Administrative Groups managing only local servers.

Routing the Way It Should Be

As administration has moved to Administrative Groups, message routing in Exchange 2000 has moved to Routing Groups. Routing Groups perform message routing similar to how it was performed with Exchange sites. Messages are sent point-to-point between servers in the same routing group and are routed across connectors between routing groups. There are three main differences in the way message routing works in Exchange 2000:

• SMTP is the primary transport between Exchange 2000 servers in a routing group, rather than RPC.
• The preferred connector is the Routing Group Connector. In the spirit of the Exchange 5.5 Site Connector, multiple bridgeheads can be defined in each routing group. However, SMTP is again used to transport messages, rather than remote procedure calls (RPCs).
• The routing and selection process is greatly enhanced by a Link State Algorithm (LSA). LSA allows each Exchange 2000 server to select the most efficient route available to deliver messages.

The use of SMTP between servers within a routing group will likely change the criteria by which routing groups are designed, when compared to Exchange sites. It’s unnecessary to have the bandwidth between servers within a routing group to support RPC. Rather, routing groups will be designed to control message flow. Routing Groups also dictate Public Folder access. Clients will search for an instance of a given public folder in the Routing Group for which the user’s mailbox resides. Searching for the instance of a public folder across routing groups is defined at the Routing Group Connector.

Link State

Each Exchange 2000 server knows the status of all connectors in the organization—whether each is up or down. Unlike previous versions of Exchange, a server sending a multi-hop message knows that all connectors are up between its routing group and the destination routing group. If there’s no route available because a connector two hops away is down, the server queues the message until the route becomes available.

All this is accomplished with the help of an algorithm with its roots in network packet routing. Each server hosts a Link State database. One server in the routing group is designated as the Routing Group Master. When a connector fails, the bridgehead that discovered the failure notifies the Routing Group Master (TCP port 691). The Routing Group Master then notifies all other Exchange 2000 servers in the routing group. If any of these servers is a bridgehead to other routing groups, they in turn notify the bridgehead in the opposing routing group (TCP port 25). That bridgehead then notifies its Routing Group Master, and so forth. The failed connector state is thus propagated throughout the organization (see Figure 6).

Figure 6. When a connector fails, link state information is passed to the routing group master, which in turn notifies all Exchange servers of the failure. Bridgehead servers notify bridgeheads in other routing groups of the failure.

Traditional Exchange site topologies have been hub-and-spoke, to avoid message ping-ponging between sites. With LSA, Routing Groups can be designed in a full-mesh topology without messages bouncing between routing groups looking for an available route.

Improved Services

Regarding services, little has gone untouched in RC1 of Exchange 2000. As you can see from the change in architecture, most components were enhanced during this upgrade process, and many others completely rewritten. Some of the highlights are included below.

Outlook Web Access

One component that underwent a great deal of development was Outlook Web Access (OWA). Introduced in Microsoft Exchange Server version 5.0, OWA provides access to Exchange Server information from Microsoft Internet Explorer or other HTML browsers.

The enhancements to OWA in Exchange 2000 increase performance and scalability. This was accomplished through major architectural changes on the server as well as the client when using IE 5.0. These enhancements include:

• Support for XML and Dynamic HTML. This allows some functions to take place at the client rather than the server, which increases performance and gives OWA a closer look and feel to Outlook 2000.
• Support for an extended version of HTTP named WebDAV (Distributed Authoring and Versioning, RFC 2581).
• Support for embedded items and ActiveX objects.
• Support for public folders that contain Contacts and Calendar items.
• Friendly URLs. User mailboxes, personal folders, and public folders can be accessed with a simple URL.
• Support for multimedia messages, including video (in RC1).

OWA is not Outlook 2000. While it can be very useful to roaming and remote users alike, it still lacks many of the features found in Outlook 2000. These include digital encryption and signature support, inbox rules, message searches, and three-pane views. You can view and create calendar items, but much of the calendar functionality found in Outlook 2000 isn’t available (such as appointment list views, free and busy details, meeting attendee acceptance, multi-day and all-day events, task lists, and exporting data).

New Services

Along with improvements in existing services, Exchange 2000 has several new communication services. These services provide expanded access to data stored on Exchange servers and increased methods of communication beyond simple messaging.

Web Store

Exchange 2000 databases are exposed to the file system through the Exchange Installable File System (EXIFS). This means that folders in Exchange 2000, such as a user’s inbox or a public folder, can be mapped to a network drive. That sounds simple enough, but it could change the way Exchange is used in many organizations. Rather than having Web servers hosting data accessed by Web browsers, file servers hosting data accessed by network clients, and messaging servers hosting data accessed by Outlook, all these clients can access data hosted in the Web Store. Furthermore, when this data is located in a public folder, it can be replicated around the organization to provide efficient, reliable access.

How the Web Store will be used (and what its final name will be) in the shipping version of Exchange 2000 is yet to be seen. Having it there strengthens Exchange as an ideal platform for knowledge management and collaborative applications, since it increases the means for getting to data.

Instant Messaging

Instant Messaging (IM) is thought by many to be for the casual AOL or Internet user trying to avoid long-distance phone calls. However, many corporate organizations are realizing the advantages of Instant Messaging; it allows users to see “presence” information about other users. That information can include whether someone is online, online but inactive, busy, or out of the office. Instant Messaging is real-time—meaning communication between users happens immediately. This makes it ideal for ad hoc or urgent communication. For example, Edgar may have a workstation at his desk, a laptop he takes to meetings, and a home computer, all on the corporate network. If Bill needs to get an answer to an important question from Edgar, Bill can see if Edgar is online. If Edgar is online, say in a meeting with his laptop, Bill can initiate an Instant Message to get his question answered.

Exchange 2000 uses the Rendezvous Protocol (RVP) for Instant Messaging. Using this protocol and the presence database, an organization could create a custom application that sends an urgent message to everyone online. Note that Instant Messages aren’t stored—once the Instant Messaging session is closed, the messages are gone.

Data Conferencing Services

In addition to Instant Messaging, Exchange 2000 provides data conferencing services. The Microsoft Exchange 2000 Data Conferencing Server gives users the ability to hold multi-user Web browser-based conferences that include video, audio, shared whiteboard, direct file transfer, and chat.

Data Conferencing services are divided into two categories; multi-cast services based on TAPI 3.0 that will provide audio and video sessions, and T.120 services, which provide everything else. In RC1, data conferencing rooms are created using the Exchange System Manager. Outlook 2000 users can schedule other users and the data conferencing room for an on-line conference. When the conference time arrives, the Outlook 2000 users simply right-click on the calendar item and choose Join Conference. A Web browser is opened and the user joins the conference (see Figure 7). This will be a separate product when Exchange 2000 is released, but won’t be included in Exchange standard or enterprise edition.

Figure 7. The MSN Messenger is the default Instant Messaging client for Exchange 2000.

Big Differences, Big Payoff

Exchange 2000 is as different from Exchange 5.5 as Windows 2000 is from NT 4.0. Therefore, it’s important to learn as much as you can about this product, set up a lab for testing, and carefully plan upgrade paths and coexistence scenarios before initiating your Exchange 2000 deployment. Microsoft is committed to making deployment of Exchange 2000 as painless as possible. There are already numerous white papers available at www.microsoft.com/exchange on the various components that make up Exchange 2000. Take the time to educate yourself so you can enjoy working with this outstanding messaging system.