GroupWise to Exchange 2007 - Interoperability and transformation (Part 8)

GroupWise to Exchange 2007 - Interoperability and transition (Part 1)

GroupWise to Exchange 2007 - Interoperability and transition (Part 2)

GroupWise to Exchange 2007 - Interoperability and transition (Part 3)

GroupWise to Exchange 2007 - Interoperability and transformation (Part 4)

GroupWise to Exchange 2007 - Interoperability and transformation (Part 5)

GroupWise to Exchange 2007 - Interoperability and transformation (Part 6)

GroupWise to Exchange 2007 - Interoperability and transformation (Part 7)

Nathan Winters

Migrate workstations or servers, XP or 2003

Before diving into the migration process, we need to introduce a little about what to run migration tools.

We used XP on the migration workstation for two reasons. The first reason is in a VM lab, we used an XP-based virtual computer to test Outlook and GroupWise on it. Secondly, it does not require server or server hardware.

If you want to use Windows Server 2003 Server, the prerequisites are similar, but the download locations may be slightly different in some components, such as DOT.NET with separate operating system versions.

1. Download and install x86 DOT.NET Framework 2.0 Service Pack 1.
2. Download Windows PowerShell for Windows Server 2003.
3. If you need it, download MMC 3.0 for Windows Server 2003 here. MMC 3.0 is included in SP2.
4. You can download Windows Server 2003 SP2 AdminPak here.
5. The Windows Server 2003 SP2 AdminPak may prompt you for SP2 CD during the installation process. Perhaps like us, you downloaded SP2 via Windows Update, the simplest solution to this problem is to "downgrade" back to SP1, and install SP1 AdminPak from here.

When you re-use SP2, AdminPak will be upgraded.

Before start

We will introduce important steps, in the right order, and give tips that we have encountered during the operation.

Here are some assumptions.

1. First acknowledge that the source GroupWise and target Exchange systems are perfectly suited to each other.

1. Assuming that you have followed the previous seven sections of this series, you have backed up your Active Directory user objects with MS Exchange Connector for Novell GroupWise.

There are many different ways you can redirect user objects in Active Directory, but the two most common migration scripts from NDS to AD are Quest's migration to NDS and AD from the NDS. The importance of using the MS Exchange Connector is that it creates Active Directory user objects based on the GroupWise folder and not the NDS.

Note, GroupWise maintains the root directory separate from NDS. This is very similar to Exchange 5.5 on NT 4.0. If you backup your Active Directory objects based on NDS, there will be a phase in the migration process where GroupWise objects and Active Directory objects (previously considered NDS objects) are matched. together to create a separate set of target objects.

This consolidation can cause some problems. Imagine a scenario where NDS and GW objects are created for Karen Smith, who then becomes Karen Jones after she gets married. Typically, the GroupWise object will be updated, because the email address is present. The NDS object may or may not be updated, which makes these objects not merge.

We will look at similar issues where GroupWise objects are misspelled, or where hyphenated names or other names are managed differently between NDS and GW.

Objects that fail to merge are written with a utility named AD Object Merge.
Since we have provisioned our Active Directory object directly from the GroupWise directory, this step becomes much simpler.

Quest software suite

A set of products and tools are included in the Quest software:

1. Directory Exporter
2. The Active Directory Object Merge Tool
3. Administrator Driven Batch Migrator
4. Self-Service Desktop Migrator
5. Quest Log File Viewer

Typically, each of these tools performs a specific step in the migration process, but there are some that take more steps.

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

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

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

Figure 1: Enter GroupWise information in Directory Exporter

Then Directory Exporter will connect to GroupWise and extract the Address Book as shown in Figure 2.

Figure 2: Directory Exporter is connecting to GroupWise to read the address book information

The stages in the migration process are shown in Figure 3.

File name

Path

UsersToMigrate.csv

C: Program FilesQuest SoftwareGroupWise Migrator for Exchange

UsersToMerge.csv

C: Program FilesQuest SoftwareGroupWise Migrator for Exchange

GroupsToProvision.abk

C: Program FilesQuest SoftwareGroupWise Migrator for Exchange

AddressTranslation.csv

C: Program FilesQuest SoftwareGroupWise Migrator for ExchangeShared

Table 1: Four output files of Directory Exporter

These four files are the main file set. The best advice is to copy them to a safe location. There is a lot of variation in the content of these files and a backup copy will really be useful for you right now.

During the migration process, you will work with a small set of data from the directory export because then you will run the migration process in the blocks. For each block, they will remove the user executed from the migration process from the file, or work with a separate set of migration files for each block.

Three of the four files are almost the same.

1. UsersToMigrate.csv
2. UsersToMerge.csv
3. AddressTranslation.csv

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

The contents of these three files allow you to merge, migrate, and perform administrative functions on the same set of mailboxes for each migration phase.

The trick with manipulating these files is to always work with a copy UsersToMigrate.csv , then save it twice as UsersToMerge.csv and AddressTranslation.csv .
If you use a separate set of migration files, call them eg Phase-1-Migrate , Phase-1-Merge and Phase-1-Translate.csv

Merge Active Directory object - AD Object Merge

When you have a complete export directory, we need to perform an AD object Merge. This is to ensure that any Active Directory user object is properly linked to the corresponding GroupWise mailboxes, and needs to be large, as we mentioned above, most resources Frequently, Active Directory objects are NDS and not GroupWise.

Let's take a look at the UsersToMerge.csv file

There are two fields to consider: ObjType and NDSUsername.

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

Note that the object types in 2 and 3 do not have NDSUsername values.

The contents of the NDSUsername attribute are matched to the User logon name (pre- W indows 2000):   field on the User Account tab in Active Directory, as shown in Figure 4.

Figure 4: Login field of Pre-Windows 2000

The export directory may also include objects synchronized with the connector from Exchange. Our export directory contains 21 objects.

1. 11 users
2. 6 distribution group
3. 2 resource mailbox
4. 1 external entity
5. 1 Exchange user.

When running the Active Directory Object Merge Tool , after providing the program with a source file containing our list of objects to merge, we will have three options to find users in Active Directory, as shown. in Figure 5.

1. Find objects by Pre-Win2K username
2. Find users from Quest NDS Migrator database
3. Find objects by attribute

Figure 5: Select how to find users in Active Directory

If simply executing an AD object Merge using the pre-Win2K default username, any object without the popular NDSUsername attribute will fail during the merge process.

Figure 6: Merge Tool results panel

If we check the contents of the Merge Report, we can see that all users with the NDSUsername attribute are merged, but many of them still fail.

There are two options here. We can live with these numbers as they grow and understand them, or we can create a data message in .csv files to allow us to delete.

For example, if we delete the distribution groups and exchange users from the UsersToMerge.csv file, then there will be only 14 objects left.

1. 11 users,
2. 2 resource mailbox
3. 1 external entity

Next, the simplest solution is to migrate the NDSUsername field to these objects by using values ​​taken from Active Directory objects.

Figure 7: Common NDSUsername field

It should be noted here that User login names does not contain spaces, where GroupWise mailboxes are executing, for the Board Room example in GroupWise to become BoardRoom in Active Directory so we need to remove these spaces.

Figure 8: Merge the Active Directory object

Conclude

Here, we have introduced you to workstation migration, besides providing information about the Quest suite and completing the first two phases of the migration process using Quest tools. . In the next few articles, we will complete the process using the Provisioning of Distribution Groups.