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:

1. Create an NT account named Anonymous or something similar. Give the account a password, and set the password options so that the password never expires and users can't change it.
2. Depending on how you've configured your server, creating an account might automatically create an Exchange mailbox. If not, create a new Exchange mailbox for the new NT account.
3. Use the Internet Service Manager (ISM) to turn on anonymous access for the new account you just created.

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:

1. Open the Microsoft Exchange Administrator program, and navigate to the OWA server.
2. Select the server, and use the File, Properties command to open its Properties sheet.
3. Switch to the Diagnostics Logging tab, then select MSExchangeDS from the list of components.
4. Set the logging level for Security, ExDS Interface, MAPI Interface, Directory Access, LDAP Interface, and Name Resolution to maximum.
5. Expand the MSExchangeIS item in the component list.
6. Select the System item under MSExchangeIS, then set the logging level for Connections and General to maximum.
7. Select the Private item under MSExchangeIS, then set the logging level for General and Logons to maximum.
8. Stop and restart the IS.

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:

1. Use a command-line mail-sending tool such as Postie (http://www.infradig.com), Blat (http://www.interlog.com/~tcharron/blat.html), or Sendmail (included in the Microsoft BackOffice Resource Kit—BORK) to send mail from a script, batch file, or application.
2. Use the socket functions in the Perl scripting language to write a mail sender.
3. Write code (in Visual Basic—VB—or Visual C++—VC++), and use the Messaging API (MAPI) or Extended MAPI routines. Outlook uses this method, which is essentially the equivalent of using Postie or Blat.
4. Create a properly formatted RFC 822 message, and put it in the imcdata\pickup directory. The IMS will notice the message and send it as though the IMS received it by way of SMTP. Listing 1 shows an example message; note that the only blank line appears between the Subject header line and the message body.

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:

1. Start your client software in offline mode.
2. Add a PST service with the Tools, Services menu (or the equivalent menu, if you're using Outlook 2000).
3. Select the messages you want to save, then use the File, Copy command to move them to the .pst file.
4. Repeat step 3 for each folder that has data you want to save.

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.

1. Run Exchange Administrator with the /r command-line switch to turn on raw mode.
2. Find the offending mailbox, then use the File, Raw Properties command to open its raw-mode Properties dialog box.
3. Select the Home-MTA attribute from the Object Attributes drop-down menu.
4. In the Value box, remove the source server's name and enter the name of the correct target server.
5. Click OK, then click Set. Click OK again to close the Raw Properties dialog box.
6. Repeat steps 2 through 5, but this time use the Home-MDB attribute in step 3. (Thanks to reader Vic Young for this question.)

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.