2.9 Running Exchange in multiple forests

 < Day Day Up > 



When Microsoft launched Exchange 2000, its advice was simple: One AD forest was sufficient to support user accounts and directory-enabled applications such as Exchange. Microsoft underlined this approach by allowing only a single Exchange organization per AD forest. Indeed, in the early days of Windows 2000 it was a form of heresy to suggest that anyone might need to deploy multiple forests. However, times change and circumstances develop that require some companies to deploy multiple instances of Exchange, each in its own forest. Among the reasons to deploy multiple forests to support Exchange are:

  • You need to support multiple Exchange organizations, each requiring a separate forest.

  • You need to include Exchange organizations acquired through a company merger or acquisition.

  • You need to isolate different parts of the business in separate Exchange organizations to make it easier for the company to divest operating entities.

  • Operating units may have their own IT department, which makes its own decision on what email system to operate. If the IT department selects Exchange, it may not choose to join a corporate deployment and will run its own to maintain operational independence.

Perhaps the worst reason to deploy multiple forests is the situation when a unit within the company begins to deploy Exchange earlier than the official deployment and so establishes its own AD forest to support the deployment. You can migrate the users from this organization over to the corporate organization when it is ready or let the two organizations run together. In other situations, an operating unit of the company must operate a secure or isolated email system to comply with government regulations. For example, a financial services company may have to run one Exchange organization for its trading unit and another for its merchant banking division.

2.9.1 Costs of multiple forests

After you determine that the need exists to deploy multiple forests, you can proceed to assess the costs of deployment. Costs arise from:

  • Software tools

  • Complexity in administration

  • The need to synchronize data between the forests

  • The degree of fidelity required between the forests

The last point is possibly the most important, because synchronization of elements such as accounts is a simple task, while synchronization of data such as public folder contents is complex and requires more effort and therefore cost. Table 2.11 lists the major cost elements in multiforest deployments.

Table 2.11: Costs to Exchange Data between Multiple Forests

Outcome

Tools

Cost

Messaging connectivity

SMTP and X.400 connectors

None: part of basic Exchange functionality

Address book synchronization

LDAP synchronization utilities such as HP LDSU or Microsoft MMS 2003 (GALsync)

Effort required to map AD objects between multiple forests to achieve consistency in address book views

Cross-forest calendar scheduling

InterOrg Replication Utility for Free/Busy data

Basic scheduling works, the effort is needed to make free/busy data visible to users across the forests

Public folder content synchronization

InterOrg Public Folder Synchronization utility

Effort required to identify public folders that should be synchronized and then to establish synchronization schedules, plus ongoing monitoring

Shared infrastructure resources (DNS, DHCP, network, single sign-on)

Standard Windows tools

Design effort to establish various infrastructures, with most effort required for single sign-on architecture

Account and mailbox moves between

forests Microsoft ADMT (or third-party utilities) and Exchange Migration wizard

Planning and control of mailbox moves between forests

You can use tools from Aelita, BindView, and other vendors to help move accounts and mailboxes between forests. These tools incur additional cost and the preferred approach is to use the free Microsoft tools (ADMT and the Exchange Migration wizard) whenever possible. However, you may have used other tools for other purposes, such as to migrate from Windows NT 4.0 to Windows 2000/2003 and can continue using them to aid cross-forest movement.

2.9.2 Directory synchronization

Exchange is an email server, so establishing messaging connectivity is the easiest part of multiforest operations. Given the SMTP-centric nature of Exchange 2000/2003, it is best to deploy SMTP connectors whenever possible. However, you may need to use X.400 connectors if the organizations share the same address space (such as two organizations that use hp.com as their address space). Assuming that messages can pass between Exchange servers in the different forests, the next issue is to build cross-forest address books by synchronizing details of mail-enabled objects so that each forest can build its own view of the complete environment. Generally, this means that you synchronize details of mail-enabled accounts, groups, and contacts from each source forest to the various target forests. You have the following choices:

  • Deploy a full metadirectory solution, such as Microsoft Metadirectory Services (MMS).

  • Deploy a simple LDAP directory synchronization solution, such as HP's LDSU or Microsoft's GALSync, a component of MMS.

  • Write your own tool to exploit APIs such as ADSI and LDAP to work with the contents of the AD.

Microsoft bought the technology for MMS from a company called Zoomit some years ago and has since developed it to become a full metadirectory service. A metadirectory accepts feeds from sources such as the AD, normalizes the data, and then provides feeds to consumers. Note that MMS does not support LDAP access to data.

MMS is full of features, but it can be complex to deploy. In addition, you may not need a full metadirectory, especially if you only want to exchange information between directories that are very close in structure to each other—for example, to exchange information between two AD forests or between the AD and the Exchange 5.5 DS, or to synchronize user account information in the AD with an LDAP-compliant HR database such as PeopleSoft. Given the increasing number of multiforest deployments, Microsoft recognized that it had to make the directory synchronization process easier and the GALSync tool is the result.

GALsync is a special utility built on top of MMS to deal specifically with the challenge of multiple AD forests. As the name implies, GALsync generates a synchronized GAL, using some preconfigured management agents to gather data from the different forests. GALsync supports hub and spoke networks, where a central forest acts as the gathering point for information from multiple spoke forests, and fully meshed networks, where each forest synchronizes its data with the others. However, GALsync does not support daisy-chained synchronization, where forests provide their information to another forest, which then sends a collated set to a third forest, and so on.

While GALSync does a good job of combining user and contact information from multiple AD forests, sometimes you need to synchronize information from multiple LDAP-compliant sources or you need to exert more control over how information flows into a directory. For example, you might have to modify information from one directory before it can go into another directory. You might have to match attributes and transfer data held in an attribute in one directory and remap it to a different attribute in another directory. In these instances, it is best to deploy a utility such as LDSU (search www.hp.com to find the latest information), which is designed to work with any LDAP-based or flat file directory and perform anything from simple to complex processing on data during the synchronization process. As with a metadirectory, LDSU is also able to normalize data and generate feeds for different directories. LDSU synchronized the Exchange directories when Compaq and Digital merged in 1998 and again when HP and Compaq merged in 2002, so it is well versed in merger and acquistion scenarios.

2.9.3 Calendar interoperability

Many companies are satisfied when the different operating units can send messages to each other and share a common GAL. This represents the lowest acceptable degree of cross-organization integration within a company. Providing a way to share calendar and public folder data represents the next degree of integration and introduces another level of complexity.

Users can send calendar meeting requests as soon as you establish messaging connectivity, and the recipients are able to process the meeting requests and accept or reject the meeting and have its details inserted in their calendars. However, by default, meeting organizers cannot view the free and busy information for recipients outside their own Exchange organization, because Exchange holds free and busy data in a system public folder that Outlook searches when it needs to retrieve information about the schedule of potential meeting attendees. There are three approaches to the issue. You can:

  • Ignore it and force users to send meeting requests between each other until all recipients can agree on a mutually acceptable time. This is a reasonable solution when you plan to merge users from multiple organizations into a common organization and do not want to expend the effort required to exchange free and busy information between the organizations.

  • Ask users to publish their free and busy data to Microsoft's Internet Free/Busy Service. Essentially, this means that users sign on to a shared service maintained by Microsoft to publish free/busy data there. Other users can then consult your free/busy data by connecting to Microsoft's service. This approach is acceptable when you have only a small number of users that need to share free/busy data for a short time while you prepare a migration—for example, if you have a small number of senior executives in each organization who need to organize meetings with each other.

  • Use Microsoft's InterOrg Replication Utility[8] to replicate free/busy data between the organizations. You can use the same tool to replicate data from other public folders as well. A copy of the latest InterOrg Replication Utility is in the /support directory on the Exchange 2003 server CD. The utility can replicate data between Exchange 5.5, Exchange 2000, and Exchange 2003 servers. This is the best option when you plan to operate multiple organizations alongside each other for sustained periods. Microsoft Knowledge Base article 238573 provides detailed instructions about how to deploy the InterOrg Replication Utility.

While all these solutions work, there is a clear requirement for user education and support. With the first option, users have to understand why they can see free/busy data for one set of users and not for others. With the second option, they have to be instructed how to publish their free/busy data to Microsoft's Internet service and how to log on (with a Microsoft passport) to consult data for other users. The third option is the most transparent for users, but it is the most onerous for system administrators, who must install and operate the InterOrg Replication Utility and debug any problems that occur.

2.9.4 Common platforms

Organizations that come together because of mergers and acquisitions usually have separate Windows and network infrastructures to support users and applications—for example, separate Windows domains, physical networks, and so on down to client platforms and methods for remote access (RAS, VPN, etc.). Following a merger, you may decide to keep the separate infrastructures or consolidate. The former is the easiest but most expensive option, because of the almost inevitable duplication in servers and other infrastructure components. Consolidation is the most attractive financial option, because you can reduce the number of domains, eliminate redundant servers, merge networks together, and so on to make the infrastructure less complex and easier to manage. However, it takes a lot of time and effort to consolidate computer infrastructures, so this is not a project to jump into overnight.

2.9.5 Moving users between different Exchange organizations

You can use the standard Move Mailbox wizard to move mailboxes within the same organization, but moving from one organization to another poses a different challenge because of the requirement to create Windows accounts, preserve legacy email addresses, and so on. Microsoft provides the Exchange Migration wizard to move a user from one Exchange organization to another. Originally designed to migrate users from Exchange 5.5 to Exchange 2000, the wizard now accommodates movements between any Exchange organization (5.5, 2000, and 2003). As shown in Figure 2.31, you can also use the Migration wizard to move mailboxes from other messaging systems such as Lotus Notes and Novell GroupWise. The Migration wizard first appeared in Exchange 2000 SP1 and is now installed alongside other Exchange 2003 components as part of the standard kit, so you can access it like any other program in the Deployment Tools folder. The processing flow is as follows:

click to expand
Figure 2.31: Migration wizard options.

  • Select the migration type. In this case, we want to move one or more mailboxes from another Exchange server in a different organization, so select "Move from Microsoft Exchange."

  • Select the target server and mailbox store for the mailboxes.

  • Select the source server and provide login information for a permissioned account on that server. A trust relationship must exist between the source and target Windows domains. You must have Exchange administrator permission on both the source and target servers. If moving from a different email system, you must have the appropriate administrative permissions on the source server to allow the Migration wizard to extract messages and other items and transfer them to the target server. The source and target servers must share network connectivity and, due to the amount of data that some mailboxes hold, faster connections are obviously desirable.

  • You then select the information to migrate. You can apply filters to move only messages within a specific date range (a year is the default option) or provide the wizard with a text file giving message subjects that you do not want to move. For example, you may decide not to move any messages that contain "Hi" as the subject, because these messages are unlikely to contain much business value.

  • The wizard connects to the source server and displays a list of the mailboxes that it holds (left-hand screen in Figure 2.32). You select the mailboxes to move and then select the organizational unit in the AD to create new accounts for these users. The wizard then checks to see whether the accounts already exist, in which case you can opt to use the existing accounts, or it proposes new accounts. You can amend details of a new account by selecting it from the list, right-click, and taking the "Edit" option.

    click to expand
    Figure 2.32: The Exchange Migration wizard in action.

  • The wizard then begins to process the mailboxes. It creates disabled Windows accounts using account information taken from the source system, creates the mailboxes in the target store, and then begins to transfer data, reporting information in a progress screen (right-hand screen in Figure 2.32). The wizard also writes information about its processing into the Application event log, as shown in Figure 2.33.

    click to expand
    Figure 2.33: A successful migration.

After the wizard finishes, you must enable the Windows account and create a new profile to allow the user to access his or her mailbox. The user must supply a new password when he or she logs on, or an administrator can reset the password and provide the new credentials to the user. Note that the contents of the source mailbox are not affected and you must remove mailboxes and accounts from the source system manually, but only after you are certain that the migration is successful.

Migrating mailboxes can take a long time to process. For example, the wizard required 40 minutes to move a mailbox with 15,409 items occupying 540,197 KB in the Store between two servers connected on the same LAN. During this period, Exchange generated 172 transaction logs (860 MB). As with all mailbox moves, it is best to perform these operations at system quiet times and ensure that you have sufficient capacity within the Store (to accept the new mailboxes) and on the disk that holds the transaction logs. The migration wizard connects to mailboxes with MAPI and appears to be a normal logon. Users can remain logged on during the move, but this is a bad idea.

The Migration wizard preserves old email addresses to allow Exchange to deliver messages users send to old addresses. The wizard writes old email addresses into user records in the AD as SMTP, X.400, and X.500 proxy addresses, and the Exchange Routing Engine searches these addresses before it fails to route a message if it cannot find another match. Microsoft first used the technique of using X.500 proxy addresses to preserve old email addresses in the Exchange 5.5 Move Server Wizard, so it works. Figure 2.34 shows details of a user who has been through several corporate acquisitions, so the Migration wizard has preserved the old "digital.com," "compaq.com." and "hp.com" SMTP addresses, while the Recipient Update Service allocates a new primary SMTP proxy for the current Exchange organization (hpqnet.qtest.cpqcorp.net). Similar processing has occurred for the X.400 addresses, and the set of X.500 addresses preserves the set of legacy Exchange first-generation internal addresses.

click to expand
Figure 2.34: Email addresses.

Aside from all the processing it already performs, the Exchange 2003 version of the Migration wizard ensures that users do not have to recreate their offline store file (OST), which is an important step given the prominence of cached Exchange mode introduced in Outlook 2003. Rebuilding an OST is always a pain, especially across a slow connection, so the Exchange 2003 version of the wizard supports a new clone mode (invoked by running mailmig.exe with the /M switch). Clone mode transfers the value of the MapiEntryID attribute for the source mailbox to the target store to preserve the connection between the token held in the OST and the mailbox.

[8] . The original need for the InterOrg Replication Utility arose when Microsoft deployed two separate Exchange organizations—one for the Exchange team and the other for the rest of Microsoft. People wanted to be able to schedule common resources such as meeting rooms and so Microsoft developed a utility to exchange calendar data between Exchange organizations.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net