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

Desktop considerations

If user workstations will need Outlook installed or upgraded, you must determine before the first users are migrated how you will accomplish the installations or upgrades. There is a MAPI service that permits the use of Outlook to access GroupWise, but users in most organizations will be using the native GroupWise client. Remember that installing Outlook requires administrator privileges on end users' machines. You can use a configuration management program to distribute and install Outlook. New profiles can be defined during or after the Outlook installation.

If any of your users will need software installed, upgraded or reconfigured, your Migration Plan should note this as one phase of tasks to be performed, and should specify exactly what must be done for which users.

Batch vs. per-desktop migration

The batch-migration program and the Self Service Desktop Migrator both can migrate the same types of data, so the overall migration will usually be more efficient if an administrator can use the batch-migration program to migrate all or most users in batches. A user batch typically numbers a hundred or so users, all migrated together in a single program run. Your Migration Plan should specify whether you will migrate users in batches, or one at a time, or by some combination of the two.

Consider that Migrator for GroupWise’s Administrator-Driven Batch Migrator program can migrate users' archives only if they reside in a single centralized location, or if the archive locations can be specified per user in the accompanying user-list .csv file. Batch migration may therefore require that users copy their archives to a central location if they are not currently stored on a network drive, or an admin may have to manually add the per-user archive locations to the .csv file prior to running the batch-migration program.

Alternatively, the Self Service Desktop Migrator can be used to migrate archives, one user at a time, after the batch-migration program has migrated the users’ server-based data. If user archives are not centrally accessible, or if some other circumstance or preference makes batch migration impractical or inadvisable, the Self Service Desktop Migrator is simple and intuitive enough that most end users will be able to run it uneventfully.

Some administrators prefer to visit select desktops personally, running the Self Service Desktop Migrator on behalf of end users, to ensure a smooth transition for executives, or for some users who may be uncomfortable attempting the tasks themselves.

Grouping users for batch migration

If you intend to migrate any user data by batches, your Migration Plan should specify how you will group your users for migration. It is often helpful to migrate users in logical groups, related by business function or administrative entity, or by physical proximity (for example, one floor of a building), so users can support one another through the transition. The Migration Plan should also specify:

Number of Users Per Batch: The optimum number of users per migration batch should correlate to the capacity of your organization's Help desk, since you can assume that the transition will stimulate increased demand for Help resources. Note also the per-user data volume on the server, the data geography (physical distribution) and bandwidth, and the capacities and configuration of the destination servers. Consider that the programs’ log files will likely bloat to unwieldy sizes for batches much greater than 100 users if you ever need to set logging to verbose mode.
Migration Scheduling: Determine how you will schedule batches for migration. This is often just a matter of avoiding each group’s critical dates on the calendar. For example, avoid disrupting finance and accounting staff at the beginning of the month when they are trying to close the books, and try not to distract sales staff near the end of a quarter when they are trying to meet their quotas. Many organizations migrate their IS or Help Desk staff first, since they are typically the most technical users and will likely help to support other users as the migration proceeds.

Method of access to GroupWise user data

The Administrator-Driven Batch Migrator must have access to users' GroupWise accounts to migrate user data to the new Exchange environment. If you are migrating from GroupWise version 6.5 or higher, the migration program will use Novell’s Trusted Application API feature to automatically register itself as a trusted application, and will then be able to migrate GroupWise user data without user passwords or proxy authorization. But if the source GroupWise version is earlier than 6.5, the Migrator for GroupWise programs will need to access users’ GroupWise data either by password or by proxy, as described below.

The easiest way to provide access to GroupWise accounts (when necessary) is to have the program reset all migrating users' passwords, and then use the new known password values to login under each user's login identity. With this migration-by-password method, the batch-migration program can reset users' passwords before accessing their GroupWise accounts. The program can reset all users' passwords to a single common value, or can set each user's password to a value that was previously entered in the user-list .csv file. Alternatively, you can set each user's password to a unique random string of characters.

If resetting passwords is impractical or otherwise inadvisable, Migrator for GroupWise also supports batch migrations by proxy (rather than by password). That is, the program can login to each user's account using the credentials of an admin account that has previously been authorized, by proxy, to access the user account. Migrator for GroupWise includes a utility called Addproxy that automates the process of establishing proxy rights for this purpose.

Your Migration Plan should specify which method you will use to access GroupWise user data. While Quest applications support both methods, the password-access method will almost always be more efficient. The proxy method affects the timing and complexity of a migration project because users cannot be migrated until they have granted the appropriate proxy rights to the administrator. Quest Addproxy program automates this process and can execute automatically from users’ network login scripts, but the utility will run only upon each user's next login — which may not be a daily or even weekly occurrence for some users. The Addproxy utility automatically logs the successful procurement of proxy rights for each user, but the administrator must then review the list of user proxies to determine whose proxy rights remain outstanding, and then migrate those users separately at a later time.

Two other disadvantages of the proxy-access method are that resources cannot be migrated and mail-forwarding rules cannot be set or removed.

While the password-access method is preferred in most circumstances, some organizations will want to keep the GroupWise environment running and accessible for some time after the migration. In this case it would be unwise to standardize users' GroupWise passwords to a common, known value, which would leave their accounts vulnerable to unauthorized access by other users. The program's access to GroupWise accounts for the migration should therefore be accomplished by one of the other methods described above.

Related Documents