The Exchange Server Troubleshooter - 03 Feb 2000

How can I set up an Exchange server to allow anonymous access to a mailbox?

Sometimes, you want to set up a mailbox to let anonymous Web users send or receive mail. Most often, you want to allow anonymous access so that your Web applications can use Exchange to send mail, without requiring Web users to have a Windows NT account in your domain. The basic steps are fairly simple:

The Microsoft article "HOWTO: Configure an Exchange Mailbox for Anonymous Access" (http://support.microsoft.com/ support/kb/articles/q195/6/81.asp) covers the steps in more detail.

How can I monitor Outlook Web Access (OWA) activity?

For most Exchange components, you can turn on diagnostic logging by using the Diagnostic Logging tab in the component's Properties sheet. However, because OWA isn't technically an Exchange component, OWA doesn't expose an external interface that you can use to log OWA-related events. However, if you know the types of events OWA generates, you can turn on logging for the Directory and Information Store (IS) services, then look for the kinds of events OWA generates.

To get a picture of what OWA is doing, you must first turn on some particular logging categories. Follow these steps:

When you set these logging categories, you see six or seven events in the log each time an OWA user logs on. You usually see event IDs 1170, 1136, 1137, 1007, and 1009, and you might see more than one of each. These events tell you who logged on and when. The Microsoft article "XWEB: Diagnostic Logging Levels for OWA Defined in the Exchange Administrator Program" (http://support.microsoft.com/ support/kb/articles/q246/2/48.asp) contains details about the pertinent events.

How can I see how many messages are in the queue of an X.400 connector?

The Exchange Internet Mail Service (IMS) has a Queues tab, so you can see how many items are in each queue. However, the X.400 connector doesn't have a Queues tab. You can still see how many messages are in the queue by taking an alternative route—the Queues tab on the Message Transfer Agent (MTA) Properties sheet for the server hosting the X.400 connector. Open the MTA Properties page, switch to the Queues tab, and use the Queue Name drop-down menu to select the X.400 connection. When you select the connection, you'll see a count of messages in the queue.

The IMS and X.400 connectors have different characteristics because of their ancestry. Microsoft integrated the X.400 and Site connectors tightly with the MTA, and the MTA maintains their queues. To build external connectors such as the IMS, Microsoft used a set of programming interfaces that it provides for external gateways. These connectors must maintain their external queues.

Sometimes we get incoming messages that don't appear to be addressed to anyone in our domain. This problem often happens to my boss, who now thinks our Exchange server is misconfigured. Why are we getting those messages if they aren't for us?

Reader Mary Curto submitted this question and some example messages. Not surprisingly, the messages all turned out to be unsolicited commercial email (UCE). The answer lies in an often-misunderstood feature of Internet mail: the blind carbon copy (Bcc) address field. The Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 specifies how users can address SMTP mail and defines what happens when someone addresses a message to a Bcc recipient.

An example illustrates the mechanism. Let's say that I send a message to Bill at [email protected] and send a copy to Scott at [email protected]. Bill and Scott will each see that the other is a recipient of the message. If I send the same message again, addressing it to Bill and sending a blind copy to Scott, Bill will see only my address (as the sender). Scott will see me as the sender and Bill as a primary recipient, but none of the other recipients in the Bcc field.

You're getting these messages because malicious users often send mail to a bogus address, then load up the Bcc field with the intended recipients—one of whom happens to be your boss. You can't do much about it except to block the problem domains (an unlikely solution, because so much UCE originates from legitimate servers that you might not want to block) or educate your users about UCE and methods for complaining directly to its originators. For more information about dealing with UCE, see Mark Howard, "Coping with Unsolicited Email" (October 1999) and Joseph Neubauer, "Is Your Exchange Server Relay-Secure?" (January 2000).

I'm installing an Exchange solution for an organization that wants to use a fairly flaky satellite connection to link all its ships with Exchange. What's the best way to do this?

My impulse is to say, "Get a less flaky satellite connection," but that suggestion probably won't help much. Satellite channels have a lot of latency because any signal has to travel to geosynchronous Earth orbit (GEO) and back again—a round trip that takes at least 0.25 seconds. That amount of latency is too much for the Site connector, and you'll probably need to make some adjustments to your servers' TCP/IP parameters to allow for the increased latency. (The IETF is working on a variant of TCP/IP that scientists can use to communicate with interplanetary spacecraft!)

However, if you must use a satellite connection, the X.400 connector is probably your best choice for connecting the servers. The X.400 works well on connections with a great deal of latency or high error rates. You can also schedule X.400 connectors to take advantage of off-peak rates. After you configure an X.400 connector, you can leave it alone—X.400 connectors tend to be robust in day-to-day operation. However, you must have the Enterprise edition of Exchange Server to get X.400 connectors, so you might be facing a substantial upgrade cost. (Thanks to reader Ryan Mullinax for this question.)

I need to send mail from an Oracle application through Exchange Server. The Oracle application decides which messages to send and when, but I want to hand the messages off to Exchange for delivery. How can I accomplish this setup?

You can send mail through Exchange from external programs in several ways. The method you use depends on how much programming you want to do and exactly how you're generating the messages you want to send. Here are a few of the ways you can hand mail off to Exchange for further processing:

If you want to create Internet mail protocols, check out John Rhoton's Programmer's Guide to Internet Mail (Butterworth-Heinemann, 1998). The book has a ton of VB code for creating and sending SMTP messages. Using SMTP instead of MAPI lets you guard against the day MAPI isn't available on your network.

An administrator in our company accidentally deleted a user's mailbox from the server. We don't have a good backup, but we do have a usable offline storage (.ost) file. Can we recover the mailbox contents?

You can recover the mailbox contents in certain circumstances. An Outlook .ost file is a replica of the contents of a server-based mailbox. When something bad happens to the server mailbox, the replica no longer has a parent; Microsoft refers to this .ost file as an orphan. The key to being able to recover the contents of an orphaned .ost file is the MAPI profile that you use to log on to the server. When you log on to a server mailbox, Exchange sends an encrypted token to the client, which stores the token in the profile. When you're working offline, the client checks your profile for the existence of the token before it gives you access to the .ost file.

The result of this procedure is that if you modify the profile associated with an .ost file and a mailbox—by deleting it or using it to log on to another Exchange mailbox—the necessary token won't be there and you won't be able to recover the mailbox data. Conversely, as long as you leave the profile alone, you can use it to open the .ost file and export its mail to a Personal Folders (.pst) file by executing the following steps:

After you've exported the mail to a .pst file, you can recreate the mailbox on the server and use the .pst file to repopulate it.

How do I stop users from sending useless large attachments such as elfbowling.exe? I know I can set the maximum message size in the IMS service, but can I filter by file type or look for particular filenames in the attachments?

You can't perform the kind of filtering you want with the tools you get on the Exchange Server CD-ROM. Administrators ask this question frequently because many administrators would like nothing more than to rid their networks of elf bowling, dancing babies, Moving Pictures Experts Group (MPEG) movies of various kinds, and other mail detritus that clogs their servers. Third-party products are your only hope (apart from educating your users, which is probably not going to work very well). I've recently been evaluating C2C Systems' Active Folders (http://www.c2c.com), which is essentially a search engine for the public and private IS databases. This product lets you perform tasks such as removing all .exe attachments and flagging any mailbox that has attachments older than 18 months. Although Active Folders is a cool product, it doesn't help you keep the junk off your server in the first place. To block mail, you need a content inspection package such as Content Technologies' MAILsweeper (http://www.contenttechnologies.com) or GFI FAX & VOICE's Mail essentials for Exchange/SMTP (http://www.gfifax.com/me/mailessentials.htm). These packages usually run on your external IMS (or on a separate SMTP-only server outside your firewall), so they can block incoming content before it gets to your Exchange server. (Thanks to reader Doug Buttry for this question.)

I moved some mailboxes between two servers in a site. After the move, the mailbox shows up on its new home server, but the client can't connect to it, and two entries for the mailbox appear in the Global Address List (GAL). What happened, and how do I fix it?

The Tools, Move Mailbox command is a straightforward way to move mailboxes between servers in a single site. The command automates the process of creating a new recipient on the target server and moving messages between the old and new mailboxes. However, like many other automated systems, sometimes it fails to work properly. In this case, the problem becomes apparent when the Exchange Administrator application fails to update the Home-MDB and Home-MTA attributes for the mailbox's directory entry. The program moves the mail correctly and properly updates the private IS databases of both the source and target servers, but it doesn't update the directory.

To fix this problem, you can use Exchange Administrator's raw mode. As always, be careful when using raw mode because indiscriminate editing can damage your directory data. As a further safeguard, don't attempt this repair until you've made a good online backup of your Exchange databases.

Several users have asked me to set up mailboxes to send a standard autoreply message to every message the mailbox receives. Can I use an Exchange server-based process?

You can't use an Exchange server-based process directly. An automatic autoresponder would be a useful feature, and it would probably take the talents on the Exchange development team about a day to use existing out-of-office functionality to implement it. In the interim, though, you're right to point out that a client-side rule will do the trick. Your best bet is probably to write an event script that would run on the server and fire whenever a new message arrives in a public folder or mailbox. (Thanks to reader Robert Marshall for the question.)

What's the accepted best practice for installing an Exchange service pack.?

My recommendation is usually to install service packs in chronological order. For example, I just came from a customer site, where I brought up a new box that had Windows NT 4.0 Service Pack 4 (SP4) on it when I got there. I installed the NT 4.0 Option Pack, then reinstalled SP4 as the Option Pack documentation requires. Then, I installed Exchange Server 5.5 and its SP3; I finished with NT SP6a, which Microsoft released in late November 1999.

However, after you've figured out what order to install the service packs in, how can you minimize problems with the installation of an Exchange service pack? My usual modus operandi is to manually stop all the Exchange services, use the Control Panel Services applet to set their startup type to manual, and reboot. After the reboot, I run the service pack installer. Stopping the Exchange services beforehand ensures that the services don't have any files locked and that no monitors are running to restart services at a potentially inconvenient time. When the service pack install finishes, I can reset the services to start automatically and reboot again.

Of course, an excellent practice is to make a complete online backup before you install a service pack, just to be safe.