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

Migrating resources

Migrator for GroupWise migrates GroupWise resources with ownership intact, so the resources’ GroupWise owners will have Full Access rights to their resources in Exchange. Migrator for GroupWise also gives you the option of conferring Calendar Delegate rights to the GroupWise owners of migrated resource mailboxes in Exchange, so the owners can book their resources and approve booking requests for other users. This option is controlled by a boolean parameter in the [Exchange] section of gwmigapp.ini:

The option is on (1) by default, but can be disabled by setting MigrateResourceDelegation=0.

When a resource (conference room, AV equipment, and so forth) is migrated to Exchange, the resource also remains on the GroupWise server—that is, the GroupWise original is copied, not destroyed or altered. After migration the two resources exist independently of each other, so users who have not yet migrated to Exchange will interact only with the GroupWise resource, while migrated users will interact only with the Exchange/AD resource. This coexistence introduces the potential for "double-booking" resources, since users in Exchange have no way of knowing whether the corresponding resources in GroupWise may have been reserved by not-yet-migrated users, and vice-versa.

There is no easy or complete solution to this "double-booking" problem, but you should consider some options to mitigate its effects, and your Migration Plan should identify this strategy. The most popular options are:

NOTE: Note: Migrator for GroupWise cannot automatically create resource-type mailboxes in Exchange 2016, 2013 or 2010, although it can migrate data to resource mailboxes that already exist. Quest therefore recommends that you manually create AD resource mailboxes prior to migration.

Provisioning groups (distribution lists)

When a group is provisioned into AD, it also remains on the GroupWise server (that is, the GroupWise original is copied, not destroyed or altered), and after its migration the two groups exist independently of each other. This coexistence introduces the potential for discrepancies between the two group membership lists, as group members may be added and deleted during the transition period. You can re-run the Directory Exporter and then the Admin-Driven Batch Migrator to update the AD groups’ membership lists with any changes entered into the GroupWise originals, but there is no practical mechanism for updating in the opposite direction, from AD back to GroupWise.

Since the only practical update path for groups is one-way, most organizations choose to defer provisioning their groups into AD until the very end of the transition—after all users have been migrated. This approach eliminates the need for periodic updates, and already-migrated users can address emails to groups defined in GroupWise the same (transparent) way they send emails to not-yet-migrated users. This approach also is likely to generate more traffic across the CMG Mail Connector (if you will use this tool for mail routing), which will increase as more and more group members migrate to Exchange.

Some admins may want to avoid that added burden on the CMG Mail Connector, but the alternative is to provision the groups into AD at the outset (or whenever). In that case you would have to choose between running frequent synchronizing updates throughout the transition period, or accepting inconsistencies between the GroupWise and AD groups. That is, you could re-run the Migrator for GroupWise Directory Exporter and then the Admin-Driven Batch Migrator to update the AD groups’ membership lists. (The more current the AD group definitions, the less traffic will be passed through CMG.) It is also conceivable, depending on how groups are managed within a particular organization, that groups could be primarily maintained in AD, which would require a manual groups-updating procedure from AD back to GroupWise throughout the transition period.

Your Migration Plan should identify which of these strategies is best suited to your organization’s needs and preferences.

The Admin-Driven Batch Migrator can be told to add a user to a group if the corresponding Contact is already a member of the group. This feature is enabled/disabled by a boolean parameter in gwmigapp.ini:

The default (MergeGrpMembership=1) tells the program to add a user to a group if the corresponding Contact is a member of the group. The alternate setting (MergeGrpMembership=0) disables this feature.

Migrating shared folders and address books, and proxy rights

A shared folder or address book in GroupWise can be migrated either to its owner (only) in Exchange, or to all of the users to whom the item was shared in GroupWise. Migrator for GroupWise’s Admin-Driven Batch Migrator includes a screen on which you can enter your preferences. You can specify different choices for shared folders vs. shared address books.

If you choose to migrate copies to all users who had rights to an item in GroupWise, the program will migrate a complete copy for each user, and the multiple copies will become independent of one another upon migration. That is, any changes made to User A’s copy will apply only to User A's copy, and not to User B's or any other user's independent copy.

If you choose to migrate shared folders only for the owner, Migrator for GroupWise can recreate the access rights in Exchange, so that the migrated item will be re-shared with the same users who had access to it in GroupWise. If no predefined Exchange access level corresponds exactly to the access level in the source, Migrator for GroupWise assigns a combination of discrete rights (some combination of Folder Visible, Read Full Details, Create Items, Delete All, etc.) to a customized permissions level that appears in the Exchange Properties as "Custom."

If you choose to migrate shared folders for their owners only, but do not choose to recreate the GroupWise permissions in Exchange, Migrator for GroupWise will simply leave the items accessible only to their owners.

NOTE: Note: When migrating shared folders and making them visible to shared recipients in Outlook: The parent folders' permissions are modified to add "folder visible" for those users, for all future new folders created under the common root.

Migration of shared address books works much the same as for shared folders. You can migrate a separate copy for each user who had access in GroupWise, or migrated one copy only to the owner. And if you migrate just one copy to the owner, you can tell Migrator for GroupWise to recreate the access rights in Exchange.

Finally, Migrator for GroupWise can migrate GroupWise proxy rights to the corresponding delegate rights in Exchange.

For each of the three types—shared folders and address books, and migrated proxy rights—Migrator for GroupWise offers the option to generate merged notification emails to users, explaining how they can access their items.

Your Migration Plan should specify whether and how you will migrate access rights to shared folders, shared address books, and proxy/delegate rights.

Migrating recurring appointments, tasks and reminder notes

Migrator for GroupWise preserves recurring events (appointments, tasks and reminder notes) as a recurring series in Exchange. This functionality is unique to Migrator for GroupWise.

Invitations and updates leaving GroupWise do not include the recurrence rules (if any), so Migrator for GroupWise includes advanced technology to generate a matching recurrence rule. A rule/pattern is required to preserve the recurrence "link" between meeting instances in Exchange.

Novell’s algorithm for generating unique calendar identifiers is proprietary. These unique identifiers must match in order to properly process updates, cancellations and responses. Since these identifiers cannot be generated outside the GroupWise system, some limitations may exist when processing updates and cancellations initiated in Exchange for appointments created in GroupWise.

Despite this limitation, the recurrence rule technology within Migrator for GroupWise provides a vastly improved end-user experience during and after a migration to Exchange.

Related Documents