The Exchange Server Troubleshooter - 01 Jun 1999

Microsoft just released a patch for a flaw in the Exchange Server Lightweight Directory Access Protocol (LDAP) service that could potentially let an attacker run arbitrary code on your server. The flaw is in the code that handles incoming LDAP requests. The code doesn't check whether the buffer it allocates to hold the request is large enough, so if an extra-large request comes in, its data can overwrite the stack and cause the code to execute. This overrun can also cause the LDAP service to crash, possibly taking the server with it. For complete details and a patch, see As a workaround, you can turn off LDAP altogether or filter out port 389 on your external firewall. Be sure to go to the Security Advisor page at services/bulletin.asp, and sign up for the Security Notification Service.

In your March 1999 column, you mentioned a program for removing passwords for .pst files, but I can't find the program. Where can I obtain it?

That answer has generated more reader mail than any column I've ever written. The file is no longer available on the TechNet CD-ROM, but it is still out there on the Web. You can find it by doing an AltaVista search or by searching the archives of the msexchange mailing list ( If you can't find the file, you can visit; Passware will gladly sell you password crackers for .pst files, Office documents, and many other types of files.

We perform a nightly offline backup of our Exchange server. Last week, the backup failed because the System Attendant (SA) began starting up (apparently spontaneously) at 8:10 p.m., right when the backup procedure was kicking in. After this problem occurred on several consecutive nights, I scheduled a batch file to run at 8:12 p.m. to shut down the SA, allowing the backup to complete successfully. Why does the SA start in conjunction with the backup procedure?

Because your original message points out that you know offline backups aren't the best way to perform backups, I won't harp on that point further. Instead, I'll suggest that this problem is likely a result of a forgotten server monitor.

When you use a server monitor, the monitor defaults to watching the Directory Service (DS), Information Store (IS), and Message Transfer Agent (MTA). However, because these three services depend on the SA and the monitor's not smart enough to restart the SA if it fails, someone at your site might have added the SA to the server monitor, along with an action that specifies that Exchange restart the service the first time it fails.

To fix the problem, check all the server monitors you've configured and make sure that none of them is watching the SA. (Mark Ott explains server monitors in "Using Exchange Server Link and Server Monitors," May 1999.)

We installed Microsoft Proxy Server 2.0 as a firewall and proxy solution for our network. Since the installation, we can use Outlook Web Access (OWA), but we haven't been able to use POP3 clients. The OWA and POP3 clients come in over the Internet. Does Proxy Server 2.0 prohibit POP3 access to Exchange Server from working? If so, how can I work around this problem?

When you install a proxy server or firewall, you isolate your LAN from the Internet. The proxy server passes in or out only the traffic types you specify. You have to configure the proxy server to allow POP3 traffic from the IS service. To add POP3 to the list of protocols the proxy server can support, make sure you have a separate proxy server configuration file just for the IS service. Create a wspcfg.ini file, and put it in the same location as your store.exe file (usually in \exchsrvr\bin\). The file looks like this:


You need the 110 in the second line because POP3 traffic is carried on port 110. To add Network News Transfer Protocol (NNTP) or Internet Message Access Protocol (IMAP), add their port numbers (119 and 143, respectively) to that line. The Microsoft article "How to Configure Exchange or Other SMTP with Proxy Server" ( kb/articles/q181/4/20.asp) provides more information about configuring Proxy Server 2.0 for use with Exchange Server.

Why is the modification time always wrong when I modify an item in the directory?

This problem is a kind of April Fool's joke. Richard Smith of Phar Lap Software found a bug in msvcrt.dll, the Visual C++ (VC++) runtime DLL that causes applications using it to calculate dates wrong, starting on April Fool's Day, 2001. (You can obtain the details about the bug at

Microsoft promptly fixed the problem by issuing an updated version of the DLL. However, the new version changes the way the DLL handles dates. The result is that Exchange (and other applications) report times and dates differently than the earlier DLL version did--timestamps start appearing as Greenwich Mean Time (GMT) instead of your local time. For example, Mountain Standard Time (MST) and GMT differ by 6 hours, so if you modify an item at 2:00 p.m. MST, the directory will show an update time of 8:00 p.m.

You apparently have installed the new version, because you installed either VC++ 6.0 or some other product that includes the new version. You can fix this problem by reverting to an earlier version of msvcrt.dll, but I recommend tolerating the incorrect timestamps until Microsoft releases a hotfix, probably in the next Exchange Server service pack. The problem isn't serious enough to run the risk of messing up some other application that depends on the old DLL.

The IS service on my Exchange Server 5.0 server stops responding, and the Windows NT Performance Monitor shows high CPU usage for the IS thread. I installed all Microsoft's recommendations for service packs and the post-Service Pack 2 (SP2) hotfixes for the IS service, but none of these actions helps. I don't want to upgrade to Exchange Server 5.5, because it doesn't offer a fix either. What do you recommend?

The updated Microsoft article "XADM: Store Process Is Causing 100 Percent CPU Utilization" ( articles/q215/9/24.asp) details this problem and now includes a hotfix. This particular problem is the result of a flaw in the IS service that causes the IS service to enter an endless loop while trying to get a message ID during public folder replication. Other store fixes have addressed other causes of this symptom, so you might need this fix even if you've already installed earlier fixes.

The new fix is available for both Exchange Server 5.0 and Exchange Server 5.5. For version 5.0, you need build 5.0.1461.82 of the mdbmsg.dll and store.exe files; for version 5.5, you need build 5.5.2528.0 of gapi32.dll, mdbmsg.dll, and store.exe.

I want to use the Exchange Server LoadSim to test my Exchange Server 5.5 servers, but I can't find it. Isn't LoadSim on the Exchange Server CD-ROM?

Microsoft included LoadSim on the Exchange Server 4.0 and Exchange Server 5.0 CD-ROMs, but it's not part of the standard version 5.5 distribution. However, it's freely available from Microsoft's Web site. The handy page at backoffice/downloads.htm#exchange lists all the available downloads for Exchange; choose Load Simulator, Exchange Server 5.5.

My company just built a new Exchange server with 1GB of physical RAM. Why does the event log occasionally report event ID 1160, signifying that the IS ran out of memory?

You receive the report because Exchange really does run out of memory. Under NT Server, applications have a 2GB address space to use (NT Server, Enterprise Edition has 3GB), but executable code takes up much of that address space. Each thread the system spawns requires extra space. The upshot is that not all of that 2GB or 3GB virtual address space is really available for Exchange to use, because system components are already using it.

By itself, this 2GB or 3GB limit isn't a problem. However, the Performance Optimizer has a flaw that causes it to misadjust the settings that control how much RAM the IS allocates for its operations. This flaw can lead the Performance Optimizer to instruct the store to allocate the entire 2GB of memory, even though not that much memory is available. When the store tries to follow the instruction, you get an event 1160 in your log.

The 1160 events start popping up when the server is under a heavy load, because the extra load causes the store to try to allocate extra memory. When the server is under a light load, it can get by with the amount of RAM that's available, so you don't see the error.

Don't be too concerned when you see this error. Just call Microsoft Product Support Services (PSS) and obtain the Performance Optimizer hotfix.

I use a mailbox (and Robert Strong's AutoAccept script from to manage nine conference rooms. Currently, a user who needs a conference room has to invite all nine rooms, find one that's available during the time desired, and then uninvite the other eight rooms. What's a more efficient way to schedule a room?

You can obtain Availability Viewer from Sue Mosher's Exchange Resource Center Web site ( As Screen 1 shows, this great tool presents a bar-graph view of the schedule for each of the attendees for a meeting. You install Availability Viewer as a form into your Outlook client and use it to check the free/busy times for a group of conference rooms at once.

Our former UNIX administrator has written many automated scripts to perform maintenance tasks on the NT and Exchange servers. Is a command-line utility available to send mail from within a script?

Several such scripts exist. The Mapisend utility (which used to be called sendmail, not to be confused with UNIX sendmail) lets you use the Messaging API (MAPI) stack to send mail. You can find this utility in the Microsoft BackOffice Resource Kit (BORK). However, you must provide a user profile name and password that it can use to log on to MAPI. Thus, the utility might not be suitable for your situation.

Another excellent solution that will probably do what you want is Postie ( Postie uses SMTP, NNTP, or IMAP4 to post messages directly to the destination you specify. It can also fetch POP3 or IMAP mail, dequeue stored mail, and act as a mailing list processor. Postie is free for noncommercial use, $50 for business use, and $250 for a site license with source code. It also runs on UNIX.

What's event ID –1018, and why is everyone scared of it?

You'd be scared too if you knew what it was. Event ID –1018 is shorthand for JET_errReadVerifyFailure, which is the event ID the IS posts when it can't verify that it correctly read a page from the database. Whenever the database commits a transaction, the database engine calculates a checksum it's writing for the page and stores it in the page header before writing it to disk. The database hands the write request over to NT, which asks the hardware to do the actual write. Some drivers return a success code before they've performed the write, so the database doesn't know the write didn't complete.

Most people report seeing –1018 errors when they're trying to perform an online backup because part of the backup process regenerates the checksum for each database page and compares it with the stored value. If the values don't match, the IS can tell that the data on disk is corrupted and bang! it's –1018 time.

Although –1018 is an Exchange error, it signifies that you have a hardware problem, such as faulty SCSI controllers, out-of-date firmware, or improper SCSI termination. Fix the hardware problem first, even though Microsoft advises that you immediately restore your system from a backup. If you follow Microsoft's advice, you'll fix your database but not the underlying cause of the problem.

Hide 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.