Migrator for GroupWise 4.7.1 - Scenarios Guide

Step 12: Configure Migrator for GroupWise parameters for Office 365

Migration to Office 365 uses the Internet to transport data, which is typically slower and less reliable than local network connections. Migrator for GroupWise offers several features to minimize timeouts when a migration encounters data transmission delays. These features are enabled/disabled and configured by parameters in Migrator for GroupWise’s ini configuration files, as described below.

The Admin-Driven Batch Migrator reads a mandatory program parameter to get the two-character Usage Location code that Microsoft requires for its Office 365 licenses (per this Microsoft article). Be sure to set this value, in Migrator for GroupWise’s gwmigapp.ini, before you try to License users:

The parameter value is a two-letter keyword, which must conform to the standardized values listed for ISO 3166-1-alpha-2.

In adobjmerge.ini: If you will use Migrator for GroupWise to create user objects in a proprietary local AD server, use a text editor to add (or edit) these parameter settings:

In gwmigapp.ini: Set the watchdogminutes parameter to 30:

This specifies the number of minutes of inactivity the Admin-Driven Batch Migrator will wait within a program run before concluding that the connection has encountered a fatal error, and aborting the process. Migration to Office 365 typically generates more process timeouts than migration to a local server. This can become particularly problematic when migrating many large messages (usually due to large attachments). Setting watchdogminutes=30 makes the program more forgiving of connection issues when migrating to an O365 target. The default value of 15 is better suited to migration to a local server, where shorter and higher-quality transmission paths make timeouts less common.

If you still encounter timeouts with watchdogminutes=30, you could disable the feature by setting watchdogminutes=0. However, this setting should be used with caution because it tells the program to wait indefinitely for activity (rather than reporting that a fatal error has occurred after some period of time).

Migrator for GroupWise lets you configure the Admin-Driven Batch Migrator to retry MAPI calls that return errors typically associated with network latency or poor bandwidth. Such errors are rare when migrating to a local Exchange server, but can become more common when migrating to Office 365. This feature lets you control MAPI retries when certain errors are encountered. The feature is configured by these program parameters in the [Exchange] section of gwmigapp.ini:

This example shows the parameters set at their default values. At these settings, the program will retry 3 times, at 30-second intervals, for MAPI error 80040115 only. If the error persists through all retry attempts, the program will note the error in the log, skip the current message property or element, and move on to process the next item. Depending on your setting for Log level (on the Specify Run Information screen), the program's retry attempts may appear in the program logs with no other documented error or warning.

Note that the MAPIErrorsToRetry= parameter may contain multiple error codes, separated by commas, as in this example:

This example would tell the program to retry a MAPI call that returns either the feature-default error 80040115 or another error 8004010F. In most cases, the default error 80040115 alone should be sufficient.

You can also configure the Admin-Driven Batch Migrator to retry the migration of an entire message when errors occurring in the connection to the target platform cause a message to fail. This feature can complement the MAPI-error retry feature (above), which permits retries at the error level. If a MAPI error remains unresolved after the specified number of retry attempts, Migrator for GroupWise notes the error in its log and resumes processing with the next element or property of the message. If an error causes an entire message to fail, these message-level retry parameters provide control over the retry processing of an entire message:

This example tells the program to try as many as 3 times (if the first 2 attempts fail), waiting 60 seconds between attempts. The defaults are WriteMessageTryCount=1 and WriteMessageRetryWait=30, which tell the program to try a message only once (and not retry at all).

This feature lets you configure the Admin-Driven Batch Migrator to retry the migration of an entire message when an error occurs in the connection to the GroupWise server. (The other message-level retry feature, described above, does the same thing for errors that occur between Migrator for GroupWise and the target Exchange platform.) If a GroupWise-Migrator for GroupWise connection error causes an entire message to fail, these message-retry parameters let you tell the program to retry processing the entire message, from the beginning, at specified intervals, through a specified number of iterations:

The RetryCount= parameter tells the program how many times to retry to migrate a message (if not successful on the first attempt), at intervals specified by RetryDelay= (in seconds). The defaults, RetryCount=3 and RetryDelay=30, tell the program to retry three times (four total tries), at intervals of 30 seconds. If a message fails again on the last attempt, the program notes the failure in its log and resumes processing with the next message.

Step 13 (if necessary): Copy users' archives to a centralized location

Migrator for GroupWise offers several options for migrating data that resides on users’ workstations. One approach uses the Self Service Desktop Migrator (SSDM), a component of Migrator for GroupWise that offers an optional Silent Mode to minimize user interaction and impact. This approach is discussed in greater detail in chapter 4 of this Guide.

Some scenarios, however, require central migration of GroupWise archives. Migrator for GroupWise’s Admin Batch Migrator can migrate GroupWise archives to Exchange (or to PSTs), but only if the program has access to the source archives. Typically, this means providing users access to a central share and having them copy their archives to this location prior to the migration. The Batch Migrator can also migrate archives from diverse, per-user locations, but only if you specify the location for each user in your user-list CSV file.

If this approach will be used for migrating archives, an appropriate location and process should be established. In addition, the approach and any end-user involvement should be communicated in advance of the migration.

Step 14: Prepare for Office 365 Wave 15 throttling

To better address the PowerShell Runspace throttling introduced in O365 Wave 15, your organization should submit a request to Microsoft to ease the PowerShell throttling restrictions. The tenant admin must open a service request with Microsoft and reference Bemis Article: 2835021. The Microsoft Product Group will need this information:

* For the last two items in this list, take the total number of threads across all migration machines and add a buffer, because it is difficult to predict the timing of the Runspace initiation. It is best to assume that all potential Runspaces could be created within a minute, so the values for both items should probably both be submitted as the total number.

When you have completed these Pre-Migration Preparations, continue with the Batch Migration Process below.

Batch migration process

Migrator for GroupWise includes two migration engines:

Either application can be used independently for the entire data migration, or the two may be used together to meet a variety of project requirements.

This section provides process instructions for a typical migration to Office 365, in which an administrator performs the migrations for multiple groups (batches) of users with no user interaction. Planning and deployment for the per-desktop SSDM are described separately, in chapter 4: SSDM (per-desktop) migration.

The flow chart below summarizes the batch-migration process for an Office 365 target. The step numbers in the flow chart correspond to the step numbers in the narrative process instructions that follow.

This batch-migration procedure is repeated for each group of users to be migrated, as shown by the looping arrow in the flow chart.

NOTE: Do not begin this procedure until you have completed the Pre-migration preparations, in the preceding section of this chapter.