GMEUserGuide

User Guide

Version 3.5

Quest GroupWise Migrator for ExchangeGroupWise Migrator for Exchange User GuideUpdated - January 2007 (Doc ID 003)Software Version - 3.5

2007 Quest Software, Inc.ALL RIGHTS RESERVED.

This guide cdescribed inThis softwaagreement.means, elecother than tInc.

If you have

Quest SoftwLEGAL Dept5 Polaris WaAliso Viejo,

www.quest.email: legal

Refer to our

DISCLAIM

The informalicense, expgranted by tFORTH IN QFOR THIS PEXPRESS, IMBUT NOT LIPARTICULAFOR ANY DIDAMAGES (BUSINESS IINABILITY TPOSSIBILITrespect to thright to maknotice. Quedocument.ontains proprietary information protected by copyright. The software this guide is furnished under a software license or nondisclosure agreement. re may be used or copied only in accordance with the terms of the applicable No part of this guide may be reproduced or transmitted in any form or by any tronic or mechanical, including photocopying and recording for any purpose he purchaser's personal use without the written permission of Quest Software,

any questions regarding your potential use of this material, contact:

are World Headquarters

yCA 92656

[email protected]

Web site for regional and international office information.

ER

tion in this document is provided in connection with Quest products. No ress or implied, by estoppel or otherwise, to any intellectual property right is his document or in connection with the sale of Quest products. EXCEPT AS SET UEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT RODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY

PLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, MITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A R PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE RECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, NTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR O USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE Y OF SUCH DAMAGES. Quest makes no representations or warranties with e accuracy or completeness of the contents of this document and reserves the e changes to specifications and product descriptions at any time without

st does not make any commitment to update the information contained in this

User Guide

iii

TRADEMARKS

Quest, Quest Software, the Quest Software logo, Aelita, AppAssure, Benchmark Factory, Big Brother, DataFactory, DeployDirector, ERDisk, Fastlane, Final, Foglight, Funnel Web, I/Watch, Imceda, InLook, IntelliProfile, Internet Weather Report, InTrust, IT Dad, JClass, Jint, JProbe, Knowledge Xpert, LeccoTech, LiteSpeed, LiveReorg, Matrix Insight, Matrix.Net, RAPS, SharSpotlight, SSQLProtectoVintela, VirtSoftware, Inregistered tMIQ, NBSpool, NetBase, Npulse, PerformaSure, PL/Vision, Quest Central, ePlex, Sitraka, SmartAlarm, Speed Change Manager, Speed Coefficient, QL Firewall, SQL Impact, SQL LiteSpeed, SQL Navigator, SQLab, SQLGuardian, r, SQL Watch, Stat, Stat!, StealthCollect, Tag and Follow, Toad, T.O.A.D., ual DBA, Xaffire, and XRT are trademarks and registered trademarks of Quest c in the United States of America and other countries. Other trademarks and

rademarks used in this guide are property of their respective owners.

CONTENTS

ABOUT THIS GUIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12HOW TO USE THE PRODUCT DOCUMENTATION . . . . . . . . . .12

ABO

CHAPTER

ABO

PREv

DOCUMENTATION CONVENTIONS . . . . . . . . . . . . . . . . . . .14

UT QUEST SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . .15CONTACTING QUEST SOFTWARE . . . . . . . . . . . . . . . . . . .15CONTACTING CUSTOMER SUPPORT. . . . . . . . . . . . . . . . . .15

1: INTRODUCTION AND PLANNING . . . . . . . . . . . . . . . .17

UT GROUPWISE MIGRATOR FOR EXCHANGE. . . . . . . . . . . . .18PRODUCT COMPONENTS . . . . . . . . . . . . . . . . . . . . . . . .19

SYSTEM REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . .20

Network Security Considerations and Options . . . . . . . . 20

How To Set the "Receive As" Privilege in Exchange. . . . . 20

Requirement Specifications . . . . . . . . . . . . . . . . . . . . . 21

-MIGRATION PLANNING AND TESTING . . . . . . . . . . . . . . . .23DEVELOP A WRITTEN MIGRATION PLAN . . . . . . . . . . . . . . .23

STRATEGIC PLANNING ISSUES . . . . . . . . . . . . . . . . . . . .24

Batch vs. Per-Desktop Migration. . . . . . . . . . . . . . . . . . 24

Migration Scale and Duration . . . . . . . . . . . . . . . . . . . . 25

Before-and-After Site Configurations. . . . . . . . . . . . . . . 27

Coexistence and Synchronization . . . . . . . . . . . . . . . . . 28

Provisioning in Active Directory . . . . . . . . . . . . . . . . . . 30

Method of Access to GroupWiseUser Data by Password or by Proxy. . . . . . . . . . . . . . 31

Desktop Considerations. . . . . . . . . . . . . . . . . . . . . . . . 32

Multi-Workstation Considerations . . . . . . . . . . . . . . . . . 32

Phased Migration Strategy . . . . . . . . . . . . . . . . . . . . . . 33

Strategies for Migrating Resources . . . . . . . . . . . . . . . . 34

Strategies for Migrating Groups (Distribution Lists). . . . . 35

Accommodating Known Limitations of theMigration Process and Other Special Circumstances . . . . 36

Migrating from an Older Version of GroupWise . . . . . . . . 36

End User Communications . . . . . . . . . . . . . . . . . . . . . . 36

TEST AND PILOT MIGRATIONS . . . . . . . . . . . . . . . . . . . .37

Quest GroupWise Migrator for Exchange

vi

CHAPTER 2: MIGRATION PROCESS INSTRUCTIONS . . . . . . . . . . . .39

PROCESS INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . .40NECESSARY PRE-MIGRATION PREPARATIONS. . . . . . . . . . . . . . .40

Step 1:

BAT

MIGVerify that All System Requirements Are Satisfied . . . . . 41

Step 2: Prepare theAddproxy Program to Establish User Proxies . . . . . . . . . 41

Step 3:Create a Temporary Subdomain for the Migration. . . . . . 41

Step 4: Create aRecipient Policy for the Temporary Subdomain. . . . . . . . 41

Step 5:Provision Active Directory with NDS Users and Groups . . 42

Step 6: Run Quest's Directory Exporter . . . . . . . . . . . . . 42

Step 7:Review and Modify (If Necessary) the Data Files . . . . . . 42

Step 8: Mail-Enable All Users AD Accounts . . . . . . . . . . 42

Step 9: Provision Public Distribution Lists in Exchange . . 43

Step 10: Modify the MX Record . . . . . . . . . . . . . . . . . . 43

Step 11: Set RemoveSrcAddresses=1 in gwmigapp.ini . . 43

Step 12 (If Necessary): Move Users Archivesand PABs to a Centralized, Accessible Location. . . . . . . . 43

CH MIGRATION PROCESS (PER USER GROUP) . . . . . . . . . . .44Step 1: Accommodate Any Recent Staff Changes . . . . . . 44

Step 2: Prepare a Migration Group User-List .csv File . . . 45

Step 3: Run Quest's Administrator-DrivenBatch Migrator to Perform Administrative Functions . . . . 47

Step 4: Synchronize the Two Directories . . . . . . . . . . . . 48

Step 5: Run Quest's Administrator-DrivenBatch Migrator to Migrate User Data . . . . . . . . . . . . . . . 48

Step 6: Distribute .pst Files (If Any) . . . . . . . . . . . . . . . 48

RATION PER DESKTOP. . . . . . . . . . . . . . . . . . . . . . . . . .48Customizing the Self-Service Desktop Migrator . . . . . . . 49

Before Running the Self-Service Desktop Migrator . . . . . 49

Distribution of Self-Service Desktop Migrator Program . . 49

Notifications to End Users . . . . . . . . . . . . . . . . . . . . . . 50

User Guide

Command-Line Switches forRunning the Desktop Migrator in Silent Mode. . . . . . . . . 50

If a User Does Not Appear To Be Migrated(After Running the Self-Service Desktop Migrator) . . . . . 51

POST-MIGRATION CLEAN-UP . . . . . . . . . . . . . . . . . . . . . . . .52

CHAPTER

ABOOPEREV

CHAPTER

OVEPERvii

3: DIRECTORY EXPORTER . . . . . . . . . . . . . . . . . . . . . .53

UT DIRECTORY EXPORTER . . . . . . . . . . . . . . . . . . . . . . .54RATING INSTRUCTIONS . . . . . . . . . . . . . . . . . . . . . . . . .55IEW AND MODIFY (IF NECESSARY) THE DATA FILES . . . . . . . .57

4: ADMINISTRATOR-DRIVEN BATCH MIGRATOR . . . . . . .59

RVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60-SCREEN INSTRUCTIONS AND APPLICATION NOTES . . . . . . . .611: WELCOME SCREEN . . . . . . . . . . . . . . . . . . . . . . . . .61

2: SELECT OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . .62

3: SPECIFY USERS FOR UPDATE . . . . . . . . . . . . . . . . . . .63

4: SELECT GROUPWISE ADMINISTRATIVE OPERATIONS . . . . .64

5: GROUPWISE FORWARDING OPTIONS . . . . . . . . . . . . . .65

6: SPECIFY SOURCE-TO-TARGET MAIL FOWARDING DOMAIN . .66

API Gateway vs. SMTP . . . . . . . . . . . . . . . . . . . . . . . . 67

7: SPECIFY GROUPWISE PASSWORDS . . . . . . . . . . . . . . .68

8: SELECT GROUPWISE VISIBILITY . . . . . . . . . . . . . . . . .69

9: SELECT EXCHANGE ADMINISTRATIVE OPERATIONS . . . . . .69

10: SPECIFY ACTIVE DIRECTORY INFORMATION. . . . . . . . . .70

11: SPECIFY EXCHANGE MAILBOX INFORMATION . . . . . . . . .72

12: SPECIFY TARGET-TO-SOURCEMAIL FORWARDING DOMAIN . . . . . . . . . . . . . . . . . . . . .72

13: SPECIFY DATA FOR MIGRATION. . . . . . . . . . . . . . . . .73

14: SELECT DATE AND SIZE FILTERS. . . . . . . . . . . . . . . .75

15: SPECIFY GROUPWISE INFORMATION . . . . . . . . . . . . . .76

16: SPECIFY GROUPWISE LOGIN INFORMATION . . . . . . . . .76

17: SPECIFY DESTINATIONS FOR MIGRATED DATA . . . . . . . .78

18: SPECIFY HOW TO MIGRATE SHARED INFORMATION . . . . .79

19: SELECT DESTINATION EXCHANGE SERVER . . . . . . . . . .81


viii

20: SPECIFY PST OUTPUT ROOT DIRECTORY . . . . . . . . . . .82

21: SPECIFY GROUPWISE DOMAIN PATH . . . . . . . . . . . . .84

22: SPECIFY RUN INFORMATION. . . . . . . . . . . . . . . . . . .85

23: MIGRATION SETTINGS SUMMARY . . . . . . . . . . . . . . . .86

REM

APPENDIX

ADDINST

ADD

APPENDIX

APPENDIX

APPENDIXSELF-SER

PRO24: PROGRESS SCREEN . . . . . . . . . . . . . . . . . . . . . . . .87

25: RESULTS SCREEN . . . . . . . . . . . . . . . . . . . . . . . . .88

EMBER TO DISTRIBUTE ANY USER .PST FILES . . . . . . . . . . .89

A: ADDPROXY UTILITY . . . . . . . . . . . . . . . . . . . . . . .91

PROXY PREREQUISITES . . . . . . . . . . . . . . . . . . . . . . . . .91ALLING ADDPROXY . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Uninstalling the AddProxy Program. . . . . . . . . . . . . . . . 93

PROXY.INI SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . .93addproxy.ini Required Parameters . . . . . . . . . . . . . . . . 93

addproxy.ini Optional Parameters. . . . . . . . . . . . . . . . . 95

B: AD OBJECT MERGE TOOL . . . . . . . . . . . . . . . . . . .97

BEFORE YOU BEGIN ... . . . . . . . . . . . . . . . . . . . . . . . .97

OPERATING INSTRUCTIONS . . . . . . . . . . . . . . . . . . . . . .98

C: LOG FILE VIEWER . . . . . . . . . . . . . . . . . . . . . . .103

TO CHANGE THE SORT ORDEROF THE LOG FILE NAVIGATOR. . . . . . . . . . . . . . . . . . . .105

TO GENERATE A USER-LIST .CSV FILEOF "ERROR USERS" (IN THE LOG FILE). . . . . . . . . . . . . .105

TO GENERATE A REPORT OF THE LOG FILE. . . . . . . . . . . .106

D: CUSTOMIZING THEVICE DESKTOP MIGRATOR PROGRAM. . . . . . . . . . . . . .107

VIDING PROGRAM ENTRY VALUES IN GWDTAPP.INI. . . . . . . .108Migration Choices inthe Specify Data for Migration Screen . . . . . . . . . . . . . 108

Outlook Profile in the Select Profile Screen . . . . . . . . . 109

Archive Destination Folder inthe Specify Directory for Migrated Archive Screen . . . . 110

User Guide

Filter Conditions in theSelect Date and Size Filters Screen. . . . . . . . . . . . . . . 110

HIDING ENTIRE SCREENS FROM THE USER . . . . . . . . . . . . . . .111HIDING CERTAIN USER CHOICES ONTHE SPECIFY DATA FOR MIGRATION SCREEN. . . . . . . . . . . . . .112FOR

APPENDIXFOR EXCH

APPENDIX

GLOSSARYix

EXAMPLE: TO MIGRATE ARCHIVES ONLY . . . . . . . . . . . . .113

E: HOW GROUPWISE MIGRATORANGE MAPS SHARED FOLDERS TO OUTLOOK . . . . . . . . .115

F: KNOWN LIMITATIONS OF THE MIGRATION PROCESS .117

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119


x

Abo

ut This Guide

Overview How To Use the Product Documentation

Documentation Conventions

About Quest Software Contacting Quest Software

Contacting Customer Support


12

OverviewThis document has been prepared to explain the intended uses and operating instructions for Quest Softwares GroupWise Migrator for Exchange, and to explain how GroupWise Migrator tools are most typically used within the broader context of

How T

The documprintable P

The Quickintended fprofessioncontributeintended fMigrator c

This Groupand six apinformatiovariety of instructionmigration an overall migration project.

o Use the Product Documentation

entation for Quest GroupWise Migrator for Exchange includes three DF documents:

Quick-Start Guide: An orientation to the product's basic purposes and features, and to how its component tools are most typically used within the broader context of an overall migration project. The Quick-Start Guide also includes instructions for downloading and installing the software, and a procedure to help you assess the product's suitability for your own needs and circumstances.

GroupWise Migrator for Exchange User Guide: The document you are now reading, with operating instructions and application notes for the components of GroupWise Migrator for Exchange that are used by administrators, an in-depth look at pre-migration planning, and recommended approaches for the most common migration scenarios and strategies.

Self-Service Desktop Migrator User Guide: Operating instructions and application notes for the Self-Service Desktop Migrator component of GroupWise Migrator for Exchange. The Self-Service Desktop Migrator User Guide is provided as a separate document so that an administrator can distribute it to any end users who will run the per-desktop program.

-Start Guide and GroupWise Migrator for Exchange User Guide are or network administrators, consultants, analysts, and any other IT als who will install the product, use its administrative tools, or to migration project planning. The Desktop Migrator User Guide is or end users or administrators who will use the Self-Service Desktop omponent.

Wise Migrator for Exchange User Guide is organized into four chapters pendixes. The first two chapters provide orientation and planning n, with broad-context process instructions for how to accomplish a migration strategies, while chapters 3 and 4 provide operating s for the two product components that are used in virtually all scenarios:

User Guide

1. Introduction and Planning: An orientation to the products purpose and capabilities, and a checklist of topics and issues that should be considered in pre-migration planning.

2. Migration Process Instructions: Step-by-step instructions for how to accomplish particular migration strategies and scenarios with

3.

4.

The appenless-routinsupplemenstrategies:

A.

B.

C.

D.

E.

F.

We strong

These sectmigration to help yothe needs imperative13

Quests tools. This chapter explains the contexts in which Quest tools are used. Wherever these procedures call for the application of Quest tools, the scenario-oriented instructions refer to tool-specific operational details in chapters 3 and 4, and in the appendixes.

Directory Exporter: Operating instructions and application notes for the Directory Exporter component of GroupWise Migrator for Exchange.

Administrator-Driven Batch Migrator: Operating instructions and application notes for the Administrator-Driven Batch Migrator component of GroupWise Migrator for Exchange.

dixes provide operating instructions and application notes for the ely used "accessory" components of the product, and other tal information you may find useful for particular migration

Addproxy Utility: Operating instructions and application notes.

AD Object Merge Tool: Operating instructions and application notes.

Log File Viewer: Operating instructions and application notes.

Customizing the Self-Service Desktop Migrator Program.

How GroupWise Migrator for Exchange Maps Shared Folders to Outlook.

Known Limitations of the Migration Process.

ly recommend that all administrators read all of:

The Quick-Start Guides Product Overview and two Walkthrough sections.

The first two chapters of this GroupWise Migrator for Exchange User Guide.

ions in particular are designed to familiarize you with how Quests tools fit into the broader context of an overall migration process, and u devise a migration strategy and a written Migration Plan that suits of your network configuration, your users, any institutional s of your organization, and of course your own preferences.


14

You may then follow the appropriate process instructions in chapter 2 to implement your strategy(ies), and refer as needed to the product operational details in chapters 3 and 4, and in the appendixes.

Documentation Conventions

In order toformattingkeystrokes

E

S

B

It

B

B help you get the most out of this guide, we have used specific conventions. These conventions apply to procedures, icons, and cross-references.

LEMENT CONVENTION

elect This word refers to actions such as choosing or highlighting various interface elements, such as files and radio buttons.

olded text Interface elements that appear in Quest products, such as menus and commands.

alic text Used for comments.

old Italic text Used for emphasis.

lue text Indicates a cross-reference. When viewed in Adobe Reader, this format can be used as a hyperlink.

Used to highlight additional information pertinent to the process being described.

Used to provide Best Practice information. A best practice details the recommended course of action for the best result.

Used to highlight processes that should be performed with care.

Ctrl+C A plus sign between two keystrokes means that you must press them at the same time.

Edit | Copy A pipe sign between elements means that you must select the elements in that particular sequence.

User Guide

About Quest SoftwareQuest Software, Inc. delivers innovative products that help organizations get more performance and productivity from their applications, databases and infrastructure. Through a deep expertise in IT operations and a continued focus on what whigher expCalifornia,

Conta

Please refe

Conta

Quest Softproduct in

You can us

15

orks best, Quest helps more than 18,000 customers worldwide meet ectations for enterprise IT. Quest Software, headquartered in Irvine, can be found in offices around the globe and at www.quest.com.

cting Quest SoftwarePhone 949.754.8000 (United States and Canada)

Email [email protected]

Mail Quest Software, Inc.5 Polaris WayAliso Viejo, CA 92656USA

Web site www.quest.com

r to our Web site for regional and international office information.

cting Customer Support

ware's world-class support team is dedicated to ensuring successful stallation and use for all Quest Software solutions.

SupportLink http://www.quest.com/support

Email at [email protected].

e SupportLink to do the following:

Create, update, or view support requests

Search the knowledge base

Access FAQs

Download patches


16

Intr

AE

P

1oduction and Planning

bout GroupWise Migrator for xchange

Product Components

System Requirements

re-Migration Planning and Testing

Develop a Written Migration Plan

Strategic Planning Issues

Test and Pilot Migrations


18

About GroupWise Migrator for ExchangeQuest Softwares GroupWise Migrator for Exchange is a set of related software applicationorganizatioExchange complemeConnectorproject-scGroupWise

Exacad

Mipeen(.p

Mith

Coth

SeExpe

In a typicaExchange hundreds per-desktodesktops tsame per-administrabatches, bper-deskto

Quests Groptions thamigration s designed to facilitate a variety of migration strategies for ns moving from Novell GroupWise, versions 5.5.3 to 7.0, to an

2003 or 2007 environment. The Quest applications are designed to nt another Quest product, NDS Migrator, and Microsoft's Exchange for GroupWise and Outlook deployment tools, to provide a ale approach to overall migration planning and management. Migrator for Exchange can:

tract user data from the GroupWise server to mailbox-enable user counts in the Active Directory, and preserve users' current SMTP dresses in their new AD accounts.

grate users' mail, appointments, tasks, personal address books, rsonal distribution lists and frequent contacts from the GroupWise vironment to the Exchange environment or Outlook Personal Folders st) files.

grate users' archives from GroupWise to either Outlook .pst files, or e new server.

py each users GroupWise folder hierarchy into Exchange, and migrate e permissions that facilitate the sharing of folders.

t and remove mail-forwarding rules between GroupWise and change to assure correct mail routing throughout the transition riod.

l scenario, an administrator uses the GroupWise Migrator for batch-migration program to migrate groups of dozens or even of users at a time. But the Quest applications also contain a p migration program that lets an administrator visit individual o perform migrations one user at a time, or end users can run the desktop program to perform their own migrations. For that matter, an tor can mix-and-match these strategies: migrating some users in ut others individually at their desktops, while still other users run the p tool themselves.

oupWise Migrator for Exchange supports several such operational t allow considerable flexibility in devising and implementing a suitable

strategy for almost any set of circumstances and preferences.

Introduction and Planning

Product Components

GroupWise Migrator for Exchange contains several separate but related applications, which may be used in various combinations to accomplish a wide range of migration strategies:

DitoQu

ADseExmeanma

Adusus

Adprorus

Seadan

Loprdo19

rectory Exporter: Extracts user data from the GroupWise directory build four data files, which will provide necessary source data to other est applications.

Object Merge Tool: Merges users GroupWise addresses into AD curity objects, to mail-enable the accounts. Also, if the program finds change Contacts for users who also have AD accounts, the program rges some of the Contact attributes into the corresponding accounts, d then deletes the Contacts, to merge the pair into a single il-enabled security object per user.

dproxy: Automates the process of setting proxy rights for migrating ers. (Used only for administrator-driven migrations when resetting ers' GroupWise passwords is impractical or otherwise inadvisable.)

ministrator-Driven Batch Migrator: Used by an administrator to ovision GroupWise public distribution lists (PDLs) in Active Directory, to perform any or all of these tasks for the users identified in a er-list .csv file:

Mailbox-enable Exchange accounts.Change the GroupWise passwords for migrating users.Extract users' GroupWise data and migrate it to Exchange.Update mail-forwarding rules for groups of migrating users.Specify users' visibility in the GroupWise directory.

lf-Service Desktop Migrator: Used by end users, or by ministrators on behalf of end users, to extract users GroupWise data d migrate it to Exchange.

g File Viewer: Simplifies the viewing and interpretation of Quest ogram log files, which are generated by most Quest applications to cument process errors and warnings.


20

System Requirements

Network Security Considerations and Options

Different organizations have different network security standards that determine the numbemigration.admin accExchange

Ingrmiwilogcre

Many orgaauthority iaccounts, of the ove

OnacwhthAdac

A ADAdad

How To

When migExchange be configuRequireme

To set the

1. La

2. Tyr and configuration of user accounts necessary to perform a The most straightforward approach is to configure a single migration ount in Active Directory with all the necessary rights in both AD and to run a full migration:

Active Directory, this account must be added to the Domain Admins oup. On each Exchange Mailbox Store to which the users are grating, the account must be added to the security access control list th at least Receive As rights. This single account must then be used to in to the migration workstation, and provide the Exchange Server dentials and the Active Directory credentials as needed.

nizations, however, prefer not to concentrate so much administrative n a single account. The alternative is to configure two separate each with more restrictive access rights, to perform different portions rall migration process. For example:

e account to login to the migration workstation: A domain user count in Active Directory, with Read/Write delegate access on all OUs ere users and groups will be provisioned. On the Exchange server,

is account will need Exchange Administration delegate access to the ministrative Group where the users mailboxes will be created. This count must then be used to login to the migration workstation.

separate account to provide Exchange Server credentials and credentials: A user object in Active Directory, added to the Domain mins group. On every Exchange Mailbox Store, this account must be ded to the security access control list with at least Receive As rights.

Set the "Receive As" Privilege in Exchange

rating to Exchange, the admin account that will be used to provide server credentials and AD credentials from the Quest programs must red with Receive As rights to each mailbox store, as noted in the nt Specifications below.

Receive As privilege in Exchange 2007 (for all mail stores):

unch an Exchange Management Shell.

pe (in one continuous line):

get-mailboxdatabase | add-adpermission-user -extendedrights Receive-As


To set the Receive As privilege in Exchange 2003 (for each mail store):

1. In Exchange System Manager, in the folder tree: Drill down through:

Administrative Groups [Admin Group Name] Servers

2. Rig

3. In

4. Inwa

5. Inch

6. Cli

Require

The requir

On

http://www

On

On

21

[Server Name] [Storage Group Name] Mailbox Store

ht-click on Mailbox Store, and select Properties.

the Properties dialog box, click the Security tab.

the Group or user names list, select the name of the account you nt to endow with the privilege.

the Permissions for [Account Name] chart, click the Allow eckboxes for Receive As and Send As.

ck OK to save the settings and clear the Properties dialog box.

ment Specifications

ements for GroupWise Migrator for Exchange 3.5 include:

the GroupWise server:

Must be running Novell GroupWise version 5.5.3 to 7.0.An admin account must be defined with administrator rights to the GroupWise server.If GroupWise Internet Addressing is not enabled, GroupWise Internet Agent LDAP Service must be configured to automate the creation of the Address Translation Table. For more information, see:

.novell.com/documentation/lg/gw55/index.html?gw55ia/data/a2zuwkc.html

the Exchange server:

Must be running either Exchange 2007 or Exchange 2003.An account must be defined with access to the Exchange environment. (A new account with "Receive As" rights to each mailbox store, and not assigned to any group, would be suitable for this purpose.)For Exchange 2003 (only): Recipient Update Service must be set to Always Run.

the Active Directory server:

An account must be defined with administrator access to the Active Directory environment. A new account with rights to add and delete users, and to manipulate AD accounts, would be suitable for this purpose. An account added to the DomainAdmins group would have sufficient rights, although membership in that group also confers other rights that may compromise some organizations security standards.


22

On each administrator workstation (running the GroupWise Migrator for Exchange administrator applications):

To accelerate large-scale migrations, GroupWise Migrator can be run on multiple migration workstations running in parallel.Workstation OS must be Windows XP (32 bit) SP2 or higher, or Windows 2003 Server (32 bit) SP1 or higher. GroupWise Migrator for Exchange does not support a 64-bit OS.

Workstation must be a separate machine from the Exchange server, but a member of the same domain as AD and Exchange, and meeting these minimum hardware requirements:

1+ GHz processor. 1GB memory. 20GB free disk space.

Recommendations for improved performance, especially for high-volume migrations:

3+ GHz processor. 2GB memory. 1 Gbps NIC. 1 Gbps or faster network connections among all migration

workstations and the Exchange and GroupWise servers.Required for any Exchange 2003 administrative functions:

Windows Admin Tools (adminpak.msi). Exchange System Manager (version to match the installed version of

Exchange).Required for any Exchange 2007 administrative functions:

Exchange 2007 Management Tools, which in turn requires .Net Framework 2.0, Microsoft Management Console (MMC), and Microsoft Windows PowerShell.

Must have a directory with write/execute permissions for the Administrator components of the Quest software, and must have a directory with read/execute permissions for the user components of the software.A profile must be defined with administrator access to the Exchange environment ("Receive As" permission to each mail store).

Order of Installation: A migration requires an unusual combination of tools, developed by different vendors, all installed on this single admin workstation, and the combination can cause compatability problems on some machines. To minimize these conflicts, Quest recommends that you install the applications (per the specifications noted below) in this particular order:

1. Windows Messaging Subsystem2. GroupWise client3. Outlook client4. Microsoft PowerShell (only if migrating to Exchange 2007)5. ConsoleOne6. Exchange Admin tools


Must be a machine where the code page associated with the runtime locale is identical to the encoding for each mailbox being migrated. The GroupWise APIs used to retrieve the data do not support retrieval of data from outside the current code page. For example, if the migration server were configured on a German machine (using code page 1252) and used to migrate a mailbox containing Polish data (using code page 1250), data would be lost during the

On

Al

Pre-M

Devel

The migracareful plaof necessathat must sequence,

The complcommunic23

migration.The Novell NetWare Administrator program (NWAdmin or ConsoleOne) must be installed. GroupWise Directory Exporter has the same prerequisites as the NetWare Administrator program.The Novell client for NetWare (client version 4.7 or higher, 4.91 SP2 recommended), and the GroupWise client must both be installed, and a Novell GroupWise profile must be present. When migrating from GroupWise 7 running on a SUSE Linux server, the NetWare client must be logged into eDirectory. Otherwise (if migrating from a Netware server), the NetWare client must be logged into NetWare. For GroupWise 6.5 and earlier, the Novell GroupWise profile must be set as the default profile.Outlook 2000, 2002 or 2003 must be installed, and the Outlook profile must be configured to always prompt for credentials. Note:

If GroupWise 5.5 is installed on the server, then Outlook 2000 or 2002 (not 2003) is required. (Outlook 2003 is incompatible with GroupWise 5.5, so that combination is not supported.)

The MAPI DLLs required to perform a migration must be those that are part of Outlook, not the downloadable Exchange 2007 "server" MAPI.

user desktops (if running the Self-Service Desktop Migrator):

Must be running Microsoft Windows 2000 (or higher).Must be running Outlook 2000, 2002 or 2003.Must be running a GroupWise client version 5.5.3 to 7.0.

l machines:

Must have network access.

igration Planning and Testing

op a Written Migration Plan

tion of any enterprise is typically a complex process that requires nning and project management. Even a high-level summary checklist ry tasks can be quite long, and will expose a good number of details be addressed for a successful migration. The "choreography" in the timing, and coordination of tasks is also important.

exity of most migration projects makes planning, foresight and ations critical to a smooth migration. Halfway through the migration


24

process is no time to discover that a neglected detail or invalid assumption will cost the organization dozens or hundreds of hours of productivity, or cause unnecessary aggravation for end users. Quest therefore recommends you develop a comprehensive written Migration Plan before you begin any migration process.

Developingand accomAt a minimIssues des

Strate

Batch v

The batch-migrate thefficient if or most usall migratewhether ycombinatio

Consider tusers' archlocations cmigration location if have to mrunning th

Alternativeone user aserver-bascircumstanthe Self-Susers will

Some admSelf-Servictransition tasks them

If you intenote your a Migration Plan is a valuable exercise that will lead you to consider modate all of the factors likely to affect an organization's migration. um your plan should address or consider all of the Strategic Planning cribed below.

gic Planning Issues

s. Per-Desktop Migration

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

hat Quests Administrator-Driven Batch Migrator program can migrate ives only if they reside in a single centralized location, or if the archive an be specified per user in the accompanying user-list .csv file. Batch may therefore require that users copy their archives to a central they are not currently stored on a network drive, or an admin may anually add the per-user archive locations to the .csv file prior to e batch-migration program.

ly, the Self-Service Desktop Migrator can be used to migrate archives, t a time, after the batch-migration program has migrated the users ed data. If user archives are not centrally accessible, or if some other ce or preference makes batch migration impractical or inadvisable,

ervice Desktop Migrator is simple and intuitive enough that most end be able to run it uneventfully.

inistrators prefer to visit select desktops personally, running the e Desktop Migrator on behalf of end users, to ensure a smooth

for executives, or for users who may be uncomfortable attempting the selves.

nd to migrate any user data by batches, your Migration Plan should requirements and preferences for these aspects of user grouping:


Grouping Method: Determine 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, so users can support one another through the transition.

Optimum Number of Users Per Batch: The optimum number of users peorstidaansesizth

MimidanoclothMaarus

Migrati

A very smtime, but bimpracticasingle run therefore msuch group

The scale factors, bedirectory c(Coexistentopic belowmigration be used tomultiple msimultaneo25

r migration batch depends primarily on the capacity of your ganization's Help desk, since you can assume that the transition will mulate increased demand for Help resources. Note also the per-user ta volume on the server, the data geography (physical distribution) d bandwidth, and the capacities and configuration of the destination rvers. Consider that the programs log files will likely bloat to unwieldy es for batches much greater than 100 users if you ever need to set e logging to verbose mode.

gration Scheduling: Determine how you will schedule batches for gration. This is often just a matter of avoiding each groups critical tes on the calendar. For example, finance and accounting staff should t be disrupted at the beginning of the month when they are trying to se the books. Likewise, sales staff would prefer no interruptions near

e end of a quarter when they are attempting to meet their quotas. ny organizations migrate their IS or Help Desk staff first, since they

e typically the most technical users and will likely help to support other ers as the migration proceeds.

on Scale and Duration

all organization may be able to migrate all of its users together at one andwidth, processing, and other limitations usually make it

l to migrate larger numbers of users (more than 100 to 150) in a of the batch-migration program. Most mid-sized to large organizations

ust migrate their users in a series of subset migration groups. Each is simply a subset of the universe of all users to be migrated.

and expected duration of a migration project are critical planning cause these things determine whether an organization will require oexistence and directory synchronization during the transition period. ce and Synchronization are explained in more detail in a separate .) The two most important factors that affect the duration of a

are data volume, and the number of migration workstations that will migrate the data. The Admin-Driven Batch Migrator can be run on igration servers running in parallel, applied to different user groups usly. In this way, you might employ a half dozen migration

Note: The first few batches should be smaller than your expected optimum size, since these first groups will likely expose any unforseen problems before a larger group would generate correspondingly larger consequences.


26

workstations to migrate a particular data volume in a single weekend, whereas you would need a half dozen weekends to migrate the same volume via a single workstation.

Data "geography" and bandwidth are the most significant factors affecting the rate of data migration, and migration workstation hardware (memory, number and speedfor the batfactors, bugigabytes dispersed problematrange. Onthe source20 GB/houworkstatio

The chart project, burely on thfactors, anYou cannmenting i

To estimatdetermine

... and the

This formuQuests ba

Band

Very

Good

Fair

Poor of CPUs, and disk speed) is also important. Actual throughput rates ch-migration program vary widely with the interplay of all relevant t administrators typically report migration rates of one to three per hour. If the data to be migrated is distributed among servers in geographic locations, and if the bandwidth among these servers is ic, then the throughput rate will likely be at the lower end of that the other hand, a migration rate of 3 GB per hour or faster is likely if data is centralized and the bandwidth is very good. Rates as high as r have been reported under optimal conditions with high-performance n hardware.

below can help you estimate the throughput rate for your migration t remember that actual rates vary widely and you should not ese values as definitive. The chart does not account for hardware d your assessment of your own bandwidth is subjective and arbitrary. ot reliably predict your own throughput rate without experi-n your own environment with your own data.

e the duration (total processing hours) of a migration project, first the estimated throughput rate:

Estimated Throughput Rates (GB/hr)

n plug the estimated rate value into this formula:

la will help you estimate the number of processing hours required for tch migrator to migrate a particular volume of data under particular

Data Distribution(percent of total data volume that is centralized)

width is ... 0-25% 25-50% 50-75% 75-100%

Good 1.2 1.8 2.4 3.0

1.0 1.6 2.2 2.8

0.8 1.4 2.0 2.6

0.6 1.2 1.8 2.4

Est TotalMigration

Hours=

Total DataVolume (GB) /

Est Through-put Rate

Number of Migration WorkstationsRunning in Parallel


conditions, but remember there is much more to a migration project than just processing time. An administrator must also export directory data from GroupWise sources, provision users and distribution groups into Active Directory, define subset batches of users, and so forth. You should also allow time to review the Quest programs log files, to verify that the programs run parameters are appropriate and efficient, and to catch and correct any minor problems b

Per-desktomigration and you shdesk. You program ra weekendhavent rafrom fresh

For a longecan expectime as thto attempt(processin

Before-

Characterinow and h

Draw a ne

Th Th Th

The netwovisualize ththe inter-n

For each s

Hoad

Thseanacac27

efore they become major problems.

p tasks such as installation of the Outlook client, and sometimes the of archives (separately, per-user) also must be figured into the plan, ould also expect an increased demand on the organizations Help may find that a couple dozen instances of the batch-migration unning on parallel workstations can migrate thousands of users over , but youll face a support nightmare on Monday morning if you mped up your Help desk staff to accommodate all of the likely calls ly migrated users.

r-term migration that will span more than just a couple of weeks, you t that these other associated admin tasks will get easier and take less e project progresses. But these collateral admin tasks make it unwise a single-weekend migration if the estimated migration time g hours) exceeds 20 to 30 hours.

and-After Site Configurations

ze the configuration of the organizations servers, both as they are ow they will be after the migration.

twork map of the pre-migration GroupWise environment, showing:

e locations, domain names and operating systems of all servers.e number of users and total data volume on each server.e bandwidths among the various nodes.

rk map should be a graphical illustration, to help migration planners e relationships between the data volumes of the various servers and ode bandwidths that connect them.

erver, note also (but not necessarily on the same network map):

w users were assigned to each serverby geographic location, or ministrative entity, or some other scheme.

e volume and locations of the various types of source data at each rverthat is, the volume (mega/gigabytes) of user mail, user archives d address books, and whether each type is located in a centrally cessible (server) location, or will be copied or moved to a centrally cessible location, or is located on user desktops.


28

Next, draw another graphical network map to show your post-migration Exchange environment: the locations and domain names of all servers, and the data capacity of each server. Then view the pre-migration and post-migration configuration maps side-by-side, and determine which users from which GroupWise servers will migrate to which Exchange servers. Make a table to document these before-and-after server assignments for each group of users to be migrate

Coexist

Coexistencserving thehave alreaserver, awcan be migbecause thaccommodnecessary

Coexistencsince forwUsers musall active smigration

Coexistencdestinationstaff additsince theirseveral weis in-procedestinationthe migratof one dire

Coexistencmigration,organizatiopermit a s

Synchro

If synchrohigh prioriand updatadministrasynchronizd.

ence and Synchronization

e is the state of two or more independent servers when both are same organization at the same timefor example, when some users dy been migrated to a new server while others remain on the old aiting migration. A migration project small enough that all user data rated in a single weekend will be simpler than a longer-term migration e latter requires additional planning and several extra steps to ate the coexistence and server synchronizations that will likely be

throughout the transition period.

e requires dynamic mail routing throughout the transition period, arding rules must be updated upon the migration of each user batch. t be able to send mail and schedule meetings with one another across ervers, throughout the transition period, without having to know the status of other users.

e also is likely to require regular synchronizations of the source and directories. Most mid-sized and large organizations will experience

ions, departures, transfers, and so forth during the transition period, migrations extend over a period of at least several days, many for eks or even months. Any staff changes that occur while the migration ss will introduce data inconsistencies between the source and servers, and these inconsistencies may need to be reconciled during ion process. Synchronization is the process of updating the contents ctory to match the contents of another.

e and directory synchronization introduce much more complexity to a and several more steps to the process. Its therefore important for an n to determine at the outset whether the scale of the project will

ingle-weekend approach, or require coexistence and synchronization.

nizing Directory Data and Updating Program Data Files

nization of coexisting directories during the transition period is not a ty for the organization, the admin may simply add and delete users e user data in the Exchange environment (only), using Exchange tion software. Otherwise, if it is important to keep the two directories ed throughout the transition period:


Enter any staff changes within the GroupWise environment as they occur, just as you always have.

If any already-migrated user leaves the organization: Delete the user from the Exchange server, using Exchange administration software.

Prior to the migration of each user group:

Email Ro

Your Migralookups (o

Bybu

Byca

Bybu

If any endSMTP metunreadablattachmen

Coexiste

Server accsome speccontains m

Seth

ThQuAD29

Run Microsofts Exchange Connector for GroupWise to re-synchronize the directories, from GroupWise to Exchange. (You need not perform this step explicitly if the Connector is scheduled to automatically re-synch the directories at regular intervals.)Re-run Quest's Directory Exporter to generate new, updated .csv files that will accurately reflect the current staff list. (Remember to review the new .csv files and, if necessary, edit them, as explained in chapter 3.)

uting and Free/Busy Lookups

tion Plan should specify your method of email routing and free/busy r lack thereof):

SMTP addressing via subdomains, which can facilitate email routing t not calendar free/busy lookups.

the Microsoft Connector, with native GroupWise addressing, which n facilitate both email routing and calendar free/busy lookups.

a hybrid scheme, in which email is forwarded via SMTP addressing, t the Microsoft Connector is used for free/busy lookups.

users have Blackberry devices: Note that mail-forwarding via the hod will forward the original message as an attachment, which will be e on devices like the Blackberry that do not support opening email ts.

nce with Multiple AD Domains

ess rights, email routing, and calendar free/busy lookups will need ial attention in a coexistence when the destination environment ultiple AD domains. In this case, your Migration Plan should note:

rver rights must be set to allow the Quest programs to access all of e various domain controllers.

e AD Object Merge Tool and the Exchange administrative functions of ests Admin-Driven Batch Migrator should be run against the primary domain controller, which is less likely to encounter latency errors

Note: SMTP forwarding from GroupWise will introduce reply-ability issues for external recipients.


30

(delays in directory synchronization among the various domain controllers and the Global Catalog).

Be sure to check the run logs for the Admin-Driven Batch Migrator and AD Object Merge Tool. Errors in the log such as:

Unable to create group....

...wa

Provisi

Decide howDirectory. most orgaQuest prodto provisiorespectiveobjects intExchange "mail-enabexternal anecessaryrouted bac

Quests NDadd NDS dthis procesaddressesAdministracreating th

The AdminLists in ADbefore the

Quests ADin AD. Forobjects forcorrespondshould) beContacts aThe AD ObUnable to add group member....

usually indicate latency problems, which can be resolved by simply iting a few minutes and running the program again.

oning in Active Directory

accounts, groups and distribution lists will be provisioned in Active Provisioning may be accomplished by a variety of methods, but for nizations the simplest and most complete will include running another uct, NDS Migrator (not a part of GroupWise Migrator for Exchange), n NDS users and groups as security objects and security groups, ly, in Active Directory. If you use the NDS Migrator to move NDS o AD, you can then use two components of GroupWise Migrator for to mail-enable and then mailbox-enable the AD objects. (A led" object has no Exchange mailbox, but contains a pointer to an

ddress, so mail can be routed to the external address. Mail-enabling is for external mail arriving via the Exchange server to be correctly k to the GroupWise addresses of users who have not yet migrated.)

S Migrator copies data from NDS to create security objects in AD, or ata to existing AD objects, but the AD objects are not mail-enabled by s. Quests AD Object Merge Tool then merges the GroupWise source

into the AD accounts to mail-enable them. And finally, Quests tor-Driven Batch Migrator mailbox-enables the accountseffectively e users mailboxes in Active Directory.

istrator-Driven Batch Migrator can also provision Public Distribution a straightforward process that occurs in a separate program run, first users are migrated.

Object Merge Tool can also be used to consolidate duplicate objects example, if migrating users already use Active Directory security network authentication, some provisioning tools may create ing Contacts in AD. In this case, the AD Object Merge Tool can (and used prior to migration to consolidate such duplicates, to merge the nd existing security objects into a single mail-enabled object per user. ject Merge Tool is explained in more detail in Appendix B of this Guide.


Method of Access to GroupWiseUser Data by Password or by Proxy

The Administrator-Driven Batch Migrator must have access to users' GroupWise accounts to migrate user data to the new Exchange environment. If you are mi-grating froNovells Tred applicauser passwearlier thaby passwo

The easiesto have thknown pasthis migrausers' pas

The prograeach user'file. Alternof charact

If resettingsupports bprogram caccount thaccount. Gautomates

Your MigraGroupWisepassword-method afcannot be administraexecute auonly upon occurrencesuccessfulthen revieoutstandin

Two other be migrateaccess.31

m GroupWise version 6.5 or higher, the migration program will use usted Application API feature to automatically register itself as a trust-tion, and will then be able to migrate GroupWise user data without ords or proxy authorization. But if the source GroupWise version is

n 6.5, the program will need to access users GroupWise data either rd or by proxy, as described below.

t way to provide access to GroupWise accounts (when necessary) is e program reset all migrating users' passwords, and then use the new sword values to login under each user's login identity. If you adopt tion-by-password method, the batch-migration program can reset swords before accessing their GroupWise accounts.

m can reset all users' passwords to a single common value, or can set s password to a value that was previously entered in the user-list .csv atively, you can set each user's password to a unique random string ers.

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

tion Plan should specify which method will be used to access user data. While Quest applications support both methods, the access method will almost always be more efficient. The proxy fects the timing and complexity of a migration project because users migrated until they have granted the appropriate proxy rights to the tor. Quest's Addproxy program automates this process and can tomatically from users network login scripts, but the utility will run each user's next login which may not be a daily or even weekly for some users. The Addproxy utility automatically logs the

procurement of proxy rights for each user, but the administrator must w the list of user proxies to determine whose proxy rights remain g, and then migrate those users separately at a later time.

disadvantages of the proxy-access method are that resources cannot d and mail-forwarding rules cannot be set or removed by proxy


32

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 accomp

Deskto

If user worbefore theupgrades.end users'access GroGroupWiseOutlook 20Outlook. N

Multi-W

The programigration options thsimple optbatches toall necessa

The tasks privileges Likewise, trequire difexample, amail-forwaGroupWisesetting upenvironmeaccordingl

Consider hdifferentlyoverall prolished by one of the alternate methods described above.

p Considerations

kstations will need Outlook installed or upgraded, you must determine first users are migrated how you will accomplish the installations or Remember that installing Outlook requires administrator privileges on machines. There is a MAPI service that permits the use of Outlook to upWise, but users in most organizations will be using the native client. For these sites, use either the deployment capabilities within 03 or a configuration management program to distribute and install ew profiles can be defined during or after the Outlook installation.

orkstation Considerations

ms of GroupWise Migrator for Exchange can be run on multiple workstations running in parallel. This approach opens several strategic at you should consider and document in your Migration Plan. One ion for the batch-migration program is simply to assign different user different migration workstations, and have each program run include ry admin and migration functions for the users in the batch.

performed by different Quest component programs require access for different servers: GroupWise vs. Exchange vs. Active Directory. he different functions available within the batch-migration program ferent access privileges, depending on the scope of their activities. For dmin access to Exchange and AD would not be necessary to set rding rules in GroupWise, but of course admin access rights in would be required for that function. You might therefore consider

multiple workstations with different access privileges to different nts, and then define tasks and assign them to various workstations y.

ow you might define and distribute various tasks to an array of configured migration workstations to maximize the efficiency of your cess, and then document your strategy in your Migration Plan.


Phased Migration Strategy

Some administrators opt for a phased-migration strategy, whereby users remain on the GroupWise server(s) throughout most of the transition period, while their oldest data (perhaps 90-95% or even more of the total) is migrated to the new Exchange proportionquickly, soshorter wiAdmin-Drimessages (or before

Some orgaGroupWiseusers will GroupWise

For some single-weebypass theyour total migrate thwhile all uusers withweekend.

If you adocreated totheir ExchAdministra

Fimaunse

Serethne33

environment. After the older data has been migrated, the ately smaller volumes of data remaining can be migrated relatively that larger numbers of users can be migrated together within a ndow. This phased-migration strategy is possible because Quests ven Batch Migrator lets you specify date limits and ranges for to be migratedto migrate only messages timestamped on or after ) a certain date, or within a particular range of dates.

nizations will need several days or weeks to move the older data to the target Exchange environment. But during this time all

continue to receive and send mail and manage their calendars in the environment.

organizations where the Migration Scale and Duration puts a kend migration just out of reach, a phased-migration approach can need for server coexistence and synchronizations. For example, if migration processing time is on the order of 50-100 hours, you might e oldest 80-90% of the data (40-90 hours) over two to four weekends sers remain in the GroupWise environment, and then migrate the the last 10-20% of their data (5-20 hours) all together in one final

pt this strategy, the Exchange accounts and mailboxes must be accept the migrated old data before the users actually start using ange mailboxes or calendars. You therefore must run the tor-Driven Batch Migrator twice for each user group:

rst Pass: to mailbox-enable user accounts on Exchange, set il-forwarding rules on Exchange (to forward mail back to GroupWise til the users migrate), and migrate users' older data to the new rver; and then ...

cond Pass: to migrate the remaining (newer) data to Exchange, verse the mail-forwarding rules (to forward mail from GroupWise to e new Exchange mailboxes), and migrate the users themselves to the w server.

Note: The date filters that you define for a phased migration like this are applied only to mail and calendar items, and not to users contacts. If contacts are selected for migration in the second pass of a phased migration, after they were already selected for migration in the first pass, the second pass will create an entire duplicate set of contacts in the Exchange environment. Quest therefore recommends that contacts be migrated only in the final cutover migration.


34

Users in this scenario will require continued access to their GroupWise mailboxes while the administrator migrates their older data, so they should keep their unique, secure passwords through the transition period. The program's access to GroupWise accounts should therefore be accomplished by some method other than by a common-value password. For an overview of the other methods, see the Method of Access topic above.

Strateg

When a reExchange,GroupWiseresources to Exchangwill interacthe potentway of knobeen reser

There is nomay want Plan shoulautomaticmigration Other opti

ies for Migrating Resources

source (conference room, AV equipment, and so forth) is migrated to the resource also remains on the GroupWise serverthat is, the original is copied, not destroyed or altered. After migration the two exist independently of each other, so users who have not yet migrated e will interact only with the GroupWise resource, while migrated users t only with the Exchange/AD resource. This coexistence introduces ial for "double-booking" resources, since users in Exchange have no wing whether the corresponding resources in GroupWise may have ved by not-yet-migrated users, and vice-versa.

easy or complete solution to this "double-booking" problem, but you to consider some options to mitigate its effects, and your Migration d identify this strategy. If your organization can live without the resource reservation and coordination features for the duration of the period, you may simply accept the temporary loss of these features. ons:

Defer the migration of all resources to the very end of the migration project, with (or after) the last users, and tell all migrated users that they may not request resources via Outlook until they are notified that the resources have been migrated to the Exchange environment. In the meantime, designate a not-yet-migrated user to serve as a Resource Coordinator in GroupWiseto manually relay resource requests from Exchange users to GroupWise resources, and manually relay resources replies back to the Exchange users.

If your resources are ordinarily allocated to certain groups of users (for example, a particular slide projector or a particular conference room is used only by users in a particular department, or on a particular floor), organize your user groups so that you migrate resources in the same groups with the users who use them. Or, if your resources are pooled to be available to larger groups of users, you could impose temporary limits on resource allocation as described abovedivvying up your resources among different user groups, for the duration of the transition periodto make possible a coordinated migration of users and their resources together.

Migrate all resources to Exchange at the beginning, with the first user group, and tell all not-yet-migrated users that they may no longer


request resources via GroupWise. In the meantime, designate an already-migrated user to serve as a Resource Coordinator in Exchangeto manually relay resource requests from GroupWise users to Exchange resources, and manually relay resources replies back to the GroupWise users.

Strateg

When a gr(that is, thmigration introduceslists, as grYou can reto update GroupWiseopposite d

Since the choose to transitionneed for pgroups denot-yet-macross themembers burden onat the outs

It is also coorganizatiorequire a mthroughou

Your Migrayour organ35

ies for Migrating Groups (Distribution Lists)

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

only practical update path for groups is one-way, most organizations defer provisioning their groups into AD until the very end of the after all users have been migrated. This approach eliminates the

eriodic updates, and already-migrated users can address emails to fined in GroupWise the same (transparent) way they send emails to igrated users. This approach also is likely to generate more traffic Microsoft Connector, which will increase as more and more group migrate to Exchange. Some admins may want to avoid that added the Connector, but the alternative is to provision the groups into AD et (or whenever), and then:

Run frequent synchronizing updates thereafter, throughout the transition period: Re-run the 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 the Connector.)

OR Accept inconsistencies between the GroupWise and AD groups.

nceivable, depending on how groups are managed within a particular n, that groups could be primarily maintained in AD, which would anual groups-updating procedure from AD back to GroupWise

t the transition period.

tion Plan should identify which of these strategies is best suited to izations needs and preferences.


36

Accommodating Known Limitations of theMigration Process and Other Special Circumstances

Review the Known Limitations of the Migration Process (in Appendix F of this Guide), and determine how you will accommodate any that apply to your organizatiomore elab

Identify anextensionsnot alreadoffer operaimplementgiven site non-stand

Migrati

GroupWiseyou want tperform a of GroupW

1. Es

2. Usdasu

3. De

4. Esco

5. MiEx

End Us

End user cmigration.migration users. The

n. Most or all may be insignificant to you, while some may require orate strategies or work-arounds to mitigate their effects.

y other aspects of the configuration that will require variations or to the typical migration process described in chapter 2, and that are

y discussed among these Strategic Planning Issues. Quest applications tional options that permit considerable flexibility in devising and ing a suitable migration strategy wherever the circumstances of a require a non-standard approach. For information and help with any ard scenarios, please contact your Quest sales representative.

ng from an Older Version of GroupWise

Migrator for Exchange supports GroupWise versions 5.5.3 to 7.0. If o migrate to Exchange from an earlier version of GroupWise, you must two-step migration with an intermediate server running a later version ise:

tablish a GroupWise server of a supported version on a new machine.

e Novell GroupWise upgrade tools to migrate your users and their ta from the original pre-5.5.3 GroupWise server to the new, pported-version GroupWise server.

commission the original pre-5.5.3 GroupWise server.

tablish a new Exchange server, either on a new machine or on the mputer that previously hosted the pre-5.5.3 GroupWise server.

grate from the new, supported-version GroupWise server to the new change server.

er Communications

ommunications is a critical but often neglected element of a smooth A user-communications plan should be a central component of your planning, to facilitate early and continuous communications with end end users will need to know:

When and how they will be migrated.How the migration will affect them.What tasks will be required of them to complete the migration.What their login credentials will be on the new Exchange server.How to use Outlook and Exchange (end-user training).


Your Migration Plan should therefore explain how and when you will deliver this information to your users. Many administrators compose a notification email to include this information, and send it to users prior to the migration. Some administrators also send another email to the new accounts as soon as they are migrated to the Exchange environment.

Test a

Any full-sctions, to coorganizatioa segregatproductionand real d

In either crepresentashould be process opor pilot useuser populthe procesprogram lowill help yViewer, fo

Quest rec

1. Pemiencoprrere

2. Wreussa37

nd Pilot Migrations

ale production migration should be preceded by test and pilot migra-nfirm that your Migration Plan and procedures will accommodate the n's requirements. A test migration uses real users and real data in ed test environment, or dummy users and dummy data in your live environment. A pilot migration uses a small portion of real users ata in the live production environment.

asea test or pilot migrationthe data to be migrated should be a tive sample of the production data, and the test or pilot migration run with the Quest applications set for the same configuration and tions that you intend to use for the production migration. Select test rs whose usage and data types make them representative of the total ation. Then run the migration for those users, just as you have defined s in your Migration Plan. When the migration is complete, review the g files for any errors or warnings. (Quest's Log File Viewer application

ou view and interpret the program log file. See Appendix B, Log File r more information.)

ommends that you use both test and pilot migrations:

rform one or more test migrations in a separate test environment, grating test copies of real users and their real data. The separate test vironment ensures that no test process will "touch" the data or nfigurations of your production environment. If a test exposes any oblems with your Migration Plan, you can amend the plan and then peat the test by simply "dumping" the test environment and creating it from scratch.

hen you are confident that your test migrations have sufficiently fined your Migration Plan, perform a pilot migration for 20 to 30 ers in your production environment to verify that your plan is tisfactory for your "real world."


38

MigInst

2ration Process ructions

Process Introduction

Necessary Pre-Migration Preparations

Batch Migration Process (Per User Group)

Migration Per Desktop

Post-Migration Clean-Up


40

Process IntroductionThis chapter provides instructions for how to accomplish the most common migration strategies and scenarios, using GroupWise Migrator for Exchange components in conjunction with Quests NDS Migrator, and Microsofts Connectorhave alreachapter 1

The task cused. WheExchange,operationa

The four rmigration

1.

2.

3.

4.

If your migany per-de

NecePrepThis sectioany type: or per-desbehalf of efirst user g

Since thesmigrationsmay simpl

The procesGroupWise and Outlook deployment tools. These instructions assume that you dy prepared a comprehensive written Migration Plan, as described in (see Pre-Migration Planning and Testing).

hecklists here explain the contexts in which the Quest applications are rever these procedures call for components of GroupWise Migrator for the scenario-oriented instructions here refer to tool-specific l details in chapters 3 and 4, and in the appendixes.

emaining sections of this chapter correspond to the phases of a process:

Necessary Pre-Migration Preparations

Batch Migration Process (Per User Group)

Migration Per Desktop

Post-Migration Clean-Up

ration strategy does not include either a batch-migration process or sktop migrations, just skip the unnecessary section.

ssary Pre-Migration arationsn explains how an administrator should prepare for a migration of administrator-driven batch migration, either by password or by proxy, ktop migrations either by end users or by administrators acting on nd users. These preparatory tasks are performed just once, before the roup or first single user is migrated.

e instructions cover a range of scenarios, not all steps will apply to all . These conditional steps are clearly identified here, and of course you y skip any steps that dont apply to you.

s begins with existing user accounts and mailboxes on a Novell server, version 5.5.3 to 7.0.

Migration Process Instructions

Step 1:Verify that All System Requirements Are Satisfied

All of the system requirements documented in chapter 1 (see About GroupWise Migrator for Exchange, System Requirements) must be satisfied before you begin this

Also, if yourun QuestGroupWiseinstruction

Step 2:Addpro

If you will establish pscript of ylogin. For

Step 3:Create

Create a teand specifenvironmeaccounts oExchange

Step 4:Recipie

Create a reusers will 41

process.

havent yet installed the GroupWise Migrator for Exchange software, s Setup program to install it now. If necessary, see Installing Migrator for Exchange in your Quick-Start Guide for complete s.

Prepare thexy Program to Establish User Proxies

use the proxy-access method: Prepare Quests Addproxy program to roxy access to each users account, and modify the network login

our migrating users to run the Addproxy program when they next complete instructions see Appendix A: AddProxy Utility.

a Temporary Subdomain for the Migration

mporary MX subdomain for the migration (e.g., migrate.domain.com) y it in DNS. The subdomain should direct traffic to the new Exchange nt. Mail from other GroupWise users arriving in the GroupWise f migrated users will be forwarded to the appropriate mailboxes in the environment using the migrate.domain.com subdomain.

Create ant Policy for the Temporary Subdomain

cipient policy to generate a secondary SMTP address so all Exchange be able to receive mail at the migrate.domain.com subdomain.

This step 2 applies only to administrator-driven batch migrations by proxy. If the program will access GroupWise source data by password, or as a Trusted App, skip ahead to step 3. If you arent sure, go back to chapter 1 and read the Pre-Migration Planning topic Method of Access to GroupWise User Data by Password or by Proxy.


42

Step 5:Provision Active Directory with NDS Users and Groups

Provision NDS users and groups as security objects and security groups, respectively, in Active Directory. Quests NDS Migrator (a separate Quest product, nmigration

In step 8 baccounts, Exporter h

Step 6:

The Directcreate theExporter nand complchapter 3:

Step 7:Review

Since the dare necessthe informmanually efiles may bdomain asthe Data Fediting the

Step 8:

Run QuestDirectory athroughou

The AD ObUsersToMelisted in thSourceAddaliases froContact, tosuch correot part of GroupWise Migrator for Exchange) offers the most complete capabilities for this task, but other methods are also possible.

elow you will run Quests AD Object Merge Tool to mail-enable these but the AD Object Merge Tool cannot be run until after the Directory as run.

Run Quest's Directory Exporter

ory Exporter extracts user data from the GroupWise environment to data files required by other Quest applications. Run the Directory ow, to generate the necessary data source files. For more information ete operating instructions for the Directory Exporter program, see Directory Exporter.

and Modify (If Necessary) the Data Files

ata files generated by the Directory Exporter (in the preceding step) ary input files for other Quest programs, it is important to verify that ation is properly formatted. This step also provides an opportunity to dit any addresses before initiating the migration. For example, the e modified to facilitate the organization's consolidation on a new SMTP part of the migration process. See Review and Modify (If Necessary) iles at the end of chapter 3 for more information about verifying and contents of these files.

Mail-Enable All Users AD Accounts

s AD Object Merge Tool to update and mail-enable the new Active ccounts, which will facilitate Exchange-to-GroupWise mail-routing

t the transition period for not-yet-migrated users.

ject Merge Tool will apply its functions to AD accounts identified in a rge.csv file that is specified during the program run. For each user e file, if an Exchange Contact address matches the GroupWise ress in UsersToMerge.csv, the program merges the GWISE and SMTP m the Contact into the AD security object, and then deletes the consolidate the pair into a single mail-enabled security object. If no sponding Contact exists, the program simply merges the


SourceAddress from UsersToMerge.csv into the AD security object, to mail-enable the object. See Appendix B, AD Object Merge Tool, for more information and operating instructions.

Step 9: Provision Public Distribution Lists in Exchange

Run the Addistributiodata file gprovision PseparatelyBatch Migrapplication

Step 10

Modify theWith the fomodificatiomail-enabaccounts amailboxesbefore init

Step 11

Use a text

[ARe

The Batchsynchronizfunction paddressesDirectory cRemoveSr

Step 12PABs to

The Adminand personthe sourcemigrate ar43

ministrator-Driven Batch Migrator to provision GroupWise public n lists (PDLs) as Exchange distribution groups. The program reads a enerated by the Directory Exporter, GroupsToProvision.abk, to DLs in Exchange. PDLs are typically provisioned in Exchange , before users are migrated in later runs of the same program, in ation Process (Per User Group) below. For operating instructions and notes, see chapter 4, Administrator-Driven Batch Migrator.

: Modify the MX Record

MX record to direct external (Internet) mail to the Exchange server. rwarding capabilities of GroupWise Migrator for Exchange, the DNS n actually can occur any time after the users AD accounts have been

ledbefore, during or after the actual migration. But since users AD re initially set to route mail back to the corresponding GroupWise , many organizations find it most appropriate to modify the DNS iating user migrations.

: Set RemoveSrcAddresses=1 in gwmigapp.ini

editor to open and edit your gwmigapp.ini file, to set:

ctiveDirectory]moveSrcAddresses=1

Migration Process (Per User Group) process includes a directory ation (via Microsofts Exchange Connector for GroupWise) that will

roperly only if the Quest program first removes all GroupWise source (gwise:proxy-Addresses), so that mailbox-enabled accounts in Active an be synchronized back to GroupWise as external users. If cAddresses=0 (default), only the gwise:uid- address is removed.

(If Necessary): Move Users Archives and a Centralized, Accessible Location

istrator-Driven Batch Migrator can migrate users GroupWise archives al address books (PABs) to Exchange, but only if the program can find archives and PABs on the GroupWise server. The program can also chives and PABs from diverse, per-user locations, but only if you


44

specify the location for each user in your user-list .csv file as explained in step 2 of the Batch Migration Process (Per User Group) procedure below.

If your GroupWise network is not already configured for your users archives and PABs to reside in centralized, accessible locations, and if you do not want to have to specify their diverse locations per user in the user-list .csv file, you (or your users) sho

Batch(Per Remembewith differMigration

This sectiomigration multiple gmigration by pass

Do not begPre-Migrat

Repeat the

Step 1:

Most migrseveral weorganizatioperiod. Anmay introdinconsisten

If maintaintransition and deleteadministraoccur afte

Otherwisetransition,since the luld move them now, before you run the Batch Migrator program.

Migration ProcessUser Group)

r that batch migrations and per-desktop migrations are performed ent Quest tools. For the per-desktop migration procedure, see the Per Desktop section of this chapter below.

n provides information and procedural instructions for a typical scenario, in which an administrator performs the migrations for roups of users with no user interaction. These instructions for batch scenarios describe the process for both methods of access to user data word or by proxy.

in this procedure until you have completed the Necessary ion Preparations listed in the preceding section of this chapter.

se steps for each group of users to be migrated:

Accommodate Any Recent Staff Changes

ation projects extend over a period of at least several days, many for eks or even months. It is entirely possible therefore that an n will experience staff additions and departures during the transition

y staff changes that occur while the migration project is in-process uce data inconsistencies between the old and new servers, but these cies can be reconciled during the migration process.

ing synchronization between the two directories during your period is not a high priority for your organization, you may simply add users in the Exchange environment (only), using Exchange tion software the same as you will for new hires and departures that r the migration is completed.

, if it is important to keep the two directories synchronized through the and if the organization has experienced any staff additions or changes ast run of the Directory Exporter:


Enter any such staff changes within the GroupWise environment as they occur, just as you always have.

If any already-migrated user leaves the organization: Delete the user from the Exchange server, using Exchange administration software.

Prior to the migration of each user group:

Step 2:

Quests Adthe subsetround. Howprogram wthe chapteData byto prepare

Preparin

If you will adapt the (optionally

To prepare

1.

2.

3.45

Run Microsofts Exchange Connector for GroupWise to re-synchronize the directories, from GroupWise to Exchange. (You need not perform this step explicitly if the Connector is scheduled to automatically re-synch the directories at regular intervals.)

Re-run Quest's Directory Exporter to generate new, updated .csv files that will accurately reflect the current staff list. (Remember to review the new .csv files and, if necessary, edit them, as explained in chapter 3 of this Guide).

Prepare a Migration Group User-List .csv File

ministrator-Driven Batch Migrator uses a .csv file as input to specify of users who will migrate together in the current migration batch or you should prepare your user-list .csv file depends on whether the ill access users GroupWise accounts by proxy, or by password (see r 1 Pre-Migration Planning topic Method of Access to GroupWise User Password or by Proxy). The next two subsections below explain how the user-list .csv file for both methods.

g a User-List .csv File for the Password-Access Method

access users GroupWise accounts by password, you can copy and user-list .csv file from the UsersToMigrate.csv that you created and ) edited in steps 6 and 7 of the Necessary Pre-Migration Preparations.

the user-list file, use Microsoft Excel to:

Open UsersToMigrate.csv and Save As to a new .csv-format filename (for example, migr01.csv for the first migration group, or migrmktg.csv for the users in the Marketing Department). You must save the file in .csv format, not as an Excel Workbook or any other file type.

Edit the copy by deleting all users except the ones you want to include in this migration group.

If you intend to access users GroupWise data by resetting their passwords to values in the .csv file (see the chapter 1 Pre-Migration Planning topic Method of Access to GroupWise User Data by Password or by Proxy): Add a Password column to the .csv file, and enter each users password value into this column.


46

4. See Other Modifications to the User-List .csv File below for a list of special circumstances and optional features that may require further modifications to the user-list .csv file.

5. Save the modified .csv file in CSV format under its new name, and exit Excel.

Preparin

If your AdGroupWiseAddproxy successfuldesignatedcurrent listhereby elformat theBatch Migr

Be sure tospecial circmodificatio

Quests Adinput file, in migratioprepped toout and baAny users run Addpr

Provisio

Some admto two or mprogram cdestinationused for th

The Homemigrating Administra

CN=MaiCN=MOBGroupsDC=Exag a User-List .csv File for the Proxy-Access Method

ministrator-Driven Batch Migrator program will access users data by proxy, you can use the .csv file generated by Quests program as your user-list file. Appendix A explains how each run of the program, per user, generates a record of the user in a file, in your addproxy.ini file as the SuccessLog. This file thus contains a

t of all users who have granted the necessary proxy rights, and are igible for migration by proxy. The Addproxy program is designed to log as a .csv file that can be read by Quests Administrator-Driven ator.

see Other Modifications to the User-List .csv File below for a list of umstances and optional features that may require further ns to the user-list .csv file.

ministrator-Driven Batch Migrator will prompt you for a user-list .csv and you may simply specify the Addproxy log file for this purpose. But n-by-proxy you must also determine which (if any) users were run Addproxy but never ran it that is, users who have not logged ck in again since the Addproxy line was added to their login scripts. who do not appear in the log file even though they were prepped to oxy will have to be migrated separately at a later time.

ning Users to Multiple Exchange Mailstores

inistrators may want to provision users in the same user-list .csv file ore different Exchange mailstores. The Admin-Driven Batch Migrator

an do that, but in this case will need to know the users individual mailstores. The HomeMDB column of the user-list .csv file can be at purpose.

MDB column specifies the home mailbox store in Exchange for each user, and is used when mailbox-enabling users in the Exchange tive Operations of the Admin-Driven Batch Migrator. Example:

lbox Store (M

GMEUserGuide

Documents

Transcript of GMEUserGuide