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

By /

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

 

 

 

Free/busy is the Holy Grail of GroupWise to Exchange Migration. In the first part of the article my co-author Declan Conroy and I deal with Exchange 2003. The second part of the article will bring Exchange 2007 into the mix.

 

This article is going to:

 

 

  • Explain how free/busy information is requested and passed between GroupWise and Exchange 2003
  • Explain how to check that the correct information is being passed.
  • Explain how Exchange 2007 complicates things.

 

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.

 

Microsoft Support Statement

 

Officially GroupWise 7 interoperability with Exchange Server is not supported by Microsoft.

 

The official policy for GroupWise co-existence is outlined in

 

Exchange support for Novell GroupWise version 6.x and 7.x

 

Microsoft specifically say:-

 

 

  • Microsoft Exchange Server 5.5, Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003 support Novell GroupWise versions 4.1x, 5.0, 5.1, 5.2x, and 5.5x.
  • Exchange Server 2003 Service Pack 2 supports Novell GroupWise versions 4.1x, 5.0, 5.1, 5.2x, 5.5x, 6.x and 6.5x.
  • Novell GroupWise version 7 has not been tested with the Exchange components that are listed in this section. Therefore, Novell GroupWise version 7 is not supported.
  • There will be no support for these versions of Novell GroupWise with the Connector or Migration Tools from other versions of Microsoft Exchange Server.

 

This final bullet point is the all important one. There is no intention to support GroupWise interoperability within Exchange 2007 or any future versions of Exchange.

 

My understanding is that this statement is not likely to change.

 

This makes life kind of tricky.

 

 

  • There is no GroupWise connector for Exchange 2007.
  • Exchange 2003 is not supported beyond GroupWise 6.5.

 

The implication then is that to migrate from GroupWise to Exchange Server 2007, you need to use an Exchange 2003 Server and that in a GroupWise 7 environment you need to install an additional GroupWise 6.5 Post Office to host the GroupWise API.

 

For the record let me just clarify that interoperability between Exchange 2003 with Service Pack 2 and GroupWise 7 does actually work, although it’s not officially supported, although the use of an unsupported migration process constitutes a considerable risk to any migration project.

 

For these articles we are running

 

 

  • Exchange 2003 with Service Pack 2
  • GroupWise 7 on Netware 6.5

 

We haven’t made any changes to our basic installation of Exchange 2003. Importantly, we haven’t paid any attention to “Send As” permission behavior change in Exchange 2003 and the change to “send as” permissions.

 

Before we get too far, we have to print a correction. In Article 2 we configured the API gateway, and the External Foreign Domain both with the same name. We called them both Exchange.

 

This was bad practice. If you haven’t yet followed the instructions in previous articles then don’t worry because they’ve been updated, if you have already configured your gateway and domain, then apologies, you’re going to have to redo the gateway setup.

 

We’ve left the External Foreign Domain called Exchange as this ties in with the Exchange Recipient policy. In order to differentiate between the two NDS objects, we’ve chosen to call the Gateway GW2MEX.

 

We’d like to thank Matt Dunkin of Salford Software for his assistance with troubleshooting message flow between our test servers, and for determining that the most probable cause of the issue was duplicate object names.

 

GroupWise and Exchange 2003

 

In Article 4 we configured the Calendar Connector to work with the Microsoft Connector for Novell GroupWise. We started the API and all of the Microsoft Exchange services, and learned what to watch for to ensure that both the API and the services started correctly.

 

Next we’re going to set up our system to monitor information flow between Exchange and GroupWise so that we can see what happens when we do a free/busy search between the systems.

 

In Article 4 we created a DWORD registry entry called Archive with a value of 1 under HKLM\SYSTEM\CurrentControlSet\Services\LME-GWISE\Parameters on the Exchange Server running the connectors. This creates an archive copy of all message that flow between GroupWise and Exchange via the \Program Files\Exchsrvr\conndata\gwrouter directory structure.

 

We’re also going to follow the instructions in How to Enable and Increase Logging for Microsoft Exchange Connectivity Controller Connectors to increase the logging levels. For the purposed of this article, we’re going to increase the diagnostic logging levels for MSExchangeCalCon to Maximum for all categories as shown in Figure 1. Bear in mind that all of this increased logging is both resource and disk space intensive, so once we’re happy that everything is working as intended, we can turn it all off again.

 


Figure 1: Setting the logging level for MSExchangeCalCon objects

 

Without reproducing huge sections of troubleshooting articles that are widely available, let me give you a quick rundown on what happens when you request free/busy information between Exchange and GroupWise.

 

There are two directories on the Exchange server under \conndata\gwrouter used to process free/busy requests and replies. The \togwise and the\freebusy directories.

 

Within the GroupWise API there are also two directories used, the wpgate\API\API_IN and wpgate\API\API_OUT

 

Finally within GroupWise itself there are the WPCSIN and WPCSOUT directories.

 

Messages flow between Exchange and GroupWise passing thru all six of these directories, as shown in Diagram 1 for every free/busy request and reply.

 


Diagram 1: The use of the six directories which process Free/Busy requests

 

Free/busy requests from Exchange to GroupWise are placed in the \togwise directory, and the Router for Novell GroupWise moves these messages to the \API_IN directory within the API folder structure. From here the API gateway processes the message, and moves it \WPSCIN where it is picked up and processed by the GroupWise MTA.

 

In the opposite direction, messages from GroupWise to Exchange start in \WPCSOUT, where they are picked up by the API gateway and moved to \API_OUT and are then transferred by the Router for Novell GroupWise to the \freebusy directory.

 

It’s a pretty simple process. Both free/busy requests and replies from Exchange to GroupWise use the same path, as do requests and replies from GroupWise to Exchange.

 

With the archive registry edit we made in Article 4, we can keep a record of all messages from both the \togwise and the \freebusy folders, and we should be able to track requests and replies.

 

Testing in Outlook

 

I find that the simplest way to test free/busy from GroupWise into Exchange is to use a Group Schedule for reasons that will become obvious. I’m running Outlook 2003 on Windows XP SP2.

 

In Outlook 2003 I have created a group schedule called GroupWise, as shown in Figure 2, and I’ve added in all of the GroupWise users (those with a mailbox still on GroupWise) which are shown in the Exchange Global Address List.

 


Figure 2: The name of the Group Schedule in Outlook

 

When I open the Group Schedule for GroupWise, the following happens.

 

For each GroupWise user in my Group Schedule, Outlook queries the Schedule+free/busy public folder for free/busy information.

 

Depending on the properties configured on the General Tab of the Calendar Connector shown in Figure 3, Exchange will either deliver free/busy information directly back to Outlook if it is cached and less than 15 minutes old or If the information isn’t already present in the free/busy public folder or it’s more than 15 minutes old Exchange sends a free/busy request to GroupWise.

 


Figure 3: The General tab of the Calendar Connector showing maximum Free/Busy cache time

 

These free/busy requests can be seen in the \Program Files\Exchsrvr\conndata\gwrouter\archive\togwise folder.

 

For example a simple free/busy query for Ian West generates a file called EGW4C.api in the togwise directory

 

If I watch the API gateway on my GroupWise server with diagnostic logging set to Verbose I can see EGW4C.API processed as an incoming message as shown in Figure 4.

 

I can then see the corresponding outbound message 15 seconds later.

 


Figure 4: The API processing the Free/Busy request

 

If I choose the Outlook option to Refresh free/busy within 15 minutes of this original transaction, no additional message are sent or received between the two systems, and the free/busy information presented is taken from the free/busy public folder.

 

With API diagnostic Logging set to Diag (F10, then F2, then F1), there is additional information present in the saved log files in the wpgate\API\000.PRC directory.

 

03-29-08 18:40:35 Processing inbound message – File: EGW4C.API
03-29-08 18:40:35   Msg-ID: AAKEIJEI:2008.3.29.18.41:2008.5.28.19.41:2008.3.29.18.41.37;
.
03-29-08 18:40:45 Processing outbound message…
.
03-29-08 18:40:45   Orig-Msg-ID= AAKEIJEI:2008.3.29.18.41:2008.5.28.19.41
:2008.3.29.18.41.37;

 

The Msg-ID: and the Orig-Msg-ID= reference is the same one included in the archived EGW4C.api file.

 

WPC-API= 1.2;
MSG-TYPE= Search;
Msg-ID= AAKEIJEI:2008.3.29.18.41:2008.5.28.19.41:2008.3.29.18.41.37;
From=
WPD= dom1;
WPPO= GW2MEX;
WPU= EXCHANGE2003-SA;
CDBA= dom1.GW2MEX.EXCHANGE2003-SA; ;
To=
WPD= DOM1;
WPPO= PO1;
WPU= Iain;
CDBA= DOM1.PO1.Iain; ;
Begin-Time= 29/3/2008 18:41;
End-Time= 28/5/2008 19:41;
-END-

 

The free/busy request contained in the EGW4C.api file is taken from the \gwrouter\togwise directory on the Exchange Server, and delivered to the wpgate\API\API_IN directory on the GroupWise Server. The API recognizes that the message type is a search

 

MSG-TYPE= Search;

 

and delivers it to GroupWise for processing.

 

GroupWise processes the message and the response is placed in the API_OUT directory, where it is then picked up by the Microsoft Exchange Router for Novell GroupWise, and moved into the gwrouter\freebusy directory.

 

The response to the free/busy request looks like this.

 

WPC-API= 1.2;
Header-Char= T50;
Msg-Type= SEARCH;
Orig-Msg-ID= AAKEIJEI:2008.3.29.18.41:2008.5.28.19.41:2008.3.29.18.41.37;
To=
CDBA= dom1.GW2MEX.EXCHANGE2003-SA;
;
Busy-For=
CDBA= DOM1.PO1.Iain;
Busy-Report=
Start-Time= 29/3/08 0:00;
End-Time= 31/3/08 8:00; ,
.
.
.
Start-Time= 28/5/08 17:00;
End-Time= 29/5/08 0:00;
;
Send-Options= None;
-END-

 

There are 60 days worth of Start-Time and End-Time pairs in this file, which is the default set for Number of days of free/busy information to request from foreign calendars set on the General tab of the Calendar Connector shown in Figure 3 and as an extract below in Figure 5.

 


Figure 5: An extract from the General tab of the Calendar connector showing the 60 day free/busy age limit

 

As detailed in PSS Article ID: 304726 “XFOR: Exchange Calendar Connector Free-and-Busy Searches Display Busy Time from 5:00 P.M. Through 8:00 A.M.” this information effectively marks each GroupWise user as busy from 17:00 until 08:00 the following day, and also as busy all weekend.

 

As a result, the free/busy information displayed in my Group Schedule for GroupWise users is as shown in Figure 6.

 


Figure 6: The GroupWise users Free/Busy information seen in Outlook

 

This is an instant visual confirmation that free/busy from Outlook/Exchange to GroupWise is working.

 

Testing in GroupWise

 

The process working the other way is just as simple.

 

From within my GroupWise client I select New Appt as shown in Figure 7.

 


Figure 7: Creating a new appointment in the GroupWise client

 

I then select Busy Search as shown in Figure 8.

 


Figure 8: Making a busy search in the GroupWise client

 

I click Invite to Meeting… as shown in Figure 9.

 


Figure 9: Inviting another user to a meeting in the GroupWise client

 

Finally, I type the name of an Exchange mailbox user as shown in Figure 10 and click OK.

 


Figure 10: Entering the name of the Exchange user to add to the meeting

 

On the GroupWise PO running the API I watch an outbound message followed by the corresponding reply after 5 seconds as shown in Figure 11.

 


Figure 11: The API processing the outbound Free/Busy request

 

Back in my GroupWise client the free/busy Status: changes from Response Pending as shown in Figure 12

 


Figure 12: Free/Busy request pending in the GroupWise client

 

 to Available as shown in Figure 13.

 


Figure 13: Free/Busy request changed to Available in the GroupWise client

 

At this point I can see the busy information displayed in the Individual Schedule Grid as shown in Figure 14.

 


Figure 14: Free/Busy information displayed in the Individual Schedule Grid in the GroupWise client

 

Out of interest, I can look in the \freebusy directory on the Exchange server to find the free/busy request from GroupWise, and I can find the reply in the \togwise directory.

 

The outbound free/busy request from GroupWise:

 

WPC-API= 1.2;
Header-Char= T50;
Msg-Type= SEARCH;
From-Text= Matt Dunkin;
From=
    WPD= DOM1;
WPPO= PO1;
    WPU= Matt;
    FN= Matt;
LN= Dunkin;
S= Dunkin;
G= Matt; ;
To=
    WPD= Exch;
WPPO= First Administrative Group;
 WPU= Flavia;
    WPPONUM= 1;
WPUNUM= 1;
FN= Flavia;
LN= Wright;
UD5= Microsoft Exchange Connector for Novell GroupWise;
S= Wright;
G= Flavia;
CDBA= 0001:0001; ;
All-To=
WPD= Exch;
WPPO= First Administrative Group;
WPU= Flavia;
WPPONUM= 1;
WPUNUM= 1;
FN= Flavia;
LN= Wright;
UD5= Microsoft Exchange Connector for Novell GroupWise;
S= Wright;
G= Flavia; ,
WPD= DOM1;
WPPO= PO1;
WPU= Matt;
WPPONUM= 2;
WPUNUM= 1;
FN= Matt;
LN= Dunkin;
S= Dunkin;
G= Matt; ;
Msg-Id= 47EFC6FC.B99A.04EB.000;
To-Text= Flavia.First Administrative Group.Exch, [email protected];
Subject= BUSY SEARCH: Flavia Wright, Matt Dunkin;
Date-Sent= 30/3/08 17:59;
Security= Normal;
Send-Options= None;
Status-Request= Opened;
Begin-Time= 31/3/08 0:00;
End-Time= 7/4/08 0:00;
Msg-Priority= Normal;
-END-

 

And the corresponding reply from Exchange:

 

WPC-API= 1.2;
MSG-TYPE= Search;
Orig-Msg-ID= 47EFC6FC.B99A.04EB.000;
To=
WPD= DOM1;
WPPO= PO1;
WPU= Matt; ;
Busy-For=
CDBA= 0001:0001; ;
Busy-Report=
Start-Time= 31/3/2008 9:0;
End-Time= 31/3/2008 12:0;,
Start-Time= 31/3/2008 13:0;
End-Time= 31/3/2008 17:0;,
Start-Time= 1/4/2008 14:0;
End-Time= 1/4/2008 16:0;
;
-END-

 

There are several pieces of information contained in the files passed between Exchange and GroupWise worth a mention.

 

Exchange typically requests 60 days of free/busy by default.

 

     Begin-Time= 29/3/2008 18:41;
     End-Time= 28/5/2008 19:41;

 

Whereas GroupWise typically requests only 7 days

 

    Begin-Time= 31/3/08 0:00;
End-Time= 7/4/08 0:00;

 

Also notice that the free/busy request from Exchange is sent by the system attendant

 

    WPU= EXCHANGE2003-SA;

 

This is actually pretty important as the system attendant needs a GWISE proxy address otherwise the process doesn’t work. This is why we suggested in Article 4 that you simply modify the Default Recipient Policy in Exchange, as per Event ID 6001 messages are logged when you use Exchange 2000 Calendar Connector

 

Finally, If you have followed the logging instructions in How to Enable and Increase Logging for Microsoft Exchange Connectivity Controller Connectors and created a \logs directory under \conndata, the log files in this directory should provide even more information for you to delve into and may help in troubleshooting although it is not something we have space to cover further here.

 

Running in Console Mode

 

Having followed all the above you should now have a working system. However, one useful method which enables you to get a more in depth look at what is happening behind the scenes is running the calendar connector in console mode on the Exchange server. This is done by running Calcon.exe from the \Exchsrvr\bin directory.

 

Some key pieces of information to note are as follows

 

[00000D70]: The Calendar Connector will process calendar requests made to the “Schedule+ Free Busy Information – first administrative group” system folder on the following servers : EXCHANGE2003

 

This tells us which free/busy public folder the calendar connector is expecting to use. We need to ensure that the free/busy information for the first administrative group is replicated to EXCHANGE2003

 

[00000D70] (Debug): API_IN Directory is ‘C:\Program files\Exchsrvr\conndata\gwrouter\togwise\’

 

[00000D70] (Debug): API_OUT Directory is ‘C:\Program Files\Exchsrvr\conndata\gwrouter\freebusy\’

 

These two lines confirm the directory associations between \togwise and \API_IN, and between \freebusy  and \API_OUT shown in Figure 2

 

[00000D70]: The Calendar Connector has logged onto the “Schedule+ Free Busy Information – first administrative group” system folder on EXCHANGE2003 to process calendar queries for site first administrative group.

 

[00000D70]: The Calendar Connector has logged onto the “Schedule+ Free Busy Information – first administrative group” system folder on EXCHANGE2003 to submit calendar query responses.

 

These two lines confirm the Calendar Connector has successfully logged in to the Schedule + Free Busy folder for the first administrative group, so submit and process queries for free/busy information.

 

Exchange 2007

 

So how do things change with Exchange 2007? Well, they don’t.  I’ve installed Exchange 2007 into my Exchange 2003 organization. I’ve used a single multi-role Exchange 2007 server, running mailbox, CAS and Hub Transport. Aside from setting up the send connector and installing SP1 it’s out of the box.

 

Note:
Installation of Exchange 2007 is outside the scope of these articles, and is well covered elsewhere on this site.

 

I’ve moved my Exchange 2003 mailboxes using the Move Mailbox… option from the Exchange Management Console.

 

Straight away, message flow both ways continues to work. Free/busy lookup from GroupWise to Exchange also works, but initially free/busy from Exchange to GroupWise doesn’t.

 

I’ve used the following PowerShell commands to add the Exchange 2007 server to the public folders replicas. In the commands below, my Exchange 2003 server name is EXCHANGE2003 and the public folder database on this server is Public Folder Store (EXCHANGE2003)

 

Set-PublicFolder –Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=Company/ou=First Administrative Group” –Replicas “EXCHANEG2003\Public Folder Store (EXCHANGE2003)”

 

Set-PublicFolder –Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)” –Replicas “EXCHANEG2003\Public Folder Store (EXCHANGE2003)”

 

Let me restate that for the record. Free/busy lookup between GroupWise 7 and Exchange 2007, via the Exchange 2003 Calendar Connector now works in both directions!

 

If anybody wants a demo of this, or to talk about it further, drop me a line, I’m only too willing to oblige.

 

So should you do it like this?

 

Having described how to set all this up; for what it’s worth, I’m not convinced this is the right way to go!

 

Let me explain;

 

Each free/busy lookup request is sent individually. I have a Group Schedule with 14 GroupWise mailboxes. When I refresh the free/busy information these 14 mailboxes generate 28 messages between Exchange and GroupWise.

 

Depending on the API Gateway Time Settings specifically the Idle Sleep Duration, as shown in Figure 15, (which can be found under by right clicking the GW2MEX Gateway object in NetWare Administrator and selecting Details…) each of these free/busy conversations can take anything from 10 to 15 seconds. For 14 mailboxes, the refresh of free/busy information takes in the region of 2 minutes. This isn’t viable for a large scale migration in my opinion. 

 


Figure 15: The API Gateway Idle Sleep Duration setting

 

Summary

 

So in summary, we have demonstrated that it is possible to get Free/busy information to pass between GroupWise and Exchange, but we strongly suggest that you use or rely on it as little as possible. It is clearly a process which does not scale well and equally is also rather prone to suddenly breaking, which can require the restart of the connectors to fix. All in all, migrate departments or teams that are likely to share free/busy at the same time and try and keep the whole co-existence period as short as possible!

 

In the next article we move on to cover migration itself!

 

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