Windows Foundation

Get the Message

Straight talk on meshing your enterprise e-mail systems.

• By Bill Heldman
• 07/01/2003

In my younger days, I was hired to migrate 800 or so users off of Banyan Vines to Windows NT 4.0. Additionally, I was tasked with setting up an Exchange 4.0 server with the same goal of taking users from Banyan’s e-mail system to Exchange. I successfully set up the e-mail server and we utilized a special but expensive third-party product to migrate users (a few at a time) off of Vines to Exchange. In the interim—for those that weren’t yet converted—our “connector” to the two systems was simple SMTP e-mail through the Internet.

But what if you want to convert lots of users off of different disparate systems? Wouldn’t it be easier if Microsoft provided a way so that you could simply connect up to the foreign system and get e-mail going between the two? Good news—they have!

If you work in a large environment, one that has a lot of geographically or functionally dispersed areas, you might have a two or three different e-mail server technologies to deal with. This can be a bugaboo for you in an Exchange 2000 migration, never mind the potential hassles that you have to go through with an Exchange 5.5 to E2K upgrade.

In the Exchange world it’s important to remember that you have two separate pieces of information you have to be concerned about: the actual mailbox data as well as the calendar data—the so-called “free and busy times.” Other enterprise e-mail systems may not segment the notion of mail versus schedule as does Exchange, but they may include scheduling capabilities for e-mail users. So it’s important to understand not only how you’re going to get your users to access their inboxes, but also how they’ll share free/busy times, if at all. The sharing of free/busy times allows users to see one another’s schedules and to create appointments accordingly.

Connecting Exchange 5.5 and Groupwise
The primary idea behind connecting two or more e-mail services together is so that all users share the same primary list of users in the corporate e-mail address book. In Exchange the corporate book is called the Global Address List (GAL) and represents the list of users, groups (called "distribution lists" in Exchange 5.5) and non-Exchange recipients (called "custom recipients"). The idea is to allow your disparate e-mail systems to co-exist, so that directory information can be shared. This co-existence might be short-term as you migrate users off of the old e-mail system to the new, or long-term. For example, suppose that you have an autonomous division in your company that exclusively utilizes Netware for its server OS and Groupwise for its e-mail server product, but the rest of the company uses Exchange 5.5 Server. In this case you may need a way to have the e-mail systems coexist permanently. Optionally, if a new CIO comes on board and says “Everyone will use Exchange Server” then you’ll be faced with a Groupwise to Exchange migration.

In the case of Exchange 5.5 and Groupwise 4.x or 5.x (not 6.x) you have several options available to you after Exchange 5.5 with Service Pack 3:

• Microsoft Exchange Connector for Groupwise—Allows you to connect with a Groupwise server; supports message transfer and directory synchronization.
• Microsoft Exchange Server Migration Wizard—Allows you to move users off of Groupwise and onto Exchange.
• Microsoft Exchange Calendar Connector—Provides near-real-time access to free/busy calendar information from each system.

By directory synchronization (dirsync) we mean the information about the users in each system. Exchange first updates Groupwise by converting its entries into Groupwise format. It then retrieves the Groupwise directory information and populates it in Exchange. Thus the two systems are synchronized with one another. The Exchange connector on the Exchange server uses the Groupwise API Gateway on the Groupwise server to accomplish this goal. Here’s the rub: This is a scheduled dirsync and doesn’t happen synchronously (i.e. all the time). You must set a schedule whereby dirsync happens. There is quite a bit of granularity available with this schedule, so don’t fret that you’ll be limited to a once a week dirsync between the two servers.

You have some controls over how you implement this Exchange 5.5/Groupwise directory synchronization process:

• You can create containers that house specific Exchange recipients and export only those containers to Groupwise.
• You can set a trust level so that certain Exchange recipients (such as the Exchange admin account, for example) are not synchronized.
• You can opt to not synchronize recipients such as custom recipients.
• You can decide whether to import/export distribution lists (DLs). (In Groupwise 4.x, DLs were called groups whereas in Groupwise 5.x they’re called Groupwise Distribution Lists and appear in Exchange 5.5 as custom recipients).
• Schema attributes are mapped accordingly. For example, the field company in Groupwise will match to the field company in Exchange 5.5.

When a user composes an e-mail and sends it to a Groupwise user, the Exchange connector sends it to the Groupwise API Gateway which in turn converts the message into the normal Groupwise message format. The Groupwise Mail Transfer Agent (MTA) then delivers it to the Groupwise recipient. The opposite is true for a Groupwise recipient sending an email to an Exchange 5.5 user.

The Exchange Calendar Connector uses a free/busy public folder to post the free/busy information of the Groupwise server, according to the dirsync schedule set up by the administrator. If an Exchange user requests free/busy information from a Groupwise user, the public folder is first queried. If no information is found, a request for that information is sent by the Exchange Connector for Groupwise to the Groupwise system.

You use the Exchange Migration Wizard when you want to move users from the Groupwise server to the Exchange 5.5 server. Depending on the size of the organization, you can opt to perform a one-step migration that moves everyone or you can perform two-step migrations in which you move small groups at a time.

Connecting Between Exchange 2000 and Groupwise
The process differs only slightly with Exchange 2000 in that Microsoft provides another utility, called the Active Directory Account Cleanup Wizard, to make it easier to copy Groupwise information into the Exchange system, either through a migration or a connector effort, that is mapped to the appropriate Active Directory account. All utilities are available on the Exchange 2000 CD (with no service packs), however Exchange 2000 with SP1 is required for free/busy information.

Before we move on, here are some problems to keep in mind for Exchange 5.5 and Exchange 2000 servers connected with Groupwise 4.x or 5.x:

• Recurring appointments cannot be sent from Exchange to Groupwise. The user receiving the appointment sees a note at the top of the appointment that it is recurring and it is left up to him to manually key in the other entries.
• You cannot query free/busy information for distribution lists on the Groupwise server.
• The Exchange Connector for Groupwise does not support Exchange messages that are signed and encrypted.

Connecting Exchange and Lotus Notes/Domino
But suppose instead that you have a complicated groupware implementation in which you not only have a messaging system, but you’ve got applications developed around that system that you want to connect to with Exchange. Now you’ve got your hands more full because you have to concentrate on the various documents that were created in the Notes/Domino system and somehow link them so that they’re delivered to the Exchange user in a meaningful way.

Exchange 5.5 SP4 provides a Lotus Notes Connector that does exactly that. It utilizes a Notes feature called DocLink, to allow Exchange users to receive via .RTF or OLE object attachments (and from Domino, hyperlink attachments) in order to interact with the Notes system. Depending on how the Exchange administrator has configured the Lotus Notes Connector, the user will receive one of three attachments:

• A rich-text (.RTF) file that the user can open via any RTF-compatible word processor.
• An OLE object to click on. For this to work, users must have the Notes 4.52 client application installed on their desktop. When the user launches the OLE object, the Notes application is launched and the user sees the Notes document.
• In the case of Domino server, which has an embedded HTTP server mechanism, the user can receive a hyperlink, pointing back to the Domino server.

The Notes connector allows for either a complete dirsync, or a dirsync of the deltas (only the changes) that have occurred to either system. Also, Notes groups and Exchange DLs are maintained. The connector does not maintain some Notes elements: mood stamps, bullets, numbering, tables, collapsible sections and encryption.

There are four Notes implementation scenarios:

• Departmental connection—Single Exchange site to single Notes domain
• Downstream sites/domains—Multiple Exchange sites to multiple Notes domains
• Shared Internet-Access—Utilizing Exchange’s Internet Mail Server (IMS) technology so that Notes users can make use of its functionality (along with the regular Notes connector)
• Message-switch—This very exotic implementation scenario utilizes the Notes connector and the IMS for Notes clients, as well as the Exchange connector for an IBM e-mail product called OfficeVision. This scenario is dubbed message-switch because the message can traverse one of three systems.

In the Exchange 2000 environment, you use not only the Connector for Lotus notes but you’re given more robust tools to facilitate a better client experience:

• Microsoft Exchange Analyzer for Lotus Notes—Allows the administrator to examine what Notes applications are running in the environment.
• Microsoft Exchange Application Converter for Lotus Notes—Allows administrators to connect to the Notes applications and convert them for use by Microsoft Outlook.

For the world’s dominant e-mail systems, there has probably been a connector written for Exchange so that you can connect to the system and, if so inclined, allow migrations off of it. I don’t pretend to underplay the many challenges with installing, configuring and getting the connectors running. (See www.microsoft.com/exchange for more information on connectors.) Nonetheless, the technology is there for you if you want your disparate e-mail systems to coexist and, thus, allow users on any system to happily trade e-mail one with another.