Chat now with support
Chat with Support

Migrator for GroupWise 4.7 - Quick Start Guide

Conceptual walkthrough

In a typical migration to a local, proprietary Exchange environment:

 

We provision the Active Directory with either Quest CMG or Quest Migrator for NDS (other Quest products, not parts of Migrator for GroupWise), which extracts data from the GroupWise server to create AD user acounts. Migrator for GroupWise’s AD Object Merge Tool then mail-enables the new objects by adding users’ GroupWise addresses to the AD account records.

 

Exchange can then route mail to not-yet-migrated GroupWise users, to facilitate correct delivery of inbound external (Internet) mail to GroupWise users, and also of internal mail from already-migrated Exchange users. The MX record can be switched at any time after the AD accounts are mail- enabled—before, during or after the actual migration.

 

Migrator for GroupWise's Administrator-Driven Batch Migrator program "mailbox-enables" (creates mailboxes for) the Exchange accounts of migrating users, and sets mail-forwarding rules in GroupWise so any mail addressed to an already- migrated user at GroupWise will be forwarded to the user's now-active Exchange mailbox.

 

This process repeats as each user group migrates to the new server.

 

When the last group is migrated to Exchange ...

 

... the old GroupWise server can be decommissioned.

Migration scenarios

Virtually all migrations follow a similar basic process, with variations to accommodate each organization's circumstances and needs—what we collectively call a scenario. Your migration scenario determines much of the migration process and your necessary pre-migration preparations, so it is critical to define your scenario at the outset. Most variations to the basic migration process are determined by:

Migration Destination (the Exchange "target" type):
A proprietary Exchange environment is one whose hardware and software are wholly under the control of the migrating organization. Ordinarily this is a local Exchange network—on the same premises as the GroupWise source, or at least near enough to use high-performance network cables for data transfer. But a proprietary Exchange server may reside at a location distant from the source (geographically and/or from a network perspective).
Microsoft’s Office 365 is a hosted Exchange platform (also known as "the cloud"). Cloud computing is a service model in which the hardware and software are owned and controlled by a third party (Microsoft). Microsoft then sells, as a service, access to disk space and the Exchange/Outlook software features.
Pre-Migration State of Local Active Directory (if any): Your organization may already have Active Directory running for login and security purposes. Part of the migration process will depend on whether you do have an existing AD and, if so, on the state of any objects already provisioned in the local AD.
If migrating to proprietary Exchange: Do you already have Active Directory configured and, if so, in what state are any previously provisioned objects? (If the objects exist, are they already mail-enabled, mailbox-enabled, or neither?)
If migrating to hosted Exchange: Will you maintain a local Active Directory—either temporarily to provision the hosted AD, or permanently? (One popular option is to provision first to a local AD, which can then be synchronized to the cloud platform.) Or will the cloud AD be provisioned directly from GroupWise? Does the hosting organization have certain provisioning requirements or procedures?

Different combinations of target types and states of an existing local AD (if any) produce an array of migration scenarios. The scenarios listed below cover almost all variations to a GroupWise-to-Exchange migration, and the Migrator for GroupWise Scenarios Guide describes them all, with suggested process instructions:

The Scenarios Guide also describes three special-case scenarios, any of which would occur in combination with one of the above-listed scenarios:

Offline Migration: A proprietary Exchange server may reside at a physical location distant from the source environment (geographically and/or from a network perspective). An offline migration is a two-phase migration strategy in which the GroupWise source data is migrated first to a nearby intermediate storage medium, which can be physically transported to another location where you have a more favorable bandwidth connection to the Exchange server. The data is then migrated from the intermediate medium into Exchange.
Phase (Staged) Migration: A phased-migration approach is a strategy by which users remain on the GroupWise server(s) throughout most of the transition period, receiving and sending mail and managing their calendars in GroupWise just as they always have, while their oldest data (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 volume of data remaining can be migrated relatively quickly, so that larger numbers of users can be migrated together within a shorter window, typically in one final cutover weekend.
SSDM Silent Mode Migration: The Migrator for GroupWise Self Service Desktop Migrator (SSDM) offers a Silent Mode configuration, commonly used to minimize end user involvement when SSDM is deployed, but while maintaining the flexibility and other benefits of a distributed migration.

Migration process overview

NOTE: This brief narrative is not meant to be a substitute for the detailed step-by-step process instructions in the Migrator for GroupWise Scenarios Guide. The material here is intended only to familiarize you with Migrator for GroupWise, and the contexts in which its components are typically used.

This section briefly describes a typical migration scenario using Migrator for GroupWise, to migrate from Novell GroupWise 8.0.0 to a proprietary on-premises Exchange 2010 server. Details of this process appear in chapter 2 of the Migrator for GroupWise Scenarios Guide. In this scenario, an administrator performs the migrations for a series of user groups with no user input or interaction.

The approach described here is appropriate for many migrations, but the configuration, circumstances and preferences of different sites often dictate variations to this process. Migrator for GroupWise also supports migrations to Microsoft’s Office 365. Migrator for GroupWise also includes a per-desktop migration tool that can be used by end users, or by administrators acting on behalf of end users. Meanwhile, Migrator for GroupWise also supports offline migrations (two-phase migrations to remote Exchange servers). Migrator for GroupWise product components offer plenty of operational options that allow great flexibility in devising and implementing a broad range of migration strategies for all of these migration destinations and circumstances. The Migrator for GroupWise Scenarios Guide explains how to approach and execute a migration in any of the most common scenarios and variations. For information and help with other scenarios, contact your Quest sales representative.

Necessary pre-migration preparations

The pre-migration process for this scenario is illustrated in the accompanying flow chart (next page).

The process begins with existing user accounts and mailboxes on a GroupWise server. The destination Exchange server is set up on another machine and the migration process will require admin accounts on both servers. In this scenario we will use Quest Coexistence Manager for GroupWise (CMG) to facilitate directory, email and free/busy coexistence during the transition period. Microsoft Outlook is installed on users’ desktops. And of course the Migrator for GroupWise software must be installed on the admin’s migration server.

Migrator for GroupWise will access GroupWise user data as a GroupWise Trusted Application (see chapter 3 of the Migrator for GroupWise Pre-Migration Planning Guide), so we skip the step for preparing Migrator for GroupWise’s AddProxy program.

Users in this scenario will migrate in a series of groups, over a period of several weeks, and want to continue using their calendar features throughout the transition period. We therefore install and configure the Quest CMG connectors for email routing, calendar free/busy queries, and directory synchronizations throughout the transition period.

We run Migrator for GroupWise's Directory Exporter to read the GroupWise directory data and generate the data files required by other Quest applications. Next we install and run Quest Migrator for NDS to provision Active Directory with user and group data from NDS. And then we run Migrator for GroupWise’s AD Object Merge Tool, which reads one of the Directory Exporter’s data files to merge users’ GroupWise addresses into the AD objects provisioned by Quest Migrator for NDS, thus mail-enabling the objects. If the AD Object Merge Tool finds any Exchange contacts for users who also have AD accounts, the program merges the contact information into the corresponding accounts, and then deletes the contacts, to consolidate each such pair into a single mail-enabled security object per user.

This process does not create mailboxes per se, but rather provisions new objects in Active Directory as mail-enabled accounts—associating users’ existing GroupWise addresses with their AD accounts to make mail routing possible. The new AD objects are said to be mail-enabled because Exchange can receive inbound (Internet) mail addressed to these users and immediately route it to the corresponding GroupWise mailboxes. Now that we have created mail-enabled AD accounts for all GroupWise users, we modify the MX record to direct external (Internet) mail to the Exchange environment.

Before the first users are migrated, we use a text editor to change a parameter in the gwmigapp.ini file so that a later directory synchronization will work properly.

Related Documents