Administering Exchange Server in a Cross-Platform Environment

If you needed to set up a mail system on a new network, you'd probably use Exchange Server 2003 as the mail server and Microsoft Outlook for the mail clients. However, most Exchange administrators don't have the luxury of starting from scratch. Instead, they often must support several types of mail servers and various client OSs. Even if you have a pure Exchange and Outlook setup now, your company could merge with another organization and force you to manage a mixed environment that includes non-Microsoft email client and server platforms. Administering cross-platform mail systems is complicated. I can't cover all the possible environment variations in one article, but I'll give you guidelines for support options in a few specific situations.

First Things First
If you must manage a cross-platform mail system, the first thing you need to do is take inventory. You can use a tool such as Microsoft Systems Management Server (SMS) or Alchemy Lab's Assets Tracker for Networks to help you do so. You need to determine each mail server's OS and hardware capabilities, as well as applications that are running on the server. Taking inventory will help you spot potential problems in cross-platform administration. For example, suppose your company merged with another organization and the new organization's mail servers were running low on disk space. You'd need to correct such a problem before you could develop a workable coexistence strategy.

Taking a workstation inventory is as important as conducting a server inventory. You don't necessarily need to take a physical inventory (i.e., record each workstation's serial number). However, you need to determine at minimum what OS and mail client each workstation is running. (For more information about using a script to determine the OS that a system is running, see "How can I use a script to determine a machine's OS version?" John Savill's FAQ for Windows, June 2005, InstantDoc ID 46759.)

Connecting Mail Servers
Whether your goal is eventual mailbox migration or long-term coexistence of two mail systems, you need to connect the mail systems by using an internal mail-routing mechanism and a shared global address book. Connecting two mail systems lets users on one system more easily communicate with users on another system because of the shared address book. The method you use to connect two mail systems depends on the type of foreign mail system in use.

Exchange Server offers connectors for Lotus Notes and Novell GroupWise that support full directory synchronization, with some scalability-related limitations. (For more information about these connectors, see the Microsoft Exchange Server 2003 Connector for Lotus Notes page at http://www.microsoft.com/down loads/details.aspx?familyid=d9f3a35e-1046-47b5-b09b-bda9de60cd9d &displaylang=en and "Introduction to Microsoft Exchange Server 2003 GroupWise Connector" at http://www.microsoft.com/technet/prodtechnol/exchange/2003/insider/groupwise.mspx#whatistheexchangenovellgroupwise.) Likewise, Exchange offers SMTP and X.400 connectors that you can use to link an Exchange server to a foreign mail system. (Exchange 2003 and Exchange 2000 Server include an SMTP connector; the SMTP connector is an add-on to Exchange Server 5.5. Exchange Server 2003, Enterprise Edition, Exchange 2000 Enterprise Server, and Exchange 5.5, Enterprise Edition include an X.400 connector.) Technically, Exchange's SMTP and X.400 connectors don't support directory synchronization, but you can use them with Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS) or a similar product to establish a message-transport path between the two systems. (For more information about these connectors, see the Windows IT Pro article "Making the Connection," September 2001, InstantDoc ID 21868.)

Creating a Custom Address Book
Sometimes Exchange must coexist with a foreign mail system when no direct directory-synchronization method exists. In such situations, I build a custom address list that Exchange users on the local network can use to communicate with users on the foreign mail system. Building a custom address list is preferable to simply using Global Address List (GAL) entries because a custom list lets you more easily organize users by location.

You can use several methods to implement this solution. The method I use is to first create a dedicated organizational unit (OU) in Active Directory (AD) to store the contacts for the foreign mail system. You don't need to create user accounts in the new OU because users on the foreign mail system don't need access to your forest. Instead, you can create contacts for those users. To do so, simply right-click the OU you created and select New, Contact from the shortcut menu. Then, enter the user's name and click Next. In the following screen, which Figure 1 shows, select the check box to create an Exchange email address for the contact, and click Modify. Then, select the address type currently in use ( typically SMTP) and click OK. Next, enter the user's existing email address in the email address field and click OK, Next, Finish. Follow these steps for each contact you want to create.

I also recommend that you set an AD attribute on each contact to designate the contact as remote. For example, suppose your company's newly acquired satellite office is in Miami. When you create contacts for each user on the Miami mail server, set the City attribute to Miami. This attribute is on the contact's properties sheet's Address tab, which Figure 2 shows. Another useful attribute to set is the Telephone Number attribute on the properties sheet's General tab. Setting this attribute lets you store the contact's phone number within AD.

After you create contacts for each user in the remote office, you must assign those contacts to a dedicated address list. In my example, in which all the foreign mail-system users are in Miami, I'd create an address list named Miami. To create an address list, open Exchange System Manager (ESM) and navigate through the console tree to Recipients, All Address Lists. Then, right-click the All Address Lists container and select New, Address List from the shortcut menu. Enter a name for the new address list (e.g., Miami), and click Filter Rules. ESM will then display the Find Exchange Recipients properties sheet.

On the properties sheet's General tab, select only the Users with Exchange mailbox and Users with external e-mail addresses check boxes. Click the Advanced tab and select the Field drop-down list. From this list, select Contact, Office Location. As Figure 3 shows, set the Condition option to Is (exactly), and set the Value option to match the value that's assigned to the Office Location attribute for which you're creating the address list (e.g., Miami). Click the Add and Find Now buttons, and you'll see a list of everyone in your remote office. Click OK, then Finish to complete creating the address list of remote-office users.

POP Server Configuration
Although Exchange offers SMTP and X.400 connectivity and has built-in connectors for IBM Lotus Notes and Novell GroupWise, sometimes none of these solutions is viable. My situation is a prime example. I live in rural South Carolina, and my local ISP has a monopoly on Internet, cable television, and telephone communications. My ISP has spotty reliability and furthermore won't issue me a static IP address. Therefore, I use an ISP in another state to host my Web site and email. However, the nature of my business requires me to use Exchange Server–based email.

I can't set up a traditional type of connector between my Exchange server and the ISP that hosts my email. However, my ISP supports SMTP and POP3 email—which Exchange also supports. I therefore used GFI Software's GFiMailEssentials POP2Exchange component to map Exchange mailboxes on my Exchange mail server to an SMTP mailbox on my ISP's server. GFiMailEssentials checks each of my mailboxes on my ISP's server every two minutes for new messages. If a mailbox contains new messages, GFiMailEssentials uses a POP client to download the messages to my Exchange server. Then, GFiMailEssentials uses the message header to determine which of my Exchange mailboxes to put messages in. I can then use Outlook to access mail directly from the Exchange server. I use the GFiMailEssentials POP2Exchange component rather than Exchange's TURN or extended TURN (ETRN) functionality because POP2Exchange is easier to configure. (For more information about using the SMTP TURN and ETRN commands, see the Web-exclusive article "Keep Your SMTPMail Flowing," September 2002, InstantDoc ID 26659.)

The configuration I use wouldn't be practical for a large network, but it works on a small scale. Although I use POP2Exchange to retrieve messages from my ISP, you could use a similar technique to connect to a POP3 mail server.

Workstation Setup
After you configure your server, you need to set up your workstations. First, determine whether your company will let you connect the workstations that are currently connected to the foreign mail server to your Exchange server instead. Connecting the workstations to your Exchange server is preferable because doing so simplifies administration—at least after you migrate content from the foreign mail system to your Exchange server. If your company won't let you connect the remote workstations to your Exchange server, you don't need a coexistence strategy for the workstations. But if you can connect the workstations to your Exchange server, you need to consider your client options.

In an ideal situation, each workstation that you wanted to connect would be running Windows XP, and you could simply install Outlook (which requires XP or Windows 2000 with Service Pack 3—SP3—or later). But reality is rarely so simple. For example, the workstations might be running Windows 95 and lack the system resources to accommodate XP or Outlook. Worse yet, the workstations might be Macintosh machines, or they might be running Linux or UNIX. Fortunately, you have connectivity options even in these problematic situations.

Legacy Windows systems. If the workstations you want to connect are old and are running an outdated version of Windows, the best solution is to replace the systems. Running old versions of Windows is a security risk, so ideally you'd install XP with SP2. However, time and budget constraints might prevent you from replacing legacy systems and software. If so, you might want to consider setting the machines up as Windows Server 2003 Terminal Services clients.

An advantage of this solution is that the old computers can act as thin clients, running only Windows and the Terminal Services client application, which uses few system resources. Your Terminal Services server runs applications on behalf of the workstations and simply transmits screen images to the workstations. Thus, even employees using outdated workstations can run Microsoft Office and can access their Exchange Server mailboxes through Outlook.

This approach does have drawbacks. If you don't already have a Terminal Services server in place, you must buy one. In addition, you need Terminal Server Client Access Licenses (TSCALs) for all the remote workstations. You might be able to justify this cost depending on how many workstations you need to connect. However, before you spend money on a Terminal Services server or TSCALs, you need to consider the legacy systems' reliability. If the workstations are running on ancient hardware, they might not run long enough for you to invest the money.

Macintosh workstations. Don't despair if the remote workstations you need to connect to your Exchange server are Macs. Throwing your hands in the air and telling your boss you don't know anything about Macs might seem like an easy solution, but connecting a Mac to Exchange is actually fairly simple.

Microsoft offers a version of Office for Mac. The current version ( Microsoft Office 2004 for Mac) doesn't include Outlook. Instead, this version of Office includes Microsoft Entourage 2004 for Mac, which is similar to Outlook and fully supports Exchange Server connectivity. For more information about Entourage, go to the Microsoft Mactopia Entourage Web site at http://www.microsoft.com/mac/products/entourage2004/entourage2004.aspx?pid=en tourage2004.

Other types of workstations. Windows and Mac might be the most prevalent OSs, but they aren't the only ones you could encounter when trying to connect remote workstations to your Exchange server. For example, many workstations run Linux or UNIX. If you can't directly connect such workstations to your Exchange server, you can use Microsoft Outlook Web Access (OWA) to give users access to their Exchange mailboxes. In general, any machine that has an up-to-date Web browser can access Exchange through OWA. This solution is also viable if your remote workstations are running an old version of Windows, and Terminal Services isn't an option.

Find What Works for You
Administering a multiplatform Exchange environment is rarely simple. However, as I've shown you, several options are available to help your Exchange environment coexist with another mail platform. Use the methods I've described as a guide to craft a cross-platform solution that meets your particular requirements.