We wanted to filter out incoming Internet mail from several domains, so I added the problem domains in the Message Filtering dialog box and restarted the Internet Mail Service (IMS). However, those domains can still deliver mail. What's happening?
Be sure to include an at sign (@) at the beginning of the domains you want to filter. To filter out all senders from the netzero.net domain, for example, you'd have to enter @netzero.net as the name of the domain you want filtered.
Our company policy restricts the use of deleted-item retention. As a last-ditch safeguard against losing important messages, our managers want administrators to be able to recover items from other users' mailboxes. How do I make this recovery work?
Exchange lets administrators access users' mailboxes by adding alternate recipients to a mailbox or specifying that one mailbox has the ability to open others. But as you've probably noticed, when you use either technique, you don't magically get the ability to recover deleted items for that mailbox. Only the primary mailbox owner can recover items from the mailbox. However, to meet your needs, you can create an alternative mailbox profile and use it to log on to the mailbox and recover items when necessary.
What's the best way to synchronize the clocks on my Exchange servers?
You can use several methods to synchronize your Exchange server clocks, ranging from the ridiculous to the sublime. You need to decide whether you want to accurately set the clocks or just make them all have the same time, even if it's incorrect. Here are a few options you might want to consider:
- Upgrade all your Exchange Server 5.5 servers to Windows 2000 (Win2K), which includes the Windows Time Synchronization service (W32Time). W32Time automatically synchronizes all server clocks in a domain with the domain controller. By carefully specifying which servers receive updates from where and using an external time source, such as a Global Positioning System receiver, you can achieve very high time accuracy.
- Use the Net Time command. You can run Net Time as part of a logon script or at scheduled intervals using the At or Winat commands. This method requires no additional software but assumes that the server you're synchronizing from has the correct time.
- Use the Microsoft Windows NT Server 4.0 Resource Kit Timesync utility.
We have a bunch of Alpha-based Exchange servers. Because Win2K doesn't support Alpha, we've decided to replace those servers with x86-based machines. Are the Exchange database (EDB) files portable between these two platforms?
Yes, you can take an EDB file (and its log files) from Alpha to x86, or vice versa, with no ill effect. However, for the kind of total replacement you're going to do, Compaq recommends bringing in the new servers and moving mailboxes and connectors to them gradually instead of replacing the entire set of servers more or less at once. A gradual approach protects you against the consequences of unexpected disasters.
I want to start testing Microsoft Exchange 2000 Server (formerly code-named Platinum). How can I obtain it?
Exchange 2000 has followed the typical Microsoft beta cycle pretty closely so far. Microsoft released beta 2 to a small number of testers; the company distributed beta 3 to Microsoft Exchange Conference (MEC) attendees, in Microsoft TechNet, and through the Corporate Preview Program (CPP). If Microsoft continues to follow its usual pattern, the company will broadly distribute Exchange 2000 release candidates (RCs) at first; the last RC (or maybe the last two) will go to smaller groups of testers. Your best bet is to join the CPP, subscribe to TechNet if you don't already receive it, or send a request to [email protected]. As an alternative way to preview Exchange 2000 and get some quality time with Win2K, don't forget that you can install and run Exchange Server 5.5 Service Pack 3 (SP3) on a Win2K machine. Remember that Exchange 2000 can run only on Win2K with Active Directory. To maximize your learning, you might consider setting up a Win2K test network and running Exchange 5.5 Server SP3 and the Exchange Active Directory Connector (ADC).
Why does a special procedure exist for removing the first server in a site?
When you install the first server in a new Exchange site, various Exchange components use several site folders to store information in the Information Store (IS) and replicate it to other servers in the site. For example, the Offline Address Book (OAB) is a site folder, as is the Organizational Forms folder. If you remove the first server in a site, other servers in the site lose access to those folders, resulting in unpredictable behavior for OABs, free/busy replication, and organizational forms. Worse still, the first server in a site is the site's routing calculation server, so removing it would render the other servers unable to update the Gateway Address Routing Table (GWART) when necessary. If you plan to remove the first server in a site, see the Microsoft article "XADM: How to Remove the First Exchange Server in a Site" (http://support.microsoft.com/support/kb/articles/q152/9/59.asp). If you've already removed the server and wish you hadn't, see the article "XADM: Rebuilding the Site Folders in a Site" (http://support.microsoft.com/ support/kb/articles/q152/9/60.asp).
How can I tell which server is first in a site?
Simple. Launch Microsoft Exchange Administrator, then open the site's Configuration container. Expand the Server container, then select any server and open its Public Information Store container. Finally, select the Public Folder Resources node. The contents pane on the right side of your Exchange Administrator window will show a list of public folders on the server. Select the OAB Version 2 folder, then open its Properties sheet. At the bottom of the General tab, you'll see two fields: Home Site and Home Server. The OAB is always on the first server installed in a site, so whatever server appears as the OAB's home server is the first server in the site—unless someone has manually moved the OAB. In that case, you can safely remove whatever server was installed first with no ill effect.
Are any scripts or tools for managing and archiving IMS data logs available? I want to keep logging turned on, but the logs get unreasonably large in just a short while.
John Alderson has solved your problem for you. If you drop by the Win32 Scripting site at http://cwashington.netreach.net, you'll find a set of scripts he wrote called "Manage Logfiles on Exchange Server." The scripts use Microsoft's Active Directory Service Interfaces (ADSI) to stop the IMS on the target server, archive the day's logs, zip them into one archive file, purge any old files you specify, and restart the IMS. This script is a big improvement over the do-it-yourself method.
What happens when I queue a message for deferred delivery using the Do not deliver before option in Microsoft Outlook?
The Message Transfer Agent (MTA) maintains a separate queue for what Microsoft calls deferred messages. When you queue a message for delivery and specify that you don't want it delivered before a certain time, the message goes from the user's client to the MTA's deferred work-item queue. The client timestamps the message when it's sent, but the MTA can see that the message is marked for later delivery, so the message sits in the MTA queue until the requested sending time. This behavior can confuse users because the receiving client usually displays the original date stamp. If I queue a message to my wife today and use Do not deliver before to mark it for delivery on Valentine's Day, the message will arrive—but it will bear a timestamp of today's date! If you want to see how many deferred messages are in your MTA queue, use Performance Monitor to look at the Deferred Delivery Msgs counter of the MSExchangeMTA object.
My ISP says I need to turn off the Extended Simple Mail Transfer (ESMTP) protocol. What is it talking about?
ESMTP is a set of extensions to the standard SMTP protocol—the E stands for Extended. Most, but not all, ISPs run SMTP services that understand SMTP. And of those that do, not all completely and correctly implement the ESMTP extensions. Exchange Server 5.5 supports ESMTP pretty well, so it advertises ESMTP support when an outside computer opens a connection to your IMS. If your ISP is telling you that you need to disable ESMTP, the ISP most likely either doesn't know that Exchange supports ESMTP or can't handle ESMTP on its end. Find out which is the case. If you need to turn off ESMTP, you can do so by adding a REG_DWORD value named AdvertiseSMTPExtensions to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters Registry key, then setting its value to zero.
However, you need to pressure your ISP to make its ESMTP support work right. Exchange 2000's SMTP engine makes heavy use of the ESMTP extensions, so to get the full benefit of its SMTP engine, you need to be talking to a fully ESMTP-aware server. If your ISP needs more information, point it to the excellent FAQ list that Andy Webb maintains at http://www.swinc.com/resource/exch_smtp.htm.
My boss and I have been arguing about whether to enable write-back caching on our RAID controllers. He points to a TechNet article that says to leave it off; I countered with a copy of Pierre Bijaoui's MEC presentation about Exchange I/O performance that says to leave it on. Who's right?
It depends. Microsoft's TechNet article does indeed say to turn off write-back caching and so does the famous "Microsoft Exchange Disaster Recovery" white paper (http://www.microsoft.com/exchange/55/whpprs/backuprestore.htm). However, Microsoft wrote both of these documents some time ago, when RAID controllers were much less reliable than they are today. Bijaoui's presentation represents the distillation of Compaq's experience with modern, battery-backed RAID controllers. A rule of thumb is that if your controller has battery-backed RAM, you can turn on write-back caching. If it doesn't, leave write-back caching turned off.
Whether or not you choose to turn on caching, pay careful attention to your system's event log, looking for evidence of the dreaded –1018 error. See my June 1999 column for an explanation of the –1018 error.
Event ID 1016 seems to signify that one user is logging on to another's mailbox. Do I need to worry when I see the error in my application event log?
Probably not. The IS logs event ID 1016 whenever a user tries to access a mailbox for which he or she isn't the primary owner. For example, when you view someone's calendar, the IS logs an event ID 1016, showing that you tried to open that person's mailbox. These events are normal; if you have an antivirus package or content scanner that runs as a service and logs on to mailboxes in the store, you'll see a lot of these messages.
How can I configure the Exchange Server 5.5 SP3 Mailbox Manager to ignore (and not clean up) certain types of messages?
Earlier versions of the Mailbox Cleanup Agent had a feature that let you specify which message types you didn't want cleaned up. But because Outlook stores many items as messages (including appointments, contacts, and tasks), it makes sense not to automatically remove some types of items that you'd like to keep. You can, however, configure the Mailbox Manager to ignore certain messages by following these steps:
- Open Exchange Administrator.
- Navigate to the Add-Ins container, then select the Mailbox Manager in the right pane.
- Open its Properties sheet with the File, Properties command.
- Click the Policies tab, then in the General Policies group, click Message Classes.
- Add the message type (or types) you want to exclude in the Excluded Message Classes list. You can specify just the message type (e.g., IPM.contact), or you can use wildcards (e.g., IPM.note.*).
- Click OK twice.
Note that these changes will take effect the next time the Mailbox Manager runs and that they might have unexpected side effects (translation: You might lose lots of stuff unexpectedly). If you're not completely sure of the message types you're specifying, try your changes on a test server first.
We set mailbox size limits (with restrict send turned on) for all users in our private IS. However, a misfiring out-of-office rule triggered a mail loop that quickly filled the users' mailbox with thousands of bounce messages—filling up our log disk in the process. Why didn't the size limit prevent this problem?
Exchange Server 5.0 had a bug that prevented Exchange from checking mailbox limits when you use a rule to generate and send new messages. Microsoft fixed the problem in Exchange Server 5.5, but that raised another problem—Exchange couldn't autoanswer meeting requests if the recipient mailbox was over its quota. (The Microsoft article "XADM: Meeting Requests Are Not Delivered if Recipient's Mailbox Has Exceeded the Storage Limit and Has a Delegate Defined"—http://support.microsoft.com/ support/kb/articles/q217/1/39.asp—explains this problem.)
In Exchange Server 5.5 SP3, Microsoft went back to the old-style version 5.0 behavior: Rules can always fire and send messages, no matter what quota limits are in place. However, Microsoft added a Registry key to control this process. Adding a REG_DWORD value named Apply Mailbox Quota to Rules under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIS\ParametersPrivate key and setting its value to anything other than zero will cause rule-generated messages to be subject to any quota-related sending restrictions on the mailbox. However, in the article "XADM: Quota Ignored When Rule-Originated Message Is Sent" (http://support.microsoft.com/ support/kb/articles/q169/7/04.asp), Microsoft points out that this action can lead to undesirable behavior, so it recommends setting this value only if you're trying to troubleshoot a misfiring rule or mail loop.
