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