Delivering external mail to Public Folders

You’ll probably find that Public Folders are a better alternative to shared mailboxes when you need to let multiple users share e-mail or other documents centralized in a single container. If you use an Internet Mail Connector in your organization, Exchange will assign an SMTP alias to each Public Folder that you create. However, if the Public Folder’s permissions for the default user are set to None, users outside your organization that don’t have another defined permission role will be unable to send mail to the folder via its SMTP alias.


There are two methods to allow users outside your organization to send e-mail to a Public Folder via its SMTP alias.


1.       You can allow all outside users to send to the folder by setting the folder’s default permission role to Author instead of None.

2.       You can allow only specific outside users to send to the folder by creating Custom Recipient entries for the users’ own SMTP aliases and then assigning the permission role of Author to their Custom Recipient entries.


Verifying .exe and .dll versions after hotfixes and upgrades

Have you applied and possibly even reapplied so many hotfixes and service packs to your Exchange Server that you’ve lost track of them all? If so, you may run into problems when applying Exchange add-ons and third-party tools that use specific versions of core Exchange .exe and .dll files. Microsoft Knowledge Base article 243604 lists the file size, revision date, and version number of all Exchange Server executable and dynamic link library files and their corresponding service pack levels. We recommend that if you have .dll conflicts, you should verify your server’s current file versions and descriptions against the lists given in this article. To capture file size, date, and version information en masse, use the Filever.exe command-line utility from the Windows NT Resource Kit, see Microsoft Knowledge Base article 183713.

Advanced configuration of public folder replication

You have public folder replication set up between Exchange servers on the same high-speed Local Area Network (LAN). Now you’d like replication to take place less frequently without changing the replication schedule.


When you set up public folder replication, you may have noticed that replication doesn’t occur immediately, even if you select Always under the replication schedule. You may have also noticed that replication can take a while, even though the servers are on the same LAN. Any of this sounding familiar?


To make advanced changes to Public Folder replication, follow these steps:


  1. Open Exchange Administrator.
  2. Select the Configuration container for the site.
  3. Select the appropriate Public Information Store object.
  4. On the File menu, click Properties and then click the Advanced tab.
  5. The Replicate Always interval is set to 15 minutes by default; adjust this value to suit your environment.
  6. The Replication Message Size Limit is 300 K by default; adjust this value to meet your particular needs.
  7. Click OK to save the changes.


NOTE: You’ll need to perform these steps for each server you want to make advanced replication changes to.



Test your RPC connectivity with Rpings.exe

As you may know, Exchange server-to-client and intrasite Exchange server-to-server communication takes place via Remote Procedure Calls (RPC). Though Windows 9x and Windows NT operating systems come with tools that allow you to easily check TCP and other network protocol connectivity between machines, you’ll need a special tool to check RPC connectivity between an Exchange server and its clients or other servers.


Microsoft provides the Rpings.exe server application and its companion client application Rpings32.exe on the Exchange Server 5.5 CD-ROM. These tools behave much like their TCP cousin, Ping.exe. You execute Rpings.exe on Machine A and Rpings32.exe on Machine B. Then use Machine B’s Rpings32.exe’s diagnostic to "rping" the Rpings.exe running on Machine A. For complete diagnosis, reverse roles by running Rpings.exe on Machine B and Rpings32.exe on Machine A and perform the test again.


Call the Doctor before things go wrong

Troubleshooting application errors that crash your Exchange Server services and the Windows NT 4.0 OS can be extremely difficult if your server doesn’t log application crash dump information. We recommend that you configure your Exchange servers to use Dr. Watson to create these log files when a crash dump occurs. If your Exchange server is crashing consistently and you plan to call MS Premier support for assistance, odds are good that Microsoft will ask you for crash dump Drwtsn32.log and user.dmp files. So save yourself some time and make sure that you’re collecting the info before you call for support. Dr. Watson is a Windows NT debugging tool that can log application crash dump information to the Drwtsn32.log text file and log data to the user.dmp file. Using the user.dmp file requires a user mode debugging tool like Windbg.exe.


To install Dr. Watson as the default debugger, run drwatsn32-I at the command. Then run drwatson32 at the command prompt with no parameters to open the Dr. Watson For Windows NT Options dialog box. Configure the options for drwatson.log and user.dmp (crash information). Be sure to deselect the Visual Notification option to allow Dr. Watson to log the crash information without requiring user intervention. This will allow services that have crashed to stop completely; they will restart if you’ve configured service-monitoring tools to restart them. Then click OK to close the Options dialog box. Please note: Your server must have a pagefile on its system partition equal in size to its physical memory in order to capture dump information.


Capturing persistent MTA crash information

When your Exchange Server’s Message Transfer Agent (MTA) logs a fatal error (an event log error with a severity level of 16), it’s designed to try to recover from the error and then attempt to shut itself down cleanly. If the MTA cannot shut down cleanly, it may "hang" and require you to kill its process. When you have to kill the process, the MTA doesn’t write other significant events that could help explain why the crash occurred to the event log. If you’re having a problem with persistent and unexplainable MTA crashes or hangs, you may want to temporarily suspend the MTA’s ability to recover from a fatal error. Doing so will cause the MTA to shut down immediately when it encounters a fatal error. If you’ve configured Dr. Watson as your default debugger (as we explained in a previous tip), it will capture the MTA’s dump information to user.dmp, and you can use this info for debug analysis. To suspend the MTA’s ability to recover from a fatal error, you must make a registry change.


1.       Start Regedt32 and open the key HKEY_LOCAL_MACHINE on Local Machine.

2.       Open SYSTEM/CurrentControlSet/Services/MSExchangeMTA/Parameters.

3.       Choose Add Value from the Edit menu.

4.       In the Value Name field, enter Raise Exception On Fatal Error.

5.       In the Data Type box, enter REG_DWORD.

6.       Click OK and enter the value 1 in the Data field.


We recommend that you use this registry setting until you’ve been able to successfully troubleshoot your MTA problems and then set the value of the key to 0 when your system is stable. This will allow the MTA to try to shut itself down if a different fatal error occurs.



From time to time, the Exchange Server message transfer agent (MTA) will crash, fail to start, or simply shut itself down after a system crash. When it does, you might want to perform an MTACHECK.


If you’re unfamiliar with the MTACHECK command or you’ve simply never used it, don’t be afraid. MTACHECK.EXE is a harmless utility that checks the integrity and consistency of the Exchange MTA queues. It’s located in the \exchsrvr\bin directory.


Here’s the syntax for running the MTACHECK command and optional switches:


mtacheck [/v] [/f <filename>] [/rd] [/rp] [/rl]


·         /v–log verbose details

·         /f filename–log to file specified

·         /rd–remove directory replication messages

·         /rp–remove public folder replication messages

·         /rl–remove link monitor messages


When the utility runs, it checks each queue in the database and removes any items that contain errors. These are placed in \mtadata\mtacheck.out.


For more detailed information on MTACHECK, check out Microsoft Knowledge Base article 175495.


When auto-forwarding rules don’t work like they should

Have you ever created a mailbox rule to automatically forward messages to an Internet address and found that the rule didn’t work when you knew that it should? This can be an incredibly frustrating problem since Exchange doesn’t generate an error or a warning message to tell you that your rule isn’t working properly. The root cause of this problem is that Exchange Server 5.5 doesn’t know the difference between an auto forward to the Internet and an auto reply to the Internet. If you’ve configured your Exchange Server to disable auto replies to Internet messages (an option in Internet Mail Service Properties), you’ve also prevented Exchange Server from auto forwarding messages to the Internet. Fortunately, Exchange Server 5.5 Service Pack 2 fixes this problem. If you haven’t yet applied SP2, you can fix the problem by modifying the server’s registry. See Microsoft Knowledge Base article 192982 for more details.


Enabling POP3 and IMAP logging

If you support mail clients that use Post Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP) to read mail from your Exchange server, you may be perplexed when troubleshooting client authentication and connectivity problems. Or maybe you’d just like to know who’s using these protocols to read mail from your server and from where they’re connecting. Why doesn’t Exchange Administrator let you log and review POP3 and IMAP communications with a server? No one but Microsoft knows the answer. Fortunately, you can configure Exchange Server to log POP3 and IMAP activity to a flat text file by editing the registry. Read Microsoft Knowledge Base article 182504 for details on how to do this. We need to warn you that these text log files can grow rather large very quickly depending on the logging level that you use and your server’s activity level.


Enabling SMTP logging

Troubleshooting problems associated with Simple Mail Transfer Protocol (SMTP) communications between servers can be difficult if you don’t know what the servers are saying to each other. Fortunately, you can use Exchange Administrator to enable SMTP logging, which records SMTP conversations in a flat text file. To enable logging, start Exchange Administrator and open the Server’s Internet Mail Service’s Properties. Select the Diagnostic Logging tab, select SMTP Protocol Log, and set its logging level to Maximum. When you stop and restart your Internet Mail Service, it will log all SMTP activity in a file named L000000X.log (where X is the log serial number) in the Exchsrvr\Imcdata\log directory. These log files can get rather large, so it’s a good idea to only enable logging while you’re trying to troubleshoot a problem and then turn it off when it’s resolved.


When Outlook hangs while using a slow connection

If you have users who connect to your Exchange server over slow WAN connections, they’ve probably complained that their Outlook or Exchange clients occasionally hang for no apparent reason. While your first thought might be to blame the slow connection, there is a documented bug in NT Server 4.0 that could account for this problem. As Microsoft Knowledge Base article 232512 explains, NT Server 4.0 TCP/IP can prematurely retransmit packets to clients connected over slow connections and dramatically degrade client/server throughput. This OS behavior is especially problematic for the Exchange Information Store service, which uses RPC to communicate with clients. Service Pack 6a for Windows NT Server 4.0 fixes this problem with the OS, though there are hotfixes available for previous service packs. If you’re looking for a reason to apply NT Service Pack 6a to your Exchange Server, this could be it.


Providing name resolution for remote clients that don’t use WINS

If your remote clients don’t use WINS servers for NetBIOS name resolution, they may be unable to connect to your Exchange server if they can’t resolve the server’s computer name (given in the Outlook profile) to an IP address. When they try to connect, they may receive the error "Network problems are preventing connection to your Microsoft Exchange server. Please contact your system administrator," even though the server is perfectly functional. To provide name resolution, add an entry to the client’s LMHOSTS file for the Exchange server’s computer name. Then to refresh the NetBIOS cache, type nbtstat -R at the command prompt.


The LMHOSTS file contains instructions for adding an entry. Once added, remote clients should be able to resolve the name to an IP address and connect to the server. Note: If the Exchange server’s IP address changes, you’ll need to change the LMHOSTS entry on each client.


Outlook Web Access, Office 2000, and Exchange Service Pack 3 are a bad mix

Does applying a service pack make you nervous? If not, it should. As a savvy Exchange administrator, you should understand that every time you apply a service pack you are potentially trading old problems for new ones. Applying Service Pack 3 to your Outlook Web Access server will cause problems for clients that have Microsoft Office 2000 installed. These clients will be unable to use Outlook Web Access to open Office documents attached to e-mail messages.


Write-back caching on RAID controllers can be hazardous to Exchange server’s health


Using write-back caching on hardware-based RAID controllers with Exchange Server significantly enhances the performance of RAID hardware. But there’s a potential trade-off: reliability for enhanced performance.


Write-back caching on hard disks and hardware-based RAID controllers may cause the Exchange Server database to become corrupt. UPS hardware reduces—but doesn’t eliminate–the probability of such catastrophes.


System failures caused by memory or operating system errors can cause uncontrolled shutdowns that don’t allow the data cached in the controller’s memory to be flushed to disk. Memory failure of the write-back cache can also destroy data.


Depending on what the Exchange database was doing when the failure occurred, you may face data loss that’s only correctable with a restoration from your last full backup. Up-to-the-minute data recovery may not be an option.


It’s possible to design a controller that supports write-back caching and is safe to use with database servers. Fault-tolerant features like mirrored memory and onboard batteries greatly improve the odds that cache data commits to disk, no matter what the cause of failure.


If your system enables write-back caching, check with your hardware vendor to see if you have a controller with properly designed data integrity features. When in doubt, disable write-back caching on hard disks altogether. The gain in performance won’t be worth diddly if you corrupt your database.


Improve POP3 client performance

If you support POP3 clients on your Exchange server, you may receive the occasional complaint from a user about how long it takes to send mail. The likely culprit? DNS reverse-lookup, which resolves IP addresses to host names.


If you want to keep reverse-lookup in place, you can fix this behavior by adding the appropriate entries to your DNS. However, a faster way to handle it is to simply disable DNS reverse-lookup on your Exchange server. Here’s how.


1. Create a new DWORD value, DisableReverseResolve, under the following registry key:


2. On the Edit menu, click Binary, enter 1, and then click OK.


3. Quit Regedt32.

4. Stop and then restart the Internet Mail Service.


Another benefit of this modification is that inbound SMTP mail should process faster since the Internet Mail Service will no longer take the time to resolve the IP addresses of inbound mail.


NOTE: Remember, editing the registry is risky, so make sure you have a good backup before you begin.