GroupWise to Exchange 2007 – Interoperability and Migration (Part 8)

By /

If you would like to read the other parts in this article series please go to:

 

 

 

About co-author Declan Conroy

 

Declan Conroy is an IT consultant specializing primarily in Microsoft technologies including Exchange and Active Directory. Having previously worked for companies like Hewlett Packard and Compaq both as internal IT support, middle management and as a Professional Services consultant, Declan founded Cheddon Consulting Limited in April 2005. Since then Cheddon Consulting have migrated over 150,000 mailboxes to Exchange Server.

 

You can contact Declan here, or through his blog.

 

Well we keep saying we’ve nearly finished! However, having written this “last part” it turns out we have two more parts. So what will we cover? Well in the final two parts we’ll walk thru the use of the Quest GroupWise Migrator for Exchange. It is not our intention to reproduce the Quest user documentation which is already extensive. We’re hoping to give you a look under the hood at what the tool does, why, and how to get the best out of it. This article covers the background to the Quest tools and then gets you half way through the migration. The final part finishes off the migration!

 

Migration Workstation or Server, XP or 2003

 

Before we dive into the migration we need to discuss what to run the migration tools on. In particular, we have received some feedback about using XP on our migration workstation.

 

We have used XP on the migration workstation for two reasons. We are in a VM lab so we have simply used the XP Virtual PC that we have been testing Outlook and GroupWise on. Secondly it does not require server OS or server hardware, which for most people is a bonus.

 

If you do want to use Windows Server 2003 Server the prerequisites are the same but the download locations are different as some components such as DOT.NET have OS specific versions.

 

 

 

When you re-apply SP2, AdminPak will be updated.

 

Before we start

 

We have tried to cover the important steps, in the correct order, and give pointers and tips where we have had real world experience. If you do get stuck, please do feel free to contact either of us, although we cannot guarantee we will get back to you fast enough if you are on site and on the clock!

 

We have made some assumptions.

 

 

  • We have assumed the source GroupWise and target Exchange systems are fit for purpose. We fully appreciate that in the real world this may not always be the case, but there are simply too many possible issues or reasons why the migration could fail for us to go into them all here.

     

  • We have also assumed you have followed the previous seven articles, and that you have provisioned your Active Directory user objects using the MS Exchange Connector for Novell GroupWise.

 

There are many different ways you can provision user objects in AD but the two most common in an NDS to AD migration scenario are the MSDSS or the NDS to AD migration software from Quest. The significance of using the MS Exchange Connector is simply that it creates AD user objects based on the GroupWise directory and not on NDS.

 

Remember, GroupWise maintains its own directory separate from NDS. This is very much like Exchange 5.5 on NT 4.0. If you provision your AD objects based on NDS, there is a stage in the migration process, where GroupWise objects and AD object (formerly NDS objects) are merged together to create a single set of target objects.

 

This merge can create issues. Image a very common scenario, where NDS and GW objects are created for Karen Smith, who then becomes Karen Jones after she gets married. Very often, the GroupWise object is updated, because the e-mail address is visible. The NDS object may or may not be updated, and as a result these objects will not merge.

 

We have seen similar issues where GroupWise objects are miss-spelt, or where hyphenated names or other common names are handled differently between NDS and GW.

 

The objects that fail to merge are logged by the AD Object Merge utility, and you often have a certain amount of data cleansing to do.

 

Because we have provisioned our AD object directly from the GroupWise directory this step is much simpler.

 

The Quest Software Suite

 

There is a suite of products and tools wrapped up in the Quest software:

 

 

  • The Directory Exporter

     

  • The Active Directory Object Merge Tool

     

  • The Administrator Driven Batch Migrator

     

  • The Self-Service Desktop Migrator

     

  • The Quest Log File Viewer

 

Each of these tools does a specific step in the migration, and some of them do more than one.

 

Everything starts with the Directory Exporter. This utility needs to be run first

 

When you run the Directory Exporter, it prompts you for a GroupWise mailbox and password, as well as the TCP/IP address or hostname of the Post Office running the GWIA, and finally the Domain path as shown in Figure 1:

 

Note: You must have a GWIA in the GroupWise Domain or the Quest software will not work properly

 


Figure 1: Entering GroupWise information in the Directory Exporter

 

The Directory Exporter then connects to GroupWise and extracts the Address Book as shown in Figure 2.

 


Figure 2: Directory Exporter connecting to GroupWise to read Address book info

 

The stages of a migration are displayed in Figure 3.

 

 

Figure 3: The Migration Steps

 

  

First, the directory exporter logs into GroupWise and extracts a post office specific view of the GroupWise directory. Each object in GroupWise can be set one of four different levels of visibility:

 

  • None
  • Domain
  • System
  • Post Office

 

The Directory Exporter will extract a list of all GroupWise objects with visibility of System.

 

The implication here is that is there are specific mailboxes or objects that have visibility of Post Office these may not be extracted unless you use a mailbox on the same post office.

 

The safest method to ensure you capture all GroupWise objects is actually to use a mailbox on each Post Office in the system, combine all of the resultant directory exports into a single file, and remove any duplicates.

 

As tedious as this step is, it’s crucial. This is largely a numbers game.

 

We need to understand how many objects we start with, how many have migrated, and why any failed. We need to be able to explain the numbers.

 

The Quest Directory Exporter creates four files that are used as input files by the other utilities in the suite.

 

These files are listed in table 1.

 

 

 

Filename

  

Location
 

UsersToMigrate.csv

  

C:\Program Files\Quest Software\GroupWise Migrator for Exchange
 

UsersToMerge.csv

  

C:\Program Files\Quest Software\GroupWise Migrator for Exchange
 

GroupsToProvision.abk

  

C:\Program Files\Quest Software\GroupWise Migrator for Exchange
 

AddressTranslation.csv

  

C:\Program Files\Quest Software\GroupWise Migrator for Exchange\Shared

 

Table 1: The four output files from the Directory Exporter

 

These four files are the master set of files. The best advice I can give is to copy them to a safe location. There is a lot of manipulation of the content of these files, and a backup copy will prove very handy, trust me.

 

During the migration you typically work with a subset of the data from the directory export as you run the migration in batches. For each batch, either remove users that are excluded from the migration from the file, or work with a completely separate set of migration files for each batch.

 

Three of four files are almost identical.

 

 

  • UsersToMigrate.csv

     

  • UsersToMerge.csv

     

  • AddressTranslation.csv

 

UsersToMigrate.csv has an additional column header in column L, SearchKey but with this exception the files and the content are exactly the same.

 

The content of these three files allows you to merge, migrate and perform admin functions on the same subset of mailboxes for each phase of migration.

 

The trick with manipulating these files is to always work with a copy of UsersToMigrate.csv, and then save it twice more as UsersToMerge.csv and AddressTranslation.csv.

 

If you are using a separate set of migration files, call them something obvious like Phase-1-Migrate, Phase-1-Merge and Phase-1-Translate.csv

 

AD Object Merge

 

Once we have a full directory export we need to do an AD object Merge. This ensures that any AD user objects are correctly associated with the corresponding GroupWise mailboxes, and is necessary largely because as we indicated earlier, the most frequent source of AD objects is NDS and not GroupWise.

 

Have a look in the UsersToMerge.csv file.

 

There are two fields of interest, ObjType and NDSUsername.

 

ObjType lists different values where 0 corresponds to a user or an external entity, 2 is a distribution group and 3 is a GroupWise resource. These are the three most common object types in the directory export.

 

Note that for each object type of 2 or 3 there is no NDSUsername value.

 

The contents of the NDSUsername attribute is matched with the User logon name (pre-Windows 2000):  field on the user Account tab in Active Directory as shown in Figure 4.

 


Figure 4: The Pre-Windows 2000 logon field

 

The directory export may also contain objects synchronized over the connector from Exchange, and while these will have an ObjType of 0 they don’t have an NDSUsername value either.

 

My directory export contains 21 objects.

 

 

  • 11 users

     

  • 6 distribution groups

     

  • 2 resource mailboxes

     

  • 1 external entity

     

  • 1 Exchange user.

 

When I run the Active Directory Object Merge Tool, after I give it the source file containing my list of objects to merge, I have three choices for how to find users in Active Directory shown in Figure 5.

 

 

  • Find object by Pre-Win2K user name

     

  • Find users from the Quest NDS Migrator database

     

  • Find object by attribute.

 


Figure 5: Choices of how to find users in Active Directory

 

If I simply perform an AD object Merge using the default of pre-Win2K user name, any object without a populated NDSUsername attribute will fail to merge.

 

Once I understand that all ObjType 2 and 3’s and one of my ObjType 0’s (the exchange user) will fail, the numbers add up, and I get 11 success and 10 failures out of 21 objects as shown in Figure 6.

 


Figure 6: The results pane of the Merge Tool

 

If I check the contents of the Merge Report I can see that all of the users with an NDSUsername attribute have merged but pretty much everything else has failed.

 

 

  • My exchange user has failed, but this is not a problem.

     

  • My distribution groups have failed, but again, understandable.

     

  • My resource mailboxes have failed, as has my external entity and these however, are a problem.

 

The numbers here MUST add up. If they don’t you have to stop and figure out why. In the early stages of a project, numbers can seem like a lot of hassle, but there will come an inevitable day towards the end when there will be a reckoning, if you don’t understand the numbers all the way thru, stop until you do.

 

I have two basic choices here. I can live with the numbers once they add up and I understand them, or I can massage the data in the .csv files to give me a clean result.

 

For example, if I delete the distribution groups and the exchange user from my UsersToMerge.csv file, I’m left with 14 objects.

 

 

  • 11 users,

     

  • 2 resource mailboxes

     

  • 1 external entity

 

Next, the simplest solution is to populate the NDSUsername field for these objects using the values taken from the AD objects I’m trying to merge with, which is also typically the Userid field as shown in Figure 7.

 


Figure 7: Populating the NDSUsername field

 

I need to note however that my User login names don’t contain spaces, where my GroupWise mailboxes do, for example Board Room in GroupWise has become BoardRoom in Active Directory so I need to remove the spaces and then this time around I get a clean bill of health from my AD object merge as shown in Figure 8.

 


Figure 8: The clean AD object merge

 

Summary

 

At this point we have discussed options for the migration workstation, introduced you to the Quest suite and completed the first two phases of migration using the Quest tools. In the next (and very likely last) article we will complete the process starting with the Provisioning of Distribution Groups.

 

If you would like to read the other parts in this article series please go to:

 

 

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top