Quest GroupWise Migrator for ExchangeComments (0)

This post will cover the steps involved in migrating from GroupWise to Exchange Server using Quest’s GroupWise Migrator for Exchange. In this case we have already a IDM sync in place and all Novell accounts have been migrated over to Active Directory user objects.

The product which just reached version 4.2 supports the following target platforms:
- Exchange 2007
- Exchange 2010
- Exchange 2013
- Office 365
- Hosted Exchange


Migration PC Requirements
- One or more workstations that will act as a migration server with recommended specs like 3+ Ghz processor, 2 GB memory and 1 Gbps NIC.
- We recommend running the workstations on physical hardware and with Windows Server 2003 R2 x86 OS.
- Novell NetWare or ConsoleOne
- Novell client for NetWare (version 4.7 or higher, 4.91 SP2 recommended)
- Groupwise Client 6.0-7.0 or 8.0.0-8.0.3 or GroupWise 2012

The account, I always use GWMigrate must have the correct permissions to create objects within an OU as well as Receive-As permissions so objects can be written to the target mailbox.

To add the permissions for this:
Add-RoleGroupMember ‘Organization Management’ -Member GWMigrate

To add the Receive-As permission:
Get-MailboxDatabase | Add-ADPermissions -User GWMigrate -ExtendedRights Receive-As

Throttling Policy
Quest recommends that we change the throttlingpolicy for the user GWMigrate.

To create a throttling policy:
New-TrottlingPolicy QuestMigration

To configure the policy:
Set-TrottlingPolicy QuestMigration -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeinMailboxRPC $null

To apply the policy on the migrationaccount:
Set-Mailbox GWMigrate -ThrottlingPolicy QuestMigration

Preparing the Migration PC
The following software must be installed in the correct order:
1) Windows Messaging subsystem
2) GroupWise Client
3) Outlook Client
4) Microsoft PowerShell
5) ConsoleOne
6) Quest GroupWise Migrator for Exchange

Migration steps

After we have prepared the Migration PC’s we will use various tools to accomplish this migration.

Directory Exporter
This is the first tool we will use to export all objects from Groupwise into several .csv files.
If we look at the file called UsersToMigrate.csv which will be the original file; this is the file from which we will create or batches.

If the file contains 10.00 objects we will definitely cut them into small batches. If we take the top 20 lines and save the file as Batch01.csv (remember to always have the top line in all bachfiles for the specific attribute).

AD Object Merge Tool
The next step is to pair the GroupWise accounts with the corresponding Active Directory account. By starting this application and choosing Batch01.csv we can pair the accounts and change the accounts from regular user accounts to mail-enabled accounts.

Administrator Driven Batch Migrator
This is where all the magic happens. From this tool we can:
- Enable/disable forwarding in both GroupWise and Exchange
- Set new passwords on the accounts
- Mailbox-enable the accounts
- Provision Distribution Groups
- Migrate the objects with lots of options like choosing which object to migrate (we might not want to migrate the trash), we can choose between which dates we will migrate objects, we can choose whether we will migrate into the user mailbox or directly to an Online Archive and much more...

We will also use the Batch01.csv file here to choose which users to handle.

Tips & Tricks

- Try to use several migration workstations and on each workstation run batches with small amount of users in it. This will help you remain in control and it’s easier to troubleshoot.
- Try to use physical migration workstations.
- If running multiple Exchange CAS Servers, distribute the load. Do not choose destination path towards the hardware load balancer if running any. Instead each workstation should point towards separate CAS servers to provide better performance. (This is done within the Wizard).
- Always do a pilot run with accounts that are to be migrated. Each account is a license, so testing on a bunch of test accounts is not a good idea. Try to remove the test accounts in an early stage or remove them from the batchfiles.
- If migrating a huge amount of data, do this a two step migration. First step is to migrate all data older than a specific data lets say 30 days back in time. etc May 31. And the second step is to migrate all data after June 1, and make the switch for both clients and inbound and outbound traffic.


You need sign in to comment! Sign up today!