The Exchange Design

After outlining the business and technical requirements and documenting your current mail and messaging infrastructure, the actual Exchange design work begins. You are now ready to plan the new messaging system, taking into account what level of service your current messaging system is providing and what your new requirements are.

One of the first steps of the design process is to perform a gap analysis of your existing mail and messaging systems and what you have outlined as your business requirements for your deployment.

During the design process, tradeoffs have to be made between cost and functionality. Your project manager might need to balance the needs of the end users with the cost of implementation and keep the project moving within the designated timelines and cost structures.

The business requirements, AD design, network topology, current messaging system, and security requirements all drive the final Exchange 2003 design.

Design Considerations

Again, with one chapter it's difficult to discuss in any detail the complete complexities of any design. Because AD is so critical to an Exchange design, you do need to understand, at least at a high level, how Exchange operates with, and in, an AD forest.

Best practice is to deploy Exchange in a single forest, but that is not the only option, as you'll learn as you read this section

Design Considerations: AD Impact

Exchange 2003 requires AD and it does, in fact, extend the AD schema. In short, this means that objects in AD (for example, users and contacts) are modified in a way to allow them to hold attributes associated with Exchange services. At a high-level, Exchange 2003 uses AD to

• Tag objects that are mail-enabled

• Tag objects that are mailbox-enabled

• Store configuration information about the Exchange organization

None of this can take place without the Exchange 2003 schema extensions. In fact, even if you currently have Exchange 2000 deployed, you need to apply the Exchange 2003 schema extensions via /ForestPrep and /DomainPrep .

ForestPrep

There's no way around running the Exchange 2003 ForestPrep utility. This utility modifies the AD schema and can be executed either from SETUP.EXE, using the /ForestPrep qualifier, or via the newly introduced ExDeploy facility, a guideline to deployment and migration of Exchange 2003.

The account from which you run ForestPrep must possess particular permissions and must be a member of the following groups:

• The Enterprise Administrators

• The Schema Administrators

• The Domain Administrators

• The Local Machine Administrators

During the execution of ForestPrep, you must designate a Windows account that will be the base account from which you will delegate other accounts to be used to install and manage subsequent Exchange 2003 installations. This base should be created in advance and, as stated, you will use it as the account from which you will run the Exchange Administration Delegation Wizard to assign specific Exchange administration roles to other Windows administrative accounts.

note

ForestPrep must be executed in the same domain, not necessarily the same server, as the schema master. It is a best practice to perform ForestPrep on the schema master because the process needs to contact the schema master anyway, and if you do want to update the schema remotely, a Registry key must be set to allow this to happen. So, overall, it's just easier to run ForestPrep on the schema master; assuming you have access to it.

DomainPrep

In addition to running ForestPrep, you must also run the Exchange 2003 version of DomainPrep. DomainPrep performs a number of functions, specifically creating the Exchange Domain Servers Global Security Group and the Exchange Enterprise Servers Local Security Group . As Exchange servers in a domain are installed, they are added into these groups, and the membership allows the Exchange server to read and to modify user and configuration information.

DomainPrep also creates the Public Folder Proxy container in each domain in which it is executed. The Public Folder Proxy object is basically an entry in the AD that holds the e-mail address associated with a Public Folder so that you can send mail to the Public Folder(s). These proxies are held in the Public Folder Proxy container.

DomainPrep must be executed in every domain that will contain an Exchange 2003 (or Exchange 2000) server and every domain that holds mail-enabled objects ”that is, Exchange mailboxes or contacts with Exchange addresses associated with them. Further, any domain containing a GC/DC that you want to expose to Exchange (through DSAccess) also needs to run DomainPrep. Additionally, Exchange 2003 (and Exchange 2000 before it) is hard-coded to expect to see the Public Folder Proxy container in the root domain of the forest, so you must ensure that DomainPrep is executed in the root domain also.

tip

The account from which you execute DomainPrep must be a member of the Domain Administrators group and the Local Machine Administrators group.

Configuration Naming Context (NC)

The Configuration NC holds configuration information from your environment. This includes the configuration of Exchange. The Configuration NC is automatically replicated to all DCs within your AD, as is the Schema NC. Therefore, it should be clear that any changes to the schema or to the Exchange configuration will result, and therefore be dependent upon, the efficiency and speed of the replication topology of AD.

Best practices recommend preparing in advance the ForestPrep and DomainPrep operations as soon as the basic AD infrastructure is in place.

Design Considerations: Single Forest

Because of the information we've just covered, the easiest and most common deployment of an Exchange 2003 organization is in a single Windows AD forest. A single forest deployment provides the richest user experience while maintaining a simplified administrative structure. Exchange 2003 can be deployed in single-or multidomain forests. The only requirement is to be sure to run DomainPrep in any domain that will host Exchange servers, and mailbox-or mail-enabled objects. In addition, if your AD structure contains a root domain, DomainPrep must be run there as explained earlier.

Design Considerations: Multiforest/Multiorganization

For a variety of reasons, you might find yourself in a situation where you have multiple AD forests. The reasons can be because of unplanned circumstances, such as those associated with mergers or acquisitions. There are times when you will plan to have multiple forests as well, such as service autonomy or true separation of services due to security concerns. In either case, you must be aware of the tasks associated with providing a seamless environment.

Before moving on, let's be clear about one thing. If you are planning to collapse multiple organizations into one, then you are dealing with a migration scenario. The topics we discuss in this section are related to maintaining multiple forests and making the best out of a nonoptimal situation. Even given this huge caveat, this topic cannot be done justice in a single chapter covering Exchange 2003, so refer to one of the books mentioned previously for more information.

Because an Exchange 2003 organization is tightly coupled to an AD forest, deploying multiple Exchange 2003 organizations in multiple forests requires you to perform tasks that are normally provided out-of-the-box in a single Exchange organization. These tasks include

• Mail connectivity

• Directory synchronization

• Sharing Free/Busy and Public Folder information

• Preparing for one-off (single or few user) migrations

• Preserving the OSTs (Offline Stores)

These tasks are not overly difficult, but are the keys to providing a rich user experience.

Mail Connectivity

Mail connectivity between organizations is fairly easy to accomplish. Your primary choice here is probably SMTP. X.400 is also perfectly acceptable. The main concern here is name resolution. If the two organizations will share the same namespace, such as company.com, then you must define and satisfy uniqueness in the left-hand side of the address. The typical example here is having two individuals named John Smith, one in each organization. Assuming you want to have everybody represented with the same domain name, you must find a way to differentiate addresses based on the name portion of the address.

Directory Synchronization

One basic requirement in a multiorganization deployment is having a common directory. To accomplish this, some sort of directory synchronization is required. The synchronization, in its simplest form, represents users in one forest as contacts in the other forest; and vice-versa. The easiest way to accomplish this synchronization is by using a tool designed specifically for this purpose. Some tools to consider are HP's LDAP Directory Synchronization Utility (LDSU) or Microsoft's Identity Integration Server 2003 (MIIS), or the stripped-down version called Identity Integration Feature Pack.

Both tools, LDSU and MIIS, are extremely powerful and can be used in scenarios far more complex than simple directory synchronization, such as provisioning or more complex metadirectory scenarios.

Other tools that can handle simple synchronization are available from companies such as CPS Systems (SimpleSync) and Imanami, to name a few.

Free/Busy and Public Folder

If Public Folder and Free/Busy information needs to be shared between organizations, about the only game in town is the Inter-Organization Public Folder (IOPF) utility, available from Microsoft. For those that have used this tool in the past, you might remember that it wasn't supported and results were inconsistent. With Exchange 2003, this tool is now officially supported, but is still a bit of a hit-and-miss tool. What I mean by hit-and- miss , is that some implementations seem to be flawless, whereas others seem to be less than optimal. Again, to follow our ongoing theme, you need to test the tool in your environment and determine how well it satisfies your needs.

note

It's important to note that Public Folders have not changed significantly in Exchange 2003. A few enhancements have been made ”for instance, the ability to view Public Folders from ESM and the Public Folder Migration Utility (PFmigrate) ”but essentially they are the same as they've been since the initial release of Exchange. Given the popularity of the Web and tools from Microsoft, such as SharePoint Portal Server and Windows SharePoint Services, it might be a good time to start considering other document collaboration tools outside of Exchange and, specifically, Public Folders. The one real advantage of Public Folders in Exchange is replication. That might be the only compelling reason to continue to use this technology.

One-Off Migrations

If you are maintaining multiple Exchange organizations, then you probably won't want to spend the money on one of the excellent , but pricey, migration tools. Remember, we're talking about maintaining multiple organizations, not collapsing or migrating entire organizations.

Still, you will run into situations where you will need to migrate a user's mailbox from one forest to another. One reason might be a job transfer of a person from one part of the company to another. Whatever the reason, you need to understand what to do to perform the migration.

First, Microsoft provides a new and improved Mail Migration Wizard (mailmig.exe) in Exchange 2003 that can move mailboxes from one Exchange organization to another. This utility is straightforward and works well regardless if the source organization is Exchange 5.5 or newer version of Exchange. The tool allows you to select objects from the source organization and, as you would expect, to accomplish this first step, you need to establish trusts between the forests (or domains if your source is Exchange 5.5).

One of the nice features of the mail Migration Wizard is that it will merge a source object with an object in the target organization. The merging, or matching, is accomplished by matching the e-mail addresses of the source object with e-mail addresses of objects in the remote forest. If no match is found, then a new, mailbox-enabled, disabled user object is created in the target forest.

note

The mail Migration Wizard does not delete the mailbox of the migrated user from the source forest. In fact, it doesn't touch that object at all. This means that after your user is happily operating in the new organization, you need to clean up the account and mailbox information in the original organization. Of course, because the information in the source forest is not touched, you do have an easy "back out" plan if something goes wrong.

You might ask the question "How would there ever be a match?" Remember, we've already established directory synchronization between the forests, so there will be contacts in the target forest that represent user objects in the source forest.

Preserving OSTs (Offline Stores)

Another nice feature of the new mail Migration Wizard in Exchange 2003 is something called Clone Mode . Under normal circumstances, if a user with an Outlook OST is migrated from one organization to another, the current OST becomes unusable and needs to be rebuilt. The reason for this is that the OST is tagged with an attribute ( mAPIEntryID ) that matches the mailbox in the organization to which the user belongs. If the mailbox is migrated, the new mailbox created in the new organization changes and, therefore, the mAPIEntryID on the OST won't match the new mailbox.

The Clone Mode feature of the mail Migration Wizard preserves the OST by tagging the new mailbox with the old mAPIEntryID and, therefore, allows a match between the OST and the mailbox.

tip

Don't forget that your now-migrated user needs to resolve the names of the servers in the new forest. So there's more work involved here other than strictly Exchange-related tasks; DNS, WINS, and desktop migration might also be necessary. Options for account migration are additional tasks that need to be considered even before the migration takes place.

Design Considerations: Resource Forests

Another option, despite the relative lack of information about it, is to deploy Exchange 2003 in the exact same scenario that many companies deployed Windows NT 4.0 and Exchange 5.5: in a resource forest.

The concept is just as you would expect. You deploy Exchange in a Windows forest that is strictly used for Exchange servers and mailboxes, and associate accounts that live in an account forest with accounts/mailboxes in the resource forest. To accomplish this, you need trusts set up between the forests, just as you did in the Windows NT 4.0/Exchange 5.5 scenario.

A few things to keep in mind:

• The GAL will be supplied by the Resource Forest . Remember, that's where Exchange sits, and Exchange will use GC servers and DCs from its own forest, the resource forest. If you want to have a rich set of attributes associated with the accounts in the resource forests, and those rich attributes (manager, title, phone, and so on) reside only in the account forest, then you will need some level of synchronization between the forests in order to populate those attributes. If you aren't interested in that rich information and are just looking for e-mail, you will not need that synchronization.

• The user's Outlook profiles must be able to resolve the names for the Exchange servers, and potentially the GCs in the resource forest (depending on the version of Outlook), so name resolution between the account forests and the resource forest will need to be integrated.

• You will actually create disabled, mailbox-enabled accounts in the resource forest. Remember, the user will authenticate into the account forest.

After the mailbox-enabled, disabled user is created in the Exchange forest, access to the mailbox for the corresponding account in the account forest must be granted. The following rights must be set up to grant the user access to the mailbox:

• Read permissions

• Full mailbox access

• An associated external account

Once completed, the user account in the account forest can access the mailbox in the Exchange forest.

note

Because the accounts ( sAMAccountName ) must be unique in each forest, it's considered a best practice to name the accounts exactly the same in the resource and account forests. This will ease administration and ensure uniqueness.

One of the advantages of the resource forest is that you can happily go about your Schema changes (via ForestPrep) in that forest without impacting the operational/production forest used for authentication. The major disadvantage is that you inherently have more moving parts and will have more to manage.

Exchange 2003 Administrative Model

You've decided on your forest model, so now it's time to look at the structure of Exchange 2003. Like AD, Exchange 2003 can be managed either centrally or distributed. The Exchange administrative model is independent of the AD model.

Exchange administrators must be granted permissions in AD to add users or modify attributes (home server, phone number, and so on). Conversely, domain administrators, or any user being granted permission to Exchange, need to be added to the appropriate Exchange AGs to modify routing, recipient policies, and so on.

Another example of this independence is that if you have a distributed administrative model in AD; that is, you have multiple domains, you could still have a single Exchange 2003 AG. Conversely, you could have a single Windows AD model and a much delegated, broadly deployed Exchange AG structure.

Delegation of Exchange Administrative Permissions

Because of the division of administrative privileges, you must delegate the appropriate rights in both AD and the Exchange administrative Microsoft Management Console (MMC) to the appropriate groups, as shown in Table 12.3. In Exchange 2003, when delegating permissions, you can choose to delegate a user or group one of the following three out-of-the-box roles within the organization:

• Exchange Full Administrator : Allows the holder or group to completely administer Exchange 2003 servers, including setting permissions.

• Exchange Administrator : Allows the holder to fully administer Exchange 2003 server information except permissions.

• Exchange View Only Administrator : Allows the holder to view Exchange Server information.

Table 12.3. Exchange Administrator Roles

Role	Right
Exchange View Only Administrator	View configuration of all Exchange objects. Only Read, List object, List contents and View information store status for all Exchange objects in the organization container and subcontainers.
Exchange Administrator	Modify configuration of all Exchange objects. All permissions except Change permissions, Send as, and Receive as for all Exchange objects in the organization container and subcontainers.
Exchange Full Administrator	Same as Exchange Administrator, but with the additional capability to modify permissions on Exchange objects. All permissions except Send as and Receive as for all Exchange objects in the organization container and subcontainers.

Table 12.4 outlines the permissions for accessing the objects when you apply a role at the AG level.

Table 12.4. Exchange Roles and Permissions at the AG Level

Role	Permissions for AG Objects	Permissions for Objects in Organization Container
Exchange Full Administrator	All permissions except Send as and Receive as for objects in the AG and subcontainers.	Only Read, List object, and List contents permissions for objects in the organization container and outside of the AG container.
Exchange Administrator	All permissions except Change permissions, Send as, and Receive as for objects in the AG and subcontainers.	Only Read, List object, and List contents permissions for objects in the organization container and outside of the AG container.
Exchange View Only Administrator	Only Read, List object, Listcontents and View information store status permissions for objects in the AG and subcontainers.	Only Read, List object, and List contents permissions for objects in the organization container and outside of the AG container.

The best practice is to use the Exchange Administration Delegation Wizard to create groups for delegating administration, rather than specifying individual accounts. This makes it easy to change administrative rights by simply changing group membership.

These roles and associated rights need to be well understood and assigned appropriately to your management objectives. The basic roles are there as a guideline and a starting point, and can be altered . That being said, it isn't too difficult either to open up access too far or close it down too much.

Migration Preparation: Directory Synchronization

If your enterprise has Exchange 5.5 or even some other non-Microsoft e-mail system, you will want to synchronize this with AD to provide a consistent GAL for your enterprise. Having one GAL will allow your end users to find and address e-mail to anyone in your company. The directory synchronization is dependent on the Windows AD forest and domain models. If you choose multiple forests, then the synchronization is more complex and will require using a product to synchronize not only your legacy e-mail subsystems, but also AD between each Windows forest.

Planning the synchronization should be a joint effort between the mail and messaging architects and AD architects as the layout of domains and Organizational Units (OUs) will have to be taken into account when designing the directory synchronization. We've discussed some of the issues associated with multiforest migrations and those concepts hold true in any migration. For intra-organization migration, which seems to be the most common, some tools are available to assist with the migration, which are covered in the next sections.

Migration Preparation: AD Connector (ADC)

The AD Connector (ADC) is a utility that provides synchronization between the Exchange 5.5 DS and AD. The ADC allows you to select the contents of one or more recipient containers from Exchange 5.5 to be synchronized into a single OU in the AD. From AD, you select the contents of one or more OUs to be synchronized into a single recipient container in the Exchange 5.5 DS.

To be sure, this is just a summary of the ADC, and there is far more information and detail about this utility that you should go explore. Check out some of the books referenced earlier, and an upcoming book from Digital Press by Kieran McCorry, for details on the ADC. That book also contains loads of information on the next topic, the Site Replication Services (SRS).

Migration Preparation: Site Replication Services (SRS)

There is much confusion about the SRS. Let's try to clear it up by first saying that only the ADC provides the mechanism to perform directory synchronization between the Exchange 5.5 DS and the AD. The SRS has nothing to do with this type of synchronization. The SRS presents itself as an Exchange 5.5 DS to other Exchange 5.5 servers, but runs on an Exchange 2003 server. The SRS is available only when running Exchange in mixed mode containing Exchange 2000/2003 class servers and downlevel servers such as Exchange 5.5.

With the SRS providing what appears to be an Exchange 5.5 DS, it allows the other Exchange 5.5 servers to continue directory replication to this new server in the same way that they always have, despite the fact that the server is running Exchange 2003. Remember, though, this service and synchronization is there just to appease the Exchange 5.5 servers. The information is not written into AD; that's the job of the ADC.

Migration Preparation: The Migration Process

The actual migration process will vary slightly for everyone. All the details of the migration need to be documented, as stated before, and that information should include

• Account migration

• Exchange upgrade approach

• In-place upgrade of servers ”Exchange 5.5 to Exchange 2000 to Exchange 2003

• Restructuring approach

• Coexistence

• Mail connectivity

• Mail reply capability

• Directory synchronization throughout migration period

• Free/Busy and Public Folders

• Migration of distribution lists

• Migration of Public Folder content

• Re-homing of system folders

• Decommissioning of servers

• Updating Outlook profiles

• Preserving OSTs and rules

A lot of details or "moving parts" are associated with a migration, and you really need to have it all laid out in a formal step-by-step document. After the document is complete, you (the author of the document) need to test it and then later have someone who knows very little about the process run through the steps. This process ensures that you aren't taking anything for granted related to the migration process.

Client Access

With Exchange 5.5, messaging clients retrieved GAL information from an Exchange 5.5 server by means of its own DS. With Exchange 2000 and later, the DS has been moved to the AD.

Messaging clients must now retrieve GAL information from Windows 2003 GC servers. The method of GC access is different for each client type. From an Exchange 2003 perspective, MAPI clients come in two forms:

• Pre-Outlook 2000

• Post-Outlook 2000

Pre-Outlook 2000 Clients

Pre-Outlook 2000 clients include Exchange 4.0 Client, Exchange 5.0 Client, Outlook 97, and Outlook 98. These clients were designed to work with Exchange Server 5.5. As a result, they expect a DS to be available on their mailbox server. Exchange 2003 maintains compatibility with these clients through DSProxy services. As noted earlier, DSProxy performs directory lookups on behalf of the MAPI client to a nearby GC server and returns the results in the same manner as provided by legacy Exchange servers.

Post-Outlook 2000 Clients

Post-Outlook 2000 clients include Outlook 2000, Outlook XP, and Outlook 2003. These "smart" clients were engineered with Exchange 2003 and AD in mind and as a result, understand that GAL lookups are performed on GCs. When a smart client such as Outlook 2003 initially connects to an Exchange 2003 server, it requests a referral from DSProxy. DSProxy returns referral information and specifies a nearby GC to which Outlook 2000 should directly connect. The Outlook client remembers this GC referral by writing the information to its MAPI profile. The client writes the fully qualified domain name (FQDN) of the GC into the Registry. (Note: this feature is also available in Outlook 98 SR2 clients.)

All directory lookup requests from this point onward, even during the initial session, go directly to the GC without any reference to the Exchange 2003 server. Subsequently, when Outlook starts the next time, it immediately attempts to access the GC specified in the MAPI profile. If this GC is unavailable, it requests a new referral from DSProxy.

This mechanism allows only the "smart" client to request a new GC should its preferred choice be unavailable. To force Outlook to choose a new GC, you must delete the entry in the MAPI profile. Conversely, Outlook 2000 SR2, Outlook XP, and Outlook 2003 clients implement a mechanism that allows a new GC request every time the client starts. When these clients start, they ignore the GC specified in the MAPI profile, request a new referral from Exchange 2003, and then write this value to the MAPI profile to be used for the duration of the session. This dynamic allocation of GCs offers improved support for directory access and availability from a client perspective.