Exchange 2000

As different as Microsoft Windows 2000 is to Windows NT, Microsoft Exchange 2000 is to previous versions of Exchange. One of the most dramatic changes is that the Exchange directory has evolved (literally) into Active Directory. Exchange 2000 no longer supports its own directory. Rather, Exchange 2000 relies on Active Directory for all its directory services. This means that if your organization uses, or plans to use, Microsoft Exchange, you should consider the affect your Active Directory design decisions have on your Exchange organization. This section highlights some of Exchange 2000's design considerations for Active Directory.

Overview of Exchange 2000

In previous versions of Exchange, the Exchange directory was the focal point of the core components. Every Exchange component communicated with the directory for information required to fulfill their tasks.

In Exchange 2000, the directory is still a core component of Exchange. However, the objects and configuration that made up the Exchange 5.5 organization are now Active Directory objects. Mail-enabled recipients are Active Directory users, groups, and contacts. The equivalent Active Directory object and Exchange objects are defined Table 18.1.

Table 18.1. Active Directory Object and the Equivalent Exchange Objects

Exchange 4.0, 5.x Object	Active Directory Object
Mailbox	User
Distribution list	Distribution or security group
Custom recipient	Mail-enabled contact

Message transfer between Exchange 5.5 servers was done using RPCs within a site and using a connector between sites. Exchange 2000 no longer relies on RPCs for communications between servers within a site. SMTP is now the protocol used for intra-site communications. This means that every Exchange server is also an SMTP host.

The configuration of previous versions of Exchange was based on an X.500-like directory that consisted of an organization, which contained sites, which contained configuration information, servers, and mail recipients. This design was limited in that the site defined an administrative context as well as a routing context. If there is limited bandwidth between physical locations, sites need to be defined to support a connector, which could control messages between physical locations and compensate for the limited bandwidth. Because the site also defined the administrative context, those physical locations now have administrative boundaries between them, regardless of whether this was desired or not. Exchange 2000 resolves this by breaking apart the administrative and routing contexts. Exchange 2000 incorporates administrative groups and routing groups that, when in Exchange 2000 Native Mode, can be defined separately.

In Figure 18.8, administrative groups are defined based on the administrative model of the organization, whereas routing groups are defined based on the available network bandwidth between sites.

You notice in the preceding example that Exchange 2000 also uses the terms Native Mode and mixed-mode. Like Active Directory, which supports down-level DCs when in mixed-mode, Exchange 2000 when in mixed-mode also supports down-level Exchange servers. Only after Exchange 2000 has been switched to Native Mode can the full functionality of the product be realized.

Administrative Groups

Administrative groups are collections of configuration objects and servers. They can be created based on the administrative model of your messaging environment. In the previous example, in which there are multiple physical locations with limited bandwidths between them, there are three regional IS group locations in their regions. With Exchange 2000, it is possible to define an administrative group for each region, independent of the network and domain topology. By grouping servers and objects together in administrative groups, the administration of those objects can be granted to the appropriate administrators or groups, regardless of the organization's physical topology.

Routing Groups

Although administrative groups group servers and objects together based on an organization's administrative model, routing groups group servers together based on network topology. As with Exchange 5.5 sites and Active Directory sites, the server's within a routing group communicate directly with one another as needed, using SMTP. Servers within a routing group are assumed to have adequate bandwidth between them; therefore, no effort is made to conserve network bandwidth, either through scheduling or data compression.

To connect routing groups, routing group connectors are used. As with previous versions of Exchange, the routing group connectors include X.400 and SMTP connectors. Rather than a site connector, which used RPC, the routing group connector uses SMTP to move messages between routing groups. One or more messaging bridgehead servers, along with a delivery schedule, can be defined for the routing group connector.

Stores

Another advancement with Exchange 2000 is the capability to support multiple stores on a single Exchange 2000 server. This means that instead of having a single 50GB message store for 1000 users, the Exchange 2000 Server could support those same 1000 users on five 10GB message stores (assuming 50MB per user). The main advantage here is that each message store can be backed up and restored independently of the others. If one message store becomes corrupt, the other four stores continue to operate while the fifth message store is being restored. Furthermore, the restore time for that message store would be approximately one-fifth the time of the single 50GB store.

The stores defined on an Exchange 2000 server are divided up into storage groups. There can be up to 15 storage groups per system (plus one hidden used for restore). Each storage group can support up to six message stores, all sharing a single transaction log.

New Services

Exchange 2000 offers expanded functionality in many areas, such as Outlook Web Access and public folders. It also offers additional services, such as Instant Messaging, Video Conferencing, multi-media messaging, and the installable file system, which enables you to mount a network drive to a folder in the Exchange 2000 system, such as your mailbox or a public folder.

Exchange 2000 servers can also be configured to play a particular role in your messaging system. With Exchange 2000, you can configure servers to be protocol servers and message store servers with a front-end/back-end relationship, as in Figure 18.9. Protocol servers accept connectivity from any of the supported Internet protocols, such as POP3 and IMAP4, and forward the packets to the appropriate message store server. This way, you can have a group of protocol servers defined as front-end servers with multiple message store servers as back-end servers. Users need not know what Exchange 2000 server their mailbox resides on, they just need to connect to the front-end protocol server(s).

Design Considerations

Exchange 2000 is the epitome of how an application, which is central to the enterprise, can rely on Active Directory for its functionality. Rather than an autonomous application that runs on top of the operating system, Exchange 2000 extends the functionality of Windows 2000 to provide messaging related services to users.

Fortunately, no major Active Directory design considerations are influenced by Exchange 2000. As it should be, the Active Directory design that fits your organization's business requirements also meets the requirements of Exchange 2000. However, some aspects of each design component should be noted.

Forest Design

Having just proclaimed that Exchange 2000 does not affect your Active Directory design, there is one exception. With previous versions of Exchange, it was possible to have an Exchange organization that spanned multiple sites, which in Windows NT domains were untrusted. As long as a single service account was used for each Exchange site and all the servers within the site were in a domain that trusted the service account's domain, there was no Exchange requirement for trusts between domains that did not span sites.

This scenario is not possible with Exchange 2000. Active Directory is made up of a single Forest that hosts domains that all trust one another. That single Forest is the Exchange organization.

If upgrading this NT 4.0 domain model to Active Directory, you need to re-evaluate why you have multiple domains that are untrusted, and make one of two choices:

Either of these choices will support Exchange 2000. However, if you choose to create multiple Forests, make sure that you and your organization understand the limitations multiple Forests place on Active Directory and Exchange 2000. You also need to develop a coexistence strategy between the two domains that supports message delivery and directory synchronization.

Domain Topology

The domain topology consists of one or more domains in one or more domain trees. The domain tree is defined by the domain name system (DNS) namespace assigned to the domains.

Exchange 2000 user-SMTP addresses are not affected by this namespace. A user in northamerica.wadeware.net can have the SMTP address of [email protected] and [email protected], independent of the DNS domain address.

However, the User Principal Name (UPN), which is a unique name in the Forest and can be used by the user to login from anywhere on the network, is by default [email protected]. This Forest-unique name assigned to each user object enables the user to login without knowing their domain. Some organizations might want to make the user's SMTP address the same as the user's UPN. This way, a user could log into the network using their suspected SMTP address.

Other organizations will want to avoid this. It would go against their security policy to have the user logon alias the same as the user SMTP alias. This would mean that when you know a person's SMTP address, you also know their logon alias. To add complexity to hacking a user account, the SMTP alias and logon alias are different.

Exchange 2000 does not affect the overall domain structure. It is possible to have Exchange 2000 routing groups span domains, with some Exchange 2000 servers in one domain and the rest in another domain, all within the same routing group.

OU Design

OU's are also Active Directory components that are not affected by Exchange 2000. User and computer locations within the domain are irrelevant to Exchange 2000. However, for organizational reasons, you might want to group all your domain's Exchange servers in an OU within your OU structure.

Outlook users, who use the Outlook Address Book, do not see OU's. Rather, Address Book lists are maintained by Exchange 2000 and are used by Outlook users to locate mail recipients. Address Book lists are built and managed by Exchange 2000, using LDAP filters. Several Address Book lists are pre-built and installed with Exchange 2000, and you can easily design your own custom Address Book lists.

Site Design

Active Directory sites are also, for the most part, unaffected by Exchange 2000. The design considerations that go into deciding what Active Directory sites to create also go into deciding what Exchange 2000 routing groups to create. The principals of Active Directory sites and Exchange 2000 routing groups are similar.

Exchange 2000 data conferencing services do assign a conference manager per Active Directory site. You can designate multiple conference managers within an Active Directory site. However, this is done only for redundancy purposes; only one conference manager can be active at a time.

Service Location

Remember that Active Directory clients require access to DNS, Active Directory DCs, and Global Catalog (GC) services to be authenticated by Active Directory. These same services are required for clients to access Exchange 2000 messaging services.

Exchange 2000 servers also need access to these services. As they communicate with one another, authentication, server location, and group expansion all require access to DNS, DCs, and GC services.

Make sure you place adequate services within close proximity to Exchange 2000 servers and clients.

Schema Modifications

Exchange 2000 makes approximately 650 changes to the Active Directory schema. These changes are made when the first Exchange 2000 server is installed in Active Directory. Additional attributes are also added to the Global Catalog (GC). This means that the Active Directory schema and configuration partitions need to have to replicate these changes throughout the Active Directory Forest. Hence, the first Exchange 2000 server should be installed at a time when the infrastructure can handle this amount of replications.

Another option is to run the Exchange 2000 setup with the /schemaonly switch. This switch does not install Exchange 2000, but only makes changes to the schema and configuration. Therefore, if your organization is going to implement Exchange 2000 after Active Directory has been deployed, it might be prudent to run the Exchange 2000 setup with the /schemaonly switch after the first few DCs have been implemented. This makes the Exchange 2000 modifications to the schema and configuration early so that as additional DCs and GC servers are implemented, these changes can be contained in the initial copy of these database partitions. Then, when you are ready to implement Exchange 2000, all DCs and GC servers have the changes necessary to support Exchange 2000.

Group Design

Exchange 2000 uses Active Directive groups for group messaging. Active Directory has both security groups and distribution groups. Both types of Active Directory groups contain users, contacts, and other groups. Both types of groups can be mail recipients, which means that you can send mail to both security and distribution groups. Security groups, however, can also be assigned permissions on network resources. This means that your group structure within Active Directory can be simplified. You don't have to create a distribution list for engineers and a Windows NT Group for engineers, and then maintain both. You can create a single security group, engineers, and assign it permissions on network resources and send messages to it. You want to make sure that you don't inadvertently grant a user permission to resources if you really intended them to be a member of the messaging group. Remember, if you put a user into a security group, not only will they receive messages mailed to that group, but they will also have access to the resources granted to that group.

There might also be groups of users for whom you want to group together only to receive messages and not to assign permissions. For these groups of users, you would use a distribution group.

The three types of groups, domain local, domain global, and universal groups can all contain different objects when in Active Directory mixed-mode or Active Directory Native Mode. Understanding the way that your organization uses groups is likely to be taken care of outside of Exchange 2000. When planning for Exchange 2000, you might need to add distribution groups, or even, security groups to supplement the group structure required to administer your Active Directory environment.

Universal groups are the most flexible of the groups. However, universal group membership is visible between domains. This means that the universal group's membership is published to the GC. Therefore, if you have a universal group with 1000 users that changes frequently, those changes are going to be replicated to all GC servers in the organizations. Global Groups, on the other hand, do not publish their membership to the GC. This means that users mailing to a global group from another domain are not able to see who is in that group. Hence, those groups whose membership is static and which needs to be visible across domains are a good fit for a universal group. Those groups whose membership is dynamic or which does not need to be visible across domains are a good fit for Global Groups.

Coexistence with Exchange 5.5

Exchange 2000 coexistence with Exchange 5.5 encompasses Active Directories coexistence with Exchange 5.5. This means that after you have established coexistence between Exchange 5.5 and Active Directory, using the ADC, extending that coexistence to include Exchange 2000 is not that complicated because the directories are already coexisting.

The Exchange 2000 Active Directory Connector

The user portions of the directories are coexisting, through the ADC, with a connection agreement. Exchange 2000 also requires coexistence between the configuration of Exchange 5.5 and Exchange 2000. This is accomplished with another type of connection agreement. The Exchange 2000 version of the ADC supports a configuration connection agreement that synchronizes the configuration of Exchange sites with the configuration of the Exchange 2000 administrative/routing groups.

This means that, before you install Exchange 2000 into an Exchange 5.5 site, you must have the Exchange 2000 version of the ADC installed. The Exchange 2000 setup program automatically configures a configuration connection agreement between the Active Directory domain and the Exchange 5.5 sites, as in Figure 18.11. This configuration connection agreement synchronizes the configuration of Exchange 2000 with all the sites in the Exchange 5.5 organization.

The Site Replication Service (SRS)

The SRS is another piece of the coexistence puzzle. The SRS, for all practical purposes, is the Exchange 5.5 directory running on the Exchange 2000 server. This directory is only used to coexist with other pre-Exchange 2000 servers in the same organization.

When Exchange 2000 is installed into an Exchange site, the SRS accepts directory changes from other Exchange servers in the site. The ADC's configuration connection agreement then takes those changes and replicates them up to Active Directory.

The SRS can also accept changes from other Exchange sites. If the Exchange 2000 server is configured as the directory-replication bridgehead server for the site, it receives directory replication messages from other sites, and then replicates those changes, via RPC, to the other directory services in the site. Meanwhile, the ADC takes those changes from the SRS and synchronizes them up to Active Directory (see Figure 18.12).

Thus, when installing an Exchange 2000 server into an Exchange site, making that server the directory replication bridgehead for the site makes directory replication to Active Directory more efficient.

Server Access

Exchange 2000 server uses GC services for many things. To reduce the burden on the GC servers in an organization, the Exchange 2000 server supports a directory access cache, DSAccess. If an Exchange 2000 server accesses the GC, the response is cached for a time (10 minutes). This helps reduce the burden placed on the GC servers by Exchange 2000.

Client Access

How Exchange 2000 clients access Active Directory depends on the client. The directory service proxy, DSProxy, process manages Exchange client access to Active Directory. If the Exchange 2000 system attendant starts, it uses DNS to locate a GC Server, which is then passed to DSProxy. DSProxy then acts on behalf of Exchange and Outlook97/98 clients that are accessing the Address Book by proxying the query to Active Directory. DSProxy refers Outlook 2000 and later MAPI clients to Active Directory for Address Book queries. After Outlook 2000 has been referred to an Active Directory server, the GC server is written to the client profile and all subsequent Address Book queries uses that Active Directory server.