Chat now with support
Chat with Support

Migrator for GroupWise 4.7 - Pre-Migration Planning Guide

About this guide Introduction Critical considerations Other strategic and tactical issues Known limitations of the migration process Summary of features and capabilities

Coexistence

Coexistence is the state of two or more independent mail systems when both are serving the same organization at the same time—for example, when some users have already migrated to a new mail system while others remain on the old system, 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.

You should therefore determine at the outset whether the scale of this 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.

Coexistence typically requires accommodations for these three elements:

Directory Coexistence: Many 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 during the transition will introduce data inconsistencies between the source and destination servers, which may need to be reconciled during the migration process. Directory synchronization updates the contents of one directory to match the contents of another.
Email Coexistence: Email coexistence requires mail routing throughout the transition period, when users will be distributed across multiple mail systems, and moving from server to server. 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 mail systems without having to know the migration status of other users. Forwarding rules must therefore be updated upon the migration of each user group.
Calendar Free/Busy Coexistence: The GroupWise and Exchange environments also implement calendar free/busy queries differently, making the availability status of users in the other system unavailable. Both applications need some help to reliably determine the free/busy status of users in the other environment.

Coexistence tools and methods

Migrator for GroupWise supports coexistence facilitated by Quest Coexistence Manager for GroupWise (CMG) product, or by SMTP mail routing with no email remediation. Other tools may be available to facilitate certain coexistence functions, but CMG is developed specifically to work with Migrator for GroupWise, and contains three components to facilitate the three primary elements of coexistence.

Quest Coexistence Manager for GroupWise (CMG)

Quest Coexistence Manager for GroupWise (CMG) provides rich directory, email and calendar coexistence features between Novell GroupWise and Microsoft Exchange or Office 365.

To accommodate the three primary elements of a GroupWise–Exchange coexistence, CMG provides these three primary components:

Directory Connector (DC): Updates directory data between Novell NDS/eDirectory and Active Directory, configurable for any number of servers.
Mail Connector (MC): Remediates calendar-data emails to permit delivery of fully functional meeting invitations, acceptances/declines, reschedules and cancellations, and task data.
Free/Busy (F/B) Connector: Facilitates lookups of calendar free/busy data between users in the two different environments.

The three CMG components are independent, but designed to work together in any combination to suit a broad range of coexistence needs.

Mail and calendar coexistence by SMTP mail routing

If your organization prefers to not use Quest CMG for email routing, you can instead use SMTP routing with domain differentiation, but no email remediation, for that function. Since GroupWise and Exchange implement calendar features differently, and since the SMTP routing method simply relays messages without remediation, much calendar functionality is lost in messages routed by this method. Also, SMTP routing has no provision for calendar free/busy lookups.

By this method, the GroupWise and Exchange servers are assigned different domains or 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, you could assign a new gw.domain.com subdomain to the GroupWise server, and assign a new exch.domain.com subdomain to the Exchange server. Then, when internal mail from other GroupWise users arrives in the GroupWise accounts of already-migrated users, the mail can be forwarded to the appropriate Exchange mailboxes using the exch.domain.com subdomain.

SMTP routing introduces the possibility of the internal domains or subdomains escaping your local environment. Since these domains typically are not listed in the external DNS, this can cause reply-ability issues for external recipients. Some organizations address this by using a gateway appliance to rewrite the internal domains as they pass out of the organization, or through user education.

By default, messages routed via SMTP forwarding from GroupWise to Exchange will appear from each user’s GroupWise mailbox with the original message encapsulated in an attachment. The attachment is fully functional, but does require an Exchange recipient to open each item to determine the sender and take action. This default format also causes mail-reading problems on some mobile devices, so you may want to consider implementing Flat Forwarding on the GroupWise Internet Agent (GWIA) to solve these problems. More information on the Flat Forwarding option is available on Novell’s website.

Related Documents