GroupWise to Exchange 2007 Migration – Common Q & A

By /

If you missed this article series please read:

 

 

 

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.

 

Brief

 

This article began life because of the amount of feedback we have received after our series on GroupWise to Exchange 2007 migration. In this article we aim to answer in print the key questions raised and to elaborate a little more on what to expect during migration, what to watch for and to discuss some real world experience garnered on projects undertaken since the series was first written. We hope it is of some use!

 

Before we begin, we would like to offer a special thanks to Southampton University Hospital for allowing their pilot migration experiences to be used as reference material and for providing screen shots.

 

Mail Routing

 

We have had many questions around mail routing, between Exchange and GroupWise and the outside world, so we will start here by answering the most frequently asked questions.

 

Inbound E-mail from Outside

 

As discussed in support.microsoft.com, if you send e-mail inbound via GroupWise you need to use the /DIA and /ARI-NEVER switches in the gwia.cfg, which can cause issues if you are not using USER_ID as the mailbox part of your internet format addresses.

 

Gwia.cfg options are described at msdn.microsoft.com.

 

What happens when you do this is that GroupWise looks at the user portion of the inbound e-mail address, and appends the domain specified in the Foreign ID field on the GroupWise tab on the GWIA properties as shown in Figure 1.

 


Figure 1: The Foreign ID Field

 

If user_id@ForeignID domain matches a GroupWise mailbox then e-mail is delivered. If user_id@ForeignID domain doesn’t match anybodies mailbox you get a very quick NDR.

 

If you do not disable Internet Addressing with /DIA then all inbound mail for Exchange mailboxes (migrated users) is treated by Exchange as bad. GroupWise processes messages inbound in such a way as to confuse Exchange, and when the GWRouter service gets hold of messages (which implies they have successfully passed through the GroupWise system) it does not like the format of the message header file so it bins the message. You will find the headers in the conndata\gwrouter\badfiles directory.

 

Bottom line, inbound via GroupWise is a problem unless you can /DIA and not everybody can.

 

Inbound via Exchange works better but it is still not perfect as any message inbound via Exchange with HTML formatting in the message body will be delivered to GroupWise mailboxes as plain text.

 

The ideal would be to deliver Exchange mail to Exchange, and GroupWise mail to GroupWise. You need some sort of relay or smart host to do this.

 

All Exchange 2007 objects will have unique addresses, such as GWISE:Exchange.* Any smart host that can do LDAP lookup for users with an Exchange specific address such as GWISE:Exchange.* in proxyAddresses can then deliver mail that matches to Exchange, and everything else to GroupWise.

 

IMCEAGWISE

 

If you see message addressed to IMCEAGWISE do not panic, this is perfectly normal. Exchange 2007 is encapsulating the GroupWise address in SMTP format and relaying it via Exchange 2003 to be delivered to GroupWise. Exchange 2003 knows how to deal with the IMCEA encapsulation, and strips it before the message is delivered.

 

@Exchange.FirstAdministrativeGroup

 

User_ID@PostOffice is a valid e-mail addressing format within GroupWise. A situation can arise where an Exchange user sends an e-mail to a GroupWise user. This GroupWise user is then migrated to Exchange, and tries to reply to the mail received while still on GroupWise. The recipient or reply address to the original mail shows up as c[email protected] Administrative Group

 

This message can not be delivered because the address contains spaces, which are illegal in SMTP.

 

The GroupWise PostOffice portion of our Exchange user addresses are made up from the Administrative Group name.

 

If we change the Admin Group name to remove spaces, or simply just change it completely then our recipient policy and our Dir Sync will give Exchange users the new admin Group as the Post Office portion of the GWISE address.

 

We need to add @Exchange.FirstAdministrativeGroup as an accepted domain in Exchange 2007, and assign @Exchange.FirstAdministrativeGroup as a recipient policy, then everything kicks in to play and works.

 

An interesting point here is that an Exchange mailbox can have one GWISE: (primary) and as many  gwise: (secondary) proxyAddresses as you like, but the routing logic when the GWRouter accepts incoming messages is to compare the PostOffice portion of the GroupWise address to the list of Administrative Groups available in Exchange.

 

As long as we have an Exchange Admin Group, even an empty one  that corresponds to the PostOffice portion of the GroupWise address, GWRouter will accept the message inbound, and Exchange will deliver it.

 

Technical Migration Errors

 

Do not use a Migration account with ” in the password. The Quest utility gets very confused. It seems to read everything after the ” as input, and complains about the file paths in the gwdirapp.ini file

 

Probably the vast majority of errors you will get during the actual mailbox migration will be ACL errors caused by proxy permissions that are assigned to GroupWise users that do not exist in AD as shown in Figure 2.

 

There may be a handful of GWCHECK issues, on archives as well as mailboxes. It is probably easier to run GWCHECK on the mailboxes highlighted in the migration log as shown in Figure 2, than to run it as a matter of process for all mailboxes before you migrate, especially on archives.

 


Figure 2:  Errors in the migration log

 

Another thing which can cause problems is mail in the root of an archive.

 

Post office names with a forward slash “/” cause issues with archive conversion to .pst files, as the subdirectory of the PST output root directory: as shown in Figure 3, is determined by the PostOffice name, and / is an illegal character for a folder name.

 

To mitigate this, you can either rename the post office, or migrate these archives directly into the Exchange Server database, or use the Home directory of NetWare account, although in the case where you are also migrating from NetWare to AD, the home directory option is not viable.

 


Figure 3:  Specifying the PST Output Root Directory

 

Not So Technical, Migration Issues

 

Mailbox structure

 

Not everybody stores mail where you would think, very often a user will complain of lost messages, when in fact they just exist in a folder they have not looked in. Mailbox messages, as shown in Figure 4, do not always appear in the Inbox!

 


Figure 4:  The GroupWise Mailbox

 

Forwarding and auto-replies

 

This can cause confusion. People just do not understand why they are getting messages from themselves!

 

An e-mail address is almost as unique as a finger print. In theory any public e-mail address should uniquely identify a recipient. You should be able to send mail from anywhere, and provided the address is valid it should arrive in only one place. Ideally, post migration you would delete the source GroupWise mailboxes and the mailbox would have moved from GroupWise to Exchange, but still uniquely exist in one place. Most people however choose to retain the GroupWise mailboxes, and simply hide them, or set visibility to none. So we now have a situation where each system has a mailbox that it thinks is unique, and this is when funny things start to happen.

 

Frequent Contacts in GroupWise will store the GroupWise Domain.PostOffice.User_ID address for GroupWise users that have been migrated to Exchange. If the source or legacy GroupWise mailbox still exists, then GroupWise will still deliver mail to it.

 

If you configure the forwarding options in the Quest utility, the message appears to come from the recipient GroupWise mailbox, not the sender GroupWise mailbox.

 

The best option here is the flat forward (/flatfwd) using a second GWIA, and use SMTP forwarding to an SMTP address space that only exists within AD, either the default recipient policy/ accepted domain, or a domain specifically assigned for the migration as shown in Figure 5.

 


Figure 5: Setting the Use SMTP for forwarding option

 

Proxy calendar access

 

The GroupWise client also stores explicit Domain.PostOffice.User_ID references for proxy calendar access, so a situation can arise after a user is migrated, even when the source mailbox is hidden (has its visibility set to none), where users that still reside on GroupWise can still proxy into the migrated users calendar. This causes confusion, as the legacy calendar is no longer kept current.

 

Even after a mailbox is hidden, you can still open it from the GroupWise client if you explicitly specify the domain and post office.

 

Resource Owners

 

In GroupWise a resource is a GroupWise mailbox with no corresponding NDS user object. Resource Owners don’t actually have explicit mailbox rights set, so when the Quest utility migrates mailbox permissions the Resource owners lose their access. In Exchange the original Resource Owner needs to have his permissions re-assigned.

 

GroupWise Does Things Differently

 

In GroupWise you can retract a message. If you delete a message from your sent items, you have the option to remove it from the inbox of any of the recipients as shown in Figure 6. GroupWise considers this to be “your” message.

 


Figure 6: Options for deleting messages

 

In Outlook a message recall request needs to be approved by the recipient and then only works if the original message has not been read. Also in Outlook, if you delete your sent item, you just delete your sent item. Once a message has arrived, it belongs to the recipient.

 

In GroupWise you can get message properties and see who had opened a message as shown in Figure 7.

 


Figure 7: Showing the GroupWise message properties

 

In Outlook you can request a read receipt. Not quite the same thing.

 

These are not strictly technical issues, but they affect the way people use the system and expect the system to work, so it is worth pointing them out, or at least being ready for them.

 

Free-Busy Lookups from Outlook 2007 to GroupWise

 

If a user on Exchange 2003 does a free-busy lookup for a GroupWise user, the returned information is cached in the Exchange 2003 public folder and replicated to Exchange 2007. Any Exchange 2007 mailbox user can then query for the same info, and depending on the timings, set on the Calendar connector the free-busy info will be returned.

 

If a mailbox on Exchange 2007 queries a GroupWise users Free-Busy, the same should work, Exchange 2007 should query the public folder database, and if it doesn’t find anything to return it should route a query via Exchange 2003 to GroupWise.

 

I have to be honest though what I do is simply modify the Default public folder database: under Client Setting for the mailbox database in Exchange 2007 to use the Public Folder store in Exchange 2003 as shown in Figure 8, and then there are no Public Folder replication or routing group issues to worry about, and everything just works.

 


Figure 8: Setting the default public folder database

 

Note:
Remember to change the Public folder back before you turn off Exchange 2003.

 

Missing ConsoleOne Snap-ins

 

Follow the instruction here: novell.com

 

Missing NWAdmin32 Snap-ins

 

This really is important however, compared to ConsoleOne, it is not so easy. I am part way there with these instructions but it is not complete however hopefully this will help some people and perhaps a future blog post will offer further updates.

 

Install the latest version of NWAdmin32 (Version 5.1.9f). You can find this on the download.novell.com website by doing an advanced search for admn519f.exe

 

Or you can follow this link: download.novell.com

 

Download the admn519f.exe to your c:\ drive, and click on the .exe and it extracts into a directory structure called c:\admn519f\Public\Win32

 

From here you can run NWAdmin32, but as yet this does not have the GroupWise extensions installed.

 

Next, download the API snapins from here: novell.com/solutions

 

Extract the contents to the root of your c:\ drive but do not run the install.

 

The snapins will create a directory structure called c:\apisnapins

 

In this directory, there is a structure called FGWEP1AD\PUBLIC.

 

Copy everything from inside the FGWEP1AD\PUBLIC directory into the c:\admn519f\Public\Win32 directory we created earlier. This should replace most of the files in the NLS and SNAPINS subdirectories and put a whole load into the Win32 directory

 

Finally, download and run NGWAUP.EXE from: download.novell.com

 

Now when you run NWADMIN32 it should work with GroupWise.

 

The exact functionality you get depends on the version of GWADMB32.DLL. I am afraid that I have not been able to categorically identify which version gives you the elusive Required Parameters tab on the API gateway properties although it has been rumored to be the version from the GW 5.5 system. If anybody can take the next step and categorically figure this out, please do let me know.

 

Outlook Permissions

 

How do I give John Smith access to my calendar? This is a bit involved, have a look at my blog on mmmug.co.uk/blogs.

 

In Outlook, How Do I… ?

 

RTFM 😉

 

Summary

 

So with luck that answers the bulk of the queries we have received and gives a further insight into some of the key issues that can crop up during migrations.

 

If you missed this article series please read:

 

 

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