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

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.

 

Configuring the Calendar connector

 

In Exchange System Manager (ESM) right click it and select properties.

 

The Calendar connector is generic and can be used with both Notes and GroupWise. The General tab shown in Figure 1 needs to know which connector it’s working with, so hit Modify…, type Connector, hit Check Names and it will list all of the available connectors to choose from. In this case there is only one.

 


Figure 1: The General Tab of the Calendar Connector

 

Next, change to the Calendar Connections tab, and click New. Then as shown in Figure 2, pick Novell GroupWise.

 


Figure 2: Selecting the Calendar system to connect to

 

Click OK, and then type the name of the GroupWise API Gateway:

 

All we need here is the name, in the format domain.gateway.

 

In this case, as shown in Figure 3, that is DOM1.Exchange.

 


Figure 3: Entering the name of the GroupWise API Gateway

 

Set your schedule, hit apply, and we’re done. Having finished the configuration we will now move on and test the functionality and then look at some possible troubleshooting steps

 

Finally before moving on from the Calendar connector, In Part 3 we talked a little bit about the GWISE Recipient policy. For the reasons detailed in the following Microsoft KB article it is worth enabling the GWISE proxy address in the Default Recipient Policy instead of creating a new policy

 

Event ID 6001 messages are logged when you use Exchange 2000 Calendar Connector

 

The Moment of Truth – Starting the API

 

At the end of Part 3 we finished the required configuration of the connectors to get directory objects synchronized. Before we start the connector or the API there are a few steps I normally follow.

 

I’ll walk you thru these, and hopefully they will help explain some more about how this all hangs together.

 

When you install the API using NWCONFIG on the GroupWise Post Office, an API directory structure is created under the wpgate directory. As well as a handful of files, this directory structure contains three subdirectories after the API has been installed and before it has been started.

 

These subdirectories are

 

 

  • GWCHARS
  • HELPRQST
  • SAVE

 

If the wpgate\API directory structure exists and only contains these three directories, we can safely assume the API is not running and has never been started.

 

As an aside, if the wpgate\API directory structure contains five subdirectories, those above plus those below, we can assume the API tried to start, but failed.

 

 

  • GWPROB
  • GWHOLD

 

The installation of the API gateway is really a pretty basic thing. The only half tricky step is the Domain Path. Which again for reference is in the format Volume:Path

 

The most common cause for this failure in my experience is either where the gateway object hasn’t been defined in ConsoleOne as in Article 3 or more likely when the Required Parameters for the gateway object, shown in Figure 4, contain an invalid Root Directory reference such as a drive letter instead of a <Server Name>/<Volume>:\<Path>

 


Figure 4: Setting the correct Gateway File Paths

 

I appreciate if you walk thru the articles in the order we’ve written them, and follow the instructions then these Root Directory paths should be correct, but I also appreciate that by the time you find these articles you may already be in trouble, and that once you start troubleshooting, it can be very easy to lose track of what has been installed, removed, re-installed…

 

Once the Gateway object has been defined in Netware Administrator and/or ConsoleOne, you can start the API from the Netware System Console using the API command. Remember, CTRL+ESC lists the Current Screens.

 

The first thing to note once the API starts is the additional directories that are created under wpgate\API

 

 

  • 000.PRC
  • API_IN
  • API_OUT
  • ATT_IN
  • ATT_OUT
  • WPCSIN
  • WPCSOUT

 

If these directories are present, we know that the API has run at least once in the past, and is hopefully running now.

 

Stay with the Netware System Console for a moment. CTRL+ESC will list the Current Screens. If the API is running select it from the list. If it isn’t, select System Console, and run the API by typing API.

 

Now press F9 to browse the log file, and use the page up page down keys to have a look around. You should notice a line that looks like this

 

02-27-08 19:58:05 **************** Gateway Started ****************

 

Three lines down from this you should see Domain and Gateway which in my case = DOM1.Exchange, the domain and the Gateway object.

 

Look down a further four lines and the Root Directory, Work Directory and Log File locations are also listed. The log file you will notice is in the 000.PRC subdirectory which is created when the API starts.

 

You can also browse to this log file using Windows Explorer and open it using Notepad as shown in Figure 5.

 


Figure 5: The API log file

 

Still within the API on the Netware server, press F1 to cancel browsing the log file.

 

Now press F10 for options.

 

Press F2 twice to set the log level to Diagnostic, this provides far more output, but it can be very helpful. Figure 6 shows the logging level configured.

 

Press F1 to Exit Options and we’re done on the NetWare server.

 


Figure 6: GroupWise API screen showning the logging level

 

At this point we have a defined Gateway object, and an API that has started. Again, if you have been following our series of articles you will also have created an External Foreign Domain and linked it to the GroupWise system.

 

Mail Flow

 

So how does mail actually get from one system to the other? Well, GroupWise addressing follows a pretty simple format. Domain.Post Office. Mailbox

 

Once we create the External Foreign domain, and link to it, GroupWise will send anything that starts with Exchange. over the API. It’s really that simple. As far as GroupWise is concerned, Exchange. is the domain name, so if you start the address with Exchange. you must belong to that domain.

 

So here’s a simple test. Within the GroupWise client, start a New Mail.

 

In the To: field, type Exchange.First Administrative Group.Administrator

 

You may or may not have the Connector for Novell GroupWise installed at this point, and DirSync may or may not be working, it really doesn’t matter. If the External Foreign Domain has been created and correctly linked, the GroupWise client will accept this address and you can Send the message.

 

If on the other hand you receive the error shown in Figure 7, this is an indication that the Exchange External Foreign Domain hasn’t been properly created yet.

 


Figure 7: The GroupWise addressing error message

 

If the Exchange and GroupWise connectivity is fully up and running, then this mail should arrive in the Administrator mailbox on the Exchange Server. If the Exchange Connector hasn’t been installed or started, then the message is prepared and ready for Exchange, and left in two places within the wpgate\API directory structure.

 

The message header can be found in wpgate\API\API_OUT.

 

The message body can be found in wpgate\API\ATT_OUT.

 

Page 125 of the Microsoft Exchange Server 2003 Interoperability and Migration Guide (Search for e2k3InterOpMig.doc) details a procedure to modify this outbound message and verify that it get’s returned to the sender GroupWise mailbox. In my experience if the messages get as far as API_OUT and ATT_OUT, then the API is working.

 

So far with the GroupWise system we’ve installed, configured and now started the API, increased diagnostic logging, watched the creation of the API directory structure, located the log file directory and gained a little understanding of how this directory structure is used. There really is too much to go into if things don’t go according to plan. I know I’ll live to regret this, but if you get this far, and things aren’t working, drop us an e-mail.

 

Starting the Exchange Connectors

 

What I like to do after the Connector for Novell GroupWise and the Calendar Connectors have been installed and configured is follow a routine;

 

All of the Services associated with the connectivity are set to manual start. Leave them like this for the moment. Within Exchange System Manager, right click the server running the Connector and get Properties. On the General tab Enable message tracking, as this is invaluable when we come to a point where we need to know if messages are reaching or leaving Exchange. Also on the Diagnostic Logging tab note what additional Services are available for logging as shown in Figure 8. For the moment leave these set to none.

 


Figure 8: Viewing the addition GroupWise services available for logging

 

Next, clear out the application and system event logs, and restart or bounce the server. These steps are performed to get a baseline for any issues that exist before we start, so that we know what pre-existing condition the server may be in. Once the server comes back up, and we’re happy with all of the event logs, again, clear down the Application Event log.

 

At this point you are ready to start the GroupWise connector on the Exchange server which is done by entering the services administrative tool (Start, Run, Services.msc). Right Click the Microsoft Exchange Connector for Novell GroupWise, and click Start. This should also start Microsoft Exchange Connectivity Controller and the Micorosft Exchange Router for Novell GroupWise.

 

Next, check the application event log. You should see five events logged.

 

 

  • Source MSExchangeGWRtr event 6015 means the Exchange Router for Novell GroupWise service has started.
  • Source MSExchangeCoCo event 8229 means the Microsoft Exchange Connectivity Controller service has started.
  • Source MSExchangeGWRtr event 5016 means the Connector is logging in to the Novell volume.
  • Source MSExchangeGWise event 8229 means the Microsoft Exchange Connector for Novell GroupWise service has started.
  • Source MSExchangeGWRtr event 5019 means the Connector has successfully connected to the Novell volume using the configured user account.

 

If you see anything other than these five events logged, something is wrong. Especially if any of them are error events. From experience, here are some of the events you don’t want to see, and the likely cause.

 

If you specify the account credentials incorrectly, the error you will see is.

 

 

  • Source MSExchangeGWRtr Event 5017 Connection , The system error code is 1219

 

If you don’t install the Novell client, which is an easy mistake to make, you will see

 

 

  • Source MSExchangeGWRtr Event 5017 Connection , The system error code is 1203

 

While we’re dealing with event logs, for reference, if you don’t loosen the default domain password policy when you try to perform the initial Immediate full reload from GroupWise to Exchange the application event log lights up like a Christmas tree. The errors you will see are

 

 

  • Source MSExchangeADDXA Event 8270 LDAP Operations, LDAP returned the error [35] Unwilling to Perform when importing the transaction

 

followed by

 

 

  • Source MSExchangeGWISE Event 8307 GroupWise Directory Syn, Error 4b8: Problem Occurred when importing entry ‘Cindy Wright’ to Exchange

 

The settings you need to change within the Default Domain Policy can be found under Computer Settings, Windows Settings, Security Settings, Account Policies, Password Policy.

 

The minimum setting I would recommend in order to allow the creation of new user objects is as follows

 

 

  • Enforce password history                                             Leave unchanged
  • Maximum password age                                              Leave unchanged
  • Minimum password age                                               Leave unchanged
  • Minimum password length                                          0 (No password required)
  • Password must meet complexity requirements     Disabled.
  • Store passwords using reversible encryption        Leave unchanged

 

Now that everything is running, start the Microsoft Exchange Calendar Connector. This should log a sixth event which just means the connector has started.

 

 

  • Source MSExchangeCalCon Event 6015

 

At this point I would set the Microsoft Exchange Connector for Novell GroupWise and the Microsoft Exchange Calendar Connector to Automatic, so that they restart every time the server does.

 

Directory Synchronization

 

Within Exchange System Manager, under the Connectors container, right click the Connector for Novell GroupWise and get Properties. Switch to the DirSync Schedule tab.

 

With all of the connectors started, and the Default Domain policy loosened, if you haven’t already, Press Immediate full reload for both GroupWise to Exchange and Exchange to GroupWise.

 

Open ADUC, and watch the user objects pop up. If you’ve done everything correctly, you should have new user objects in the OU you specified for import into Active Directory as shown in Figure 9.

 


Figure 9: New Objects in the GroupWise Sync OU

 

You should also find that the new users show up in the GAL which is shown in Figure 10.

 


Figure 10: New entries in the GAL

 

Each one should have the GroupWise post office listed on the Exchange General tab of their user object properties which you can see in Figure 11.

 


Figure 11: The GroupWise address of the synced object

 

Finally, we need to test whether accounts are synchronized from Exchange to GroupWise. To do this, move the only existing mailbox enabled user, the Administrator, into the Exchange Users OU (or whichever OU you setup for export), to see it get synchronized back to GroupWise.

 

Check it has been synchronized using the GroupWise client.

 


Figure 12: The Exchange Administrator mailbox shown in the GroupWise client

 

Notice in Figure 12, how the GWISE proxy address is displayed in GroupWise, as we described earlier.

 

A nice tip to allow you to watch and troubleshoot exactly what is going on at the Microsoft end is to create a registry DWROD on the Exchange server to archive everything that goes through the program files\exchsrvr\conndata\gwrouter directory structure. This is the directory structure on the Exchange Server that effectively is the connector.

Create a DWROD value called Archive with a value of 1 under
HKLM\SYSTEM\CurrentControlSet\Services\LME-GWISE\Parameters

 

and then restart Exchange Router for Novell GroupWise service. This creates an additional directory under gwrouter called archive which retains a copy of every file that transitions the gwrouter directory structure as shown in Figure 13. This is very valuable, as the files are transitory, and once they are processed they are purged, so unless you enable the archive subdirectory you have a job catching files on the fly.

 


Figure 13: The archive directory

 

Summary

 

If you have followed the series this far you are well on the way to migrating from GroupWise to Exchange. One thing we have not yet covered is Free/Busy transfer between the two systems. It is fair to say that this is often a very challenging area to get working! In the next article we will discuss this further, begin implementing Exchange 2007 and cover the Microsoft statement of support for migrations of this type.

 

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.

 

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