Chatta subito con l'assistenza
Chat con il supporto

Migrator for Notes to Exchange 4.17 - Pre-Migration Planning Guide

About the Migrator for Notes to Exchange documentation Introduction Critical considerations Other strategic planning issues Appendix A: Known limitations of the migration process

Phased migration strategy

Some administrators opt for a "phased" migration strategy, where users remain on the Domino server(s) throughout most of the transition period, while their oldest data (perhaps 90-95% or even more of the total) is migrated to the new Exchange environment. After the older data has been migrated, the proportionately smaller volumes of data remaining can be migrated relatively quickly, so that larger numbers of users can be migrated together within a shorter window. A phased-migration approach may save enough time in the final cutover phase to eliminate the need for coexistence (see next following section), where the migration scale would otherwise put a single-weekend migration out of reach.

A phased migration is a variation of the more typical scenario, requiring some extra considerations and a few extra steps, as explained in the Phased Migration topic in chapter 1 of the Migrator for Notes to Exchange Scenarios Guide.

Coexistence during the transition

Coexistence is the state of two or more independent servers when both are serving the same organization at the same time—for example, when some users have already been migrated to a new server while others remain on the old server, awaiting migration. Coexistence introduces more complexity to a migration, and additional steps to the process. But for many organizations, some level of coexistence is essential for the continuity of critical business operations through the transition period of a migration.

An organization should therefore determine at the outset whether the scale of its migration project will permit a single-weekend or "phased" approach (as described above), or will require coexistence. Where coexistence is required, your written Migration Plan should specify the coexistence methods that best suit your needs.

For a Notes–Exchange coexistence, you likely will want to accommodate some combination (or all) of these primary issues:

•
Directory Updates: Most migrating organizations experience staff additions, departures, transfers, and so forth during a transition period of at least several days, often weeks or even months. Any staff changes that occur while the migration is in process will introduce data inconsistencies between the source and destination servers, which you may need to reconcile during the transition. A directory update synchronizes the contents of one directory to match the contents of another. With Migrator for Notes to Exchange, a directory update is also used to help provision Active Directory with the objects in the Domino directory.
•
Email Routing and Remediation: Email coexistence requires mail routing throughout the transition period, when users will be distributed across multiple mail systems. Inbound Internet mail must be directed to the correct server mailbox, and all users must be able to send mail to one another across all active servers without having to know the migration status of other users. Forwarding rules must therefore be updated upon the migration of each user collection.
 
* 
NOTE: Quest Migrator for Notes to Exchange does not physically route email between Notes and Exchange. Migrator for Notes to Exchange can update mail-forwarding rules in Notes/Domino and AD/Exchange as users migrate from one environment to the other, to ensure proper routing throughout the migration. But the flow of mail is facilitated by some other mechanism, not by Migrator for Notes to Exchange.
In addition to email routing, most organizations want some level of email remediation to compensate for cross-platform losses in the fidelity of message contents: attributes, attachments, calendar data, and so forth. Notes and Exchange environments offer similar email and calendar capabilities, but implement many features differently. Outlook therefore does not handle certain message types that originate in Notes, and vice versa.
Meeting invitations, acceptances, declines, cancellations, and so forth are particularly vulnerable to losses in functionality, since calendar data is transmitted within email messages, but the data formats are different in Notes vs. Exchange. Often a recipient client can display pertinent calendar information correctly, but cannot perform the calendar updates that would have been automatic if the recipient and sender were using the same email system. Or sometimes the receiving client can perform automatic calendar updates, but introduces errors— incorrect dates or times, or missing or extraneous instances in recurring series, etc.
•
Calendar Free/Busy Lookups: Full use of calendar features requires free/busy lookups that will find current data regardless of the servers where the meeting attendees reside. This is accomplished by free/busy synchronizations and queries between the Notes and Exchange free/busy databases.

While it is possible to route mail via SMTP addressing alone, this method offers no remediation for calendar data, or Notes "active mail," or for other email attributes, attachments and so forth. Most organizations will therefore want some tool to facilitate good coexistence between the Notes and Exchange environments. Migrator for Notes to Exchange is designed to complement the coexistence features of other tools, especially Quest’s own Coexistence Manager for Notes (CMN).

Several coexistence topics appear over the next few pages, including an overview of Quest CMN. Your written Migration Plan should include a thorough description of your organization coexistence strategy: mail-routing method and configuration, planned accommodations for directory updates and email remediation and calendar free/busy lookups, and the software tool(s) you will use to implement your coexistence strategy.

 
* 
IMPORTANT: If you will configure free/busy coexistence between Domino and either a local proprietary Exchange or Microsoft 365, the timing of your target provisioning (within the overall migration process) will be affected by this known Exchange limitation:

Exchange cannot send a free/busy query to Domino for any user who has an Exchange mailbox. Exchange can direct such queries only to its own mailboxes.

This is true with or without Quest CMN. The significance and implications of this limitation depend on whether you are migrating to a proprietary AD or to Microsoft 365. For more information see Provisioning Microsoft 365 earlier in this chapter.

Quest Coexistence Manager for Notes (CMN)

Coexistence Manager for Notes (CMN) is a separate Quest product designed to provide rich directory, email and calendar coexistence features between Notes and Microsoft Exchange (including Microsoft 365). To accommodate the three primary issues of a Notes–Exchange coexistence, CMN provides these three primary components:

•
Directory Connector: Updates directory data between the Domino Directory and Active Directory, configurable for any number of servers.
•
Mail Connector: Monitors SMTP traffic between Domino and Exchange to intercept and fix the incompatibilities inherent to certain message types and message contents and attachments. This email remediation service detects and converts in-transit messages as necessary, on the fly, to facilitate cross-platform functionality of most calendar functions, message attachments, and Notes rich-content mail features whereby messages can carry "live" or "active" functional content.
•
Free/Busy Connector: Facilitates the exchange of calendar free/busy data between users in the two different environments. This sharing of free/busy data between Notes and Exchange makes possible automatic calendar updates for accepted meeting invitations, or when a user proposes a different day/time, or cancels, etc.

CMN is not a part of Migrator for Notes to Exchange, but may be purchased separately from Quest. For more information contact your Quest Sales representative.

SMTP email routing

SMTP mail routing can be configured for either single-domain or multi-domain environments, as described separately below. In either case, Notes person documents and Active Directory object records are configured prior to migration to permit internal mail-routing during coexistence.

Single-namespace SMTP mail routing (within a single domain, by smart hosts)

Mail routing by SMTP addressing within a single domain is accomplished using smart hosts in both directions. Exchange can be configured to route mail to a smart host if Exchange determines the recipient is not in the local internet domain. Exchange routes such mail to the smart host, via the targetAddress attribute in the Active Directory object record. Meanwhile, Domino is configured to do the same thing in reverse for a recipient whose local internet domain address is not listed in any Domino person documents.

To configure smart-host SMTP routing with Quest's CMN, both smart hosts are configured to point to the CMN server. Within CMN, one set of SMTP IN and SMTP OUT queues is configured to accept mail from Domino and deliver it to the receiving Exchange server, while another set is configured to accept mail from Exchange and deliver it to Domino. Multiple CMN servers can be deployed for load balancing and redundancy. The CMN User Guide explains this scenario in more detail (see Coexistence Mail Routing Basics in chapter 3). And see also your Domino and Exchange documentation and online resources for more information about configuring smart hosts for those servers.

Multi-domain SMTP mail routing

Mail routing by multi-domain (subdomain) SMTP addressing is somewhat more complicated, but still straightforward to implement. By this method, Domino and Exchange are assigned different subdomains to differentiate the two internally (within your network) during the transition, so email can be routed between the two servers by SMTP addressing and your organization's DNS configuration.

For example, if your original domain is domain.com, assign a new notes.domain.com subdomain to the Domino server, and assign a new exch.domain.com subdomain to the Exchange server. When internal mail from other Notes users arrives in the Notes accounts of already-migrated users, the mail can be forwarded to the appropriate Exchange mailboxes using the exch.domain.com subdomain.

A subdomain routing method may introduce a risk that the assigned subdomain names will escape your organization internal communications, which in turn can cause bounce-backs on replies to those addresses. To prevent this, set the Notes forwarding address attribute to user@subdomain@notesdomain, which causes Domino to set the reply address for external email to the user's primary SMTP address (internet address field value).

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione