Exchange Server Troubleshooter - 01 Dec 1998

I'm retiring an old Exchange Server computer. I know how to use Setup to remove Exchange, but what else can I do to clean up the machine?

You can reformat the disk and reinstall Windows NT, but that's overkill for most installations. Even if Setup cleanly completes the uninstall process, you might still need to remove several components:

  • The exchsrvr directory and its subdirectories might still exist; you can safely remove them after the uninstall completes.
  • The setup.log file contains information about the previous Exchange Server install and remove operations. You won't need that file any longer, so you can remove it, too.
  • Orphaned Registry keys might remain after you've removed Exchange Server. You can remove these keys if you want, but leaving them in place is harmless. The following are keys to remove: ESE97, EDB, or anything starting with MSExchange beneath the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key and the EDB, ESE97, and Exchange keys in HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft.

How do I configure Exchange Server so that messages that the System Attendant sends appear to be from the postmaster account?

When the System Attendant or another Exchange Server component needs to communicate with you or another user, the component usually sends mail from an account named System Administrator. Oddly, that account doesn't exist, and its address is a special type—SYSTEM. If users reply to the mail without realizing that Exchange Server has generated the message automatically, their mail will bounce, because no System Administrator address exists. You can easily add this pseudoaccount to any existing account, such as your postmaster or administrator account (or even your helpdesk account, if you're feeling frisky). That way, when people respond to automatically generated messages, the responses will end up in your Inbox instead of generating a nondelivery receipt (NDR) to the sender. Here's what to do:

  1. Select the account you want to appear as the originator of system messages.
  2. Open the account's properties dialog box; on the E-Mail Addresses tab, click New.
  3. In the New E-Mail Address dialog box, specify the address type as Other Address, and type System Administrator as the email address. In the address type field, type SYSTEM.
  4. Click OK twice.

Now, replies to system-generated messages will go where you specify. You can change this behavior by removing the pseudoaccount address from one mailbox and adding it to another. Just don't try to apply System Administrator as an additional address on more than one mailbox—if you do, mail routing won't work the way you expect.

I want to move some Macintosh users from their existing mail system to the Exchange Server computer. Where can I find the Macintosh Exchange or Outlook clients?

Using the Mac with Exchange Server presents good news and bad news. First, the good news: Mac versions of the Outlook and Exchange clients exist. The bad news is that they're large, slow, and feature-poor. The Mac Outlook client is the older Exchange client with a new user interface and a few new features tossed in. However, the Mac Outlook client has four serious limitations:

  • MacOS 8.x doesn't support the original Outlook client. According to the Exchange Server 5.5 Service Pack 1 (SP1) release notes, the Outlook client in SP1 supports MacOS 8.0 and 8.1. However, the jury's still out on whether Outlook works with MacOS 8.5, which Apple released after SP1.
  • The Outlook client can't view Outlook 97/98 calendar details, only the older Schedule+ format. (It can, however, see free/busy information from Outlook users.)
  • The Outlook client doesn't support deleted item retention, one of the best new features in Exchange Server 5.5.
  • You can't move .pst, .ost, .pab, or Advanced Security files between Macs and Windows machines.

Microsoft calls the Mac and Windows 3.1 clients "stepping stones" for people who are migrating to the Win32 family, so don't expect Microsoft to resolve these problems.

An alternative to using Outlook is to use a better mail client. Microsoft has done a good job with the Mac version of Outlook Express—it's fast, flexible, well featured, and free. You can also use Outlook Web Access (OWA) only for its calendaring features or as your primary mail interface. Of course, you can also use any other Post Office Protocol 3 (POP3) or Internet Message Access Protocol 4 (IMAP4) Revision 1 client, including the excellent Mac versions of Eudora Pro (versions 4.1 and later support IMAP) or Netscape Messenger.

If you insist on using the Outlook client, you can obtain it from the Outlook 97 CD-ROM included in your Exchange Server package. The trick is that the CD-ROM has both Mac and Windows partitions on it—you'll see the Mac partition only if you mount the CD-ROM on a Mac. You can obtain the SP1 Outlook client from the SP1 CD-ROM or as a 23MB download from ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg5.5/Sp1/Mac/SP1_55MA.hqx. I recommend the SP1 Outlook client, because it includes bug fixes that make it work properly under MacOS 8.0 and 8.1. The SP1 client supports both Power Macintosh and older 680 * 0 processor Macs; the original client supported only Power Macs.

How do the methods for queuing mail for later delivery differ?

You can queue mail for later delivery in two ways. Most people schedule message delivery through the message properties sheet. From File, Properties, click Send Options. Go to the Microsoft Exchange Server tab to specify the time you want the mail to go out. With this method, the mail sits in the sender's Outbox until the appointed time. When that time arrives, the mail goes out, regardless of whether Outlook is running. This method is nice because you can always change your mind and stop the message by deleting it from the Outbox.

The second method has the same result—delayed delivery—but the intermediate behavior is different. On the Options tab of the message composition window in Outlook 97 or the View, Options dialog box in Outlook 98, specify a time in the Do not deliver before delivery option. If you use this option, Outlook doesn't queue the message on your machine but sends the message to your home server's Message Transfer Agent (MTA), which adds it to the MTA's work queue. Because this queue is invisible, you can't find or recall your message after it hits the MTA—so be careful with this feature. If you're using Exchange Server 5.5, you can use the Work Queue Length counter for the MSExchangeMTA object in Performance Monitor to monitor the work queue length; this counter tells you how many—but not which—deferred messages are waiting for their delivery time to arrive. You can also check the application log in Event Viewer; the MTA logs event ID 275 when it processes a deferred message.

I moved a batch of mailboxes from one server to another, but the mailboxes still show up in the original server's Mailbox Resources view. What's going on?

Mailboxes appear in the server's Mailbox Resources view after you've moved them because the original server's Private Information Store (IS) still thinks the mailboxes are there. This problem can occur when the postmove cleanup code doesn't correctly delete all the objects associated with a mailbox. It can also happen if the move fails.

The fix is simple, but counterintuitive. You might think you need to delete the objects, but you don't. Instead, you need to open an Exchange Administrator window to the server you moved the mailboxes to. Select each mailbox, and use Tools, Move Mailbox to tell Exchange Administrator to move the mailbox back to the original server. When you get an error message, just ignore it. Exchange Server won't move the mailbox, but the original server's ghost objects will disappear.

The biggest drawback to this procedure is that you need to repeat it for each stranded mailbox. The Microsoft article "XADM: Removing Stranded Mailboxes in Mailbox Resources" (http://support.microsoft.com/support/kb/articles/q177/7/72.asp) explains the process.

In "Restoring an Exchange Server Computer" (November 1998), Mark Ott says to always put transaction logs on a separate physical disk from the databases. If I'm already using RAID-5 on my server, do I still need to separate logs from databases?

Yes, you do. Although RAID-5 provides both data redundancy and better performance than disks, you need to remember what the transaction logs are for. Whenever a new database transaction occurs, Exchange Server immediately writes it to the transaction log and to the copy of the database cached in RAM. Periodically, Exchange Server writes all transactions buffered in RAM back to the real database. During regular operation, the transaction log files are write-only. Components read data from the logs only when Exchange Server replays the transactions during server restarts or during a backup.

By putting the log files on a separate disk, you isolate these sequential write requests on that disk, instead of mixing slow sequential I/O requests with the random I/O read and write requests typical of the database files. If you want redundancy for your transaction logs, make a mirror set for the log file disk, and have a well-tested backup strategy.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish