GroupWise to Exchange 2007
Written by David Noel-Davies   
Lets explore the task of migrating from Novell GroupWise to Microsoft Exchange 2007 (because companies still have it out there!). We will cover all areas of the migration including the most critical of phases, planning and preparation. Time spent here will save you many days later on in the project. We will show exactly how to create connectivity between the two systems and will discuss some of the common pitfalls of interoperability. Finally, we will cover the actual migration, showing the use of both native and 3rd party tools, namely the Quest GroupWise Migrator for Exchange. The intention is to write the definitive article on GroupWise to Exchange migration. We will make use of & refer to existing material, which will be corrected and or updated where appropriate. The series will walk any prospective migration consultant through both the theory and practice highlighting specific pointers and tips where we can help, and gotchas that you must watch out for.

Planning

Any migration project consists of three key phases as shown in Figure 1.


Figure 1:
The keysphases of a migration project plan

  • The Discovery phase consists of an assessment of existing infrastructure, and an investigation to gain an understanding of pain points, challenges and objectives.
  • The Solution Design phase is where you put together an optimal solution that addresses the challenges, mitigates the pain points, and achieves all of the objectives.
  • Once we have a clear understanding of the current state of play, and a view of the optimal solution, a Migration Plan can be outlined to migrate from the where you currently are, to where you want to go.

Overall, what we want to emphasize in this section is that without thorough planning and testing, it is highly unlikely your migration will be as smooth as it could be. Therefore, whilst detailed project planning is beyond the remit of this article, it is worth highlighting both some common issues that are encountered when planning a project and some areas which you should consider:

  • Phases
    Allow plenty of time in between your phases. A common fault is to put together a project plan where the phases are back-to-back. Leave time in between your phases to allow for over-run and unforeseen problems.
  • Resources and Scheduling
    Determine a core migration team. It sounds obvious, but put your team member holidays and public holidays into your plan. Having broken down your plan into high level tasks and durations, you can see where the resource shortfalls are and plan accordingly.
  • Monitoring and Reviewing
    There is little point producing a plan if it is not then monitored and updated. The plan is there to help and guide you through your migration. Make sure you update it regularly with progress, so that you are able to plan ahead to keep your project on track.
  • Proof of Concept
    It is essential to thoroughly test both your design for the new Exchange system AND your migration plan for how to get there. Very often people work out their Exchange implementation and then simply dive into the migration. This will not lead to the best outcome!
  • Training
    When working with such a fundamental change in technology, it is critical to train not only your administrators but also your users. Whilst the concept of email is the same to both systems the way the User Interface differs is enough to cause significant loss of productivity especially amongst the most active users.
  • Decommissioning existing systems
    At this phase your project is almost over, however it is important to consider exactly how to remove the old systems and to ensure that any data protection requirements are adequately followed.

What is involved in Migrating to Exchange

With a GroupWise to Exchange migration, what we have, and what we want, are both largely defined. We are simply left with choosing the best migration plan.

We will focus on the specifics of GroupWise to Exchange 2007 migration later in this article and this series, but let us start from a technology independent perspective. In order to migrate to Microsoft Exchange you will need to accomplish three things. These steps are irrespective of the source or legacy system and are shown in Figure 2.


Figure 2:
Key Stages of the Migration

  • Create objects in Active Directory. Unlike Exchange 5.5 all versions of Exchange since Exchange 2000 are integrated with Active Directory. What this means is that before you can grant somebody an Exchange mailbox, you have to provide them with a user account.

    In our scenario we are going to use the Connector for GroupWise to provision our Active Directory objects. Options available on the Import Tab of the Microsoft Connector for GroupWise deal with which action to take when a GroupWise directory object is not found in Active Directory. We will be choosing to create a new user object.

    We will cover Active Directory object provisioning in the second article.

  • Integrate the two mail systems. With the exception of what we refer to as a big-bang migration, (where you migrate all of your mailboxes and resources in one go over a very short timeframe) you will need to consider co-existence and integration. During a period of co-existence, two disparate mail systems must look and feel like a single cohesive system.

    You need to give consideration to:
    - Directory integration and synchronization for internal address resolution
    - SMTP mail flow and routing
    - Calendar free/busy and schedule information

  • Migrate data. Most people presume that there will be a requirement to migrate everything, and this is the worst case scenario to plan for, but give it some consideration. A migration of the last three to six months mail, or even possibly a clean Exchange mailbox may suffice.

Migrating from GroupWise, the Challenges

Let us take a look at what we are going to face in our migration from GroupWise to Exchange.

Exchange 2007 migration options

A migration from Novell GroupWise to Exchange 2007 is complicated by the design decisions that Microsoft took when building Exchange 2007. Previous versions of Exchange came with tools to enable migration from GroupWise. The tools provided by Exchange 2003 to enable co-existence with, and migration for GroupWise are as follows:

  • Connector for Novell GroupWise
    This tool provides the ability to route mail to the GroupWise system and for Exchange to understand the GroupWise address space. Once configured it also enables the two directories to be synchronised to ensure that there is a consistent address book across both systems.
  • Calendar Connector
    This tool enables users from both systems to see each others’ scheduling information.
  • Migration Wizard
    Includes an option to Migrate from Novell GroupWise… In this series we will also look at the Quest migration tools.

With Exchange 2007 these connectors are no longer provided which means that to provide ongoing integration and co-existence with GroupWise you must also implement Exchange 2003.

You cannot install an Exchange 2003 server into an existing Exchange 2007 organization, so if co-existence and integration are required during a phased migration, you MUST install Exchange 2003 into the organization first.

Figure 3 gives a high level view of how the two systems are integrated and communicate via the Connector for GroupWise and Calendar Connectors.


Figure 3:
GroupWise and Exchange co-existence and integration

User experience and expectations

Possibly less obvious but equally as important, a GroupWise client on a GroupWise system will offer different features and user experiences to an Outlook client on an Exchange system.

  • There may not always be a one-to-one parallel with the way things used to be done in the new client.
  • There may not be a one to one conversion for certain client features, or formatting.

Which leads nicely to the next consideration.

Selecting a migration technology

It is worth taking a look at the migrations options. The two options we will focus on in this series of articles are the native Exchange 2003 Migration Wizard and the Quest GroupWise migrator for Exchange. Both tools provide most of the same features at a basic level. The third party (Quest) tool provides more advanced functionality than the native migration wizard in regard to migration of certain GroupWise features, such as proxy access, shared folder permissions and importantly, local GroupWise Archives.

A very high level comparison of what can be migrated with each tool is provided in Table 1.

If you find that the additional migration options available in the Quest tools are of no benefit, you may find the native Migration Wizard more than adequate.

 

Can be migrated with

Quest

Migration Wizard

Inbox

Yes

Yes

Email

Yes

Yes

Folders and subfolders

Yes

Yes

Attachments

Yes

Yes

Calendars

Yes

Yes

Tasks

Yes

Yes

Address books and contacts

Yes

No

Proxy access

Yes

No

Shared folder permissions

Yes

No

Archives

Yes

No

GroupWise Distribution Lists and membership

Yes

No

Rules

No

No

Table 1: Migration Tool Comparison

Realistically, your requirements as defined during project scoping and assessment will tend to strongly favor one or other migration tool. For example, if you need to migrate local GroupWise archives to Exchange, and you do not have the disk space, bandwidth or time to copy local content back into GroupWise ready for migration, the only choice you have is to go with Quest!

Let’s Outline our Migration Scenario

In order to give a realistic migration scenario, our company is in the process of migrating from a Novell network to a Microsoft network. An Active Directory does exist, but AD design and configuration is outside the scope of these articles. There are no user objects in Active Directory.

All users have accounts in eDirectory and the clients being used are all Windows XP SP2 with the Novell client.

The GroupWise system is currently running version 7, although the principles of migration, if not the client versions, would remain the same for earlier versions.

We are doing everything in a virtual server farm using VMware Server which is on version 1.0.4 as of this writing.

Our server infrastructure will grow as we progress through this series of articles. As it currently stands we have;

  • A GroupWise 7 server running on Netware 6 called NWGW1
  • An Active Directory Domain Controller called ADADMIN
  • An NDS admin workstation running Console One and NWADMIN called NDSADMIN
  • An Exchange 2003 server called EXCHANGE2003

In later articles we will add Exchange 2007 servers, and Quest migration workstations into the infrastructure.

Our GroupWise server is running both the API gateway and our live Post Office. We have done this for several reasons, it serves our purpose and it allows us to demonstrate the key steps and technologies used in migrating away from GroupWise, but we appreciate that GroupWise best practice is to run the API gateway on a separate Post Office in a separate secondary Domain.

We have started with the four machines above for simplicity. Remember, you cannot add an Exchange 2003 server to an existing Exchange 2007 organization, and you should have spotted this in the planning stage. In order to migrate to Exchange 2007 and co-exist with GroupWise during the process, you need to get Exchange 2003 in first. You may already have Exchange 2007 in place, but so long as you also have your Exchange 2003 in place, that is fine.

Our Exchange 2003 server is running Exchange 2003 SP2 on Windows Server 2003 R2 also SP2. We have a clean install, with no connectors, no Mailbox enabled AD objects and no additional AD user objects other than Administrator.

We have a small OU structure in NDS that consists of five departments. We have 12 user objects, three groups, one GroupWise resource and two GroupWise external entities. We will worry about these GroupWise objects and how they are migrated to Exchange in a later article.

For now we are going to get these two systems talking to each other.

Installing the Exchange Connectors

Although there are situations where more than one connector may be required, for example where you need to synchronize with more than one GroupWise system, or where you wish to distribute the workload which you can do by pointing multiple Connector instances at the same API gateway or at separate gateways possibly in separate GroupWise domains, you can only run one instance of the Novell Connector for GroupWise per Exchange 2003 server. In a small to medium sized migration to Exchange 2007 this is likely all you need. One Exchange Server talks to one GroupWise server and the replication mechanisms of each system do the rest.

Start with the Exchange 2003 CD in the drive.

Skip the ExDeploy, and run the setup.exe directly from the \SETUP\i386 subdirectory.

On the Welcome to the Microsoft Exchange Installation Wizard page, press Next>.

For the Microsoft Exchange component and the Microsoft Exchange Messaging and Collaboration Services component change the action from ü to Change as shown in Figure 1.

For the Microsoft Exchange Connector for Novell GroupWise and the Microsoft Exchange Calendar Connector components select Install, again shown in Figure 1.


Figure 1: Modifying the Exchange install to install connectors

Press Next>.

These files do not take much space, about 8Mb. We are essentially creating a file and folder structure with the Exchsrvr\Conndata directory.

You will need to re-apply Exchange 2003 SP2 after the connectors have been installed as shown in Figure 2. There were some updates to the GroupWise connector in SP2.


Figure 2: Exchange setup warns you to re-install SP2

If the re-installation of SP2 gives you a warning about the IMF as shown in Figure 3, open Regedt32 and look for the following key:

HKLM\Software\Microsoft\Exchange\ContentFilterVersion


Figure 3: The IMF warning which prevents update

Change the value to 1 as shown in Figure 4, exit the SP installation and try again.


Figure 4: Setting the IMF Version value to 1

So let us look at what we have. In ESM we now have two connectors, one for Novell GroupWise and one for the calendar which you can see in Figure 5.


Figure 5: The newly installed connectors

Before these will actually talk to anything, we need to install the Novell client onto the Exchange server. We need to do this for the following reason; the way the connector actually works is that it simply places text files into a specific directory structure on the Netware server that is running GroupWise. Gateway Services for NetWare GSNW is not available for Windows Server 2003. To access the directory structure, we need the Novell client.

At the time of writing the most up to date version of the client for Windows Server 2003 is 4.91 SP4. You can download it from http://download.novell.com. It is a 21.5MB download.

Once you have created a login (free) and downloaded the install file, unzip it and run SETUPNW.EXE.

Select Typical Installation and click Install> as shown in Figure 6. Then opt to Reboot.


Figure 6:
Installing the Novell Client

We are not actually going to install the GroupWise client on the Exchange server at this point. If we decide to use the native Exchange Server Migration Wizard we will need to. The migration is client side driven, and each GroupWise mailbox is opened using the GroupWise client.

The Quest utilities that we will cover in a later article are also client side driven, but we typically run these on a dedicated migration workstation, with everything we need such as the AD AdminPak, GroupWise and Outlook clients installed.

So, the Exchange Server now has all the prerequisites in place, they just need to be set up. We will come back to this in a moment.

Installing the GroupWise API

The GroupWise API is a generic API that allows GroupWise to talk to any third party e-mail system. It is not specific to Exchange. Novell do make a specific connector for Exchange, but you can only run this on a Windows platform, and if GroupWise is not running on Windows then we are left with the good old fashioned API.

Patch 2 for the 4.1 API was written in 1999, and Patch 5 was last updated in December 2001. The Microsoft Connector for Novell GroupWise was last updated on October 2005 when Exchange 2003 SP2 came out so as you can see we are not dealing with the latest technology here!

Download the Novell API from http://download.novell.com. Also, get a copy of the most recent patch, simply search for gw41api2.exe and fgwapi5.exe.

Extract the files from the gw41api2.exe to a floppy disk, and insert it in the floppy drive on the GroupWise server.

On the keyboard, press CTRL+ESC, and from the list of Current Screens shown in Figure 7, select the System Console.


Figure 7: The Netware Current Screens selection page

Type NWCONFIG and press return. We are looking for the option to Install a product not listed shown in Figure 9, which is under the Product Options you can see in Figure 8.


Figure 8:
The Netware Configuration Options screen


Figure 9: The Netware Other Installation Actions screen

Press <Enter> to continue when prompted that the Product will be installed from A:\.

Now this next screen, the API Gateway Installation shown in Figure 10, is pretty important and for most Windows/Microsoft consultants, it takes a bit of careful deciphering.


Figure 10: The API Gateway Installation screen

The GroupWise Domain Path follows the Novell Volume format which is not intuitive to us Windows folk. The Domain Path is essentially a path to the WPDOMAIN.DB file. The domain path uses the following format:

Volume:Path_to_groupwise_domain

There may be more than one WPDOMAIN.DB, as it is possible for multiple domains to exist on a single GroupWise server, but chances are with a separate GroupWise server that has been set up in a secondary domain to run the API Gateway there will only be one.


Figure 11: ConsoleOne showning the WPDOMAIN.DB file

You can find the WPDOMAIN.DB file from within ConsoleOne as shown in Figure 11. This typically gives you a good indication of what the volume and path should be. You can also use the Tools, GroupWise System Operations, Select Domain… option from within ConsoleOne to verify the domain path.


Figure 12: Showing the GroupWise Domain Path

In my case, because I am using an admin workstation to run ConsoleOne the domain path is displayed in terms of a Universal Naming Convention starting with \\ which you can see in Figure 12.

Since I am installing the API on the Post Office itself, all I need are the volume and path, so in my case it is data\dom1. The format required by the API installation includes an “:”, so it is data:\dom1. Once you have the GroupWise domain path, the Gateway NLMs path may update itself, after which you should press Install…

Once the install has completed, press ESC twice, then Enter to confirm you wish to exit NWCONFIG.

Next we need to do a file replacement in order to upgrade the API to Patch 5.

When you unzip fgwapi5.exe there is a notepad document called fgwapi5.txt that walks you through this, but essentially we are replacing the NGWAPI.FIL and the NGWAPI.NLM files in the wpgate\api directory under the GroupWise domain path, so in my case this is dom1\wpgate\api.

You can browse to the directory using Windows explorer, and simply swap the files.

While we are in the api directory, open the NGWAPI.PRM file shown in Figure 13, and locate the line that reads: Gateway does inbound group expansion. Remove the ; from ;/group on the following line to enable group expansion. While the NGWAPI.PRM file is open, look for the line that reads ; Path to the gateway’s root directory. This line should contain a reference to the GroupWise domain path from earlier. In my case it reads /Home-data:\dom1\wpgate\api


Figure 13: The NGWAPI.PRM file showing the areas requiring change

Save the file and close it.

Summary

At this stage you have finished the install process of the connectivity pieces used to get Exchange and GroupWise talking. In the next article we will show you how to configure them to get things actually working!