I ran the Mailbox Cleanup Agent (Mbclean) on my Microsoft Outlook users' mailboxes. Why didn't the utility clean everything?
By design, the Mbclean utility doesn't touch Calendar, Contacts, Notes, Journal, or Tasks folders. Microsoft designed the utility that way so you can use Outlook for long-term recordkeeping without fearing that the cleanup utility will delete important information, such as your list of staff meetings from 1996. Many companies have requirements for archiving meeting notes and schedules, and Mbclean can interfere with that archive process. To manually archive this data, you can use Outlook's File, Archive command; Outlook also features AutoArchive, which does much of the dirty work for you. After you archive files, Mbclean leaves them alone.
Mbclean isn't part of the standard Exchange Server installation. You can obtain it from the Microsoft BackOffice Resource Kit (BORK). Be sure to use Mbclean 1.9 or later; earlier versions had bugs that can do unexpected things to your mail, such as deleting tons of mail you didn't ask it to. Be sure to tell your users what the utility will do before you use it, because users hate surprises, especially disappearing mail. Also note that Microsoft Product Support Services (PSS) doesn't officially support Mbclean.
I applied a Microsoft store.exe hotfix. Now, some of my users can't reply to messages in their Inbox, although they can still send and receive mail. What's happening?
Accidents happen, and this defect is one of them. One of the patches for store.exe caused the problem, and Microsoft inadvertently included the problem in a hotfix. Any version of the store.exe components between build 2232.x and 2402.0 is vulnerable to this particular failure. To correct the problem, you need another hotfix, which Microsoft included in Exchange Server 5.5, Service Pack 2 (SP2).
How can a defect in a hotfix slip through the cracks?
If you've ever read a Knowledge Base or TechNet article that mentions a hotfix, you know that Microsoft warns you up front that when it comes to hotfixes, the cure can be worse than the disease. The warning reads, "A supported fix that corrects this problem is now available from Microsoft, but has not been fully regression-tested and should be applied only to systems experiencing this specific problem. If you are not severely affected by this specific problem, Microsoft recommends that you wait for the next Microsoft Exchange Server version 5.5 service pack that contains this fix."
Let me translate. This hotfix resolves one particular problem. However, in the interest of getting the fix out to customers quickly, Microsoft hasn't completely tested the hotfix to make sure it doesn't cause other problems. Even Microsoft can't test every possible hardware or third-party software configuration, but getting the fix out is more important than holding it for exhaustive testing. If you're not having a major difficulty with the problem that the hotfix cures, don't apply the hotfix. Instead, wait for the next Exchange Server service pack, which will include the fix without any undesirable side effects.
In your November 1998 column, you suggested not using Eseutil to do offline defragmentation unless it was really necessary. How can I determine how much unused space is in my Information Store (IS)?
In Exchange Server 5.5 SP1, Microsoft added a set of event log messages that give you information about free space. Every night, the IS logs two information messages, marking them with ID 1221 and showing MSExchangeIS Private or MSExchangeIS Public as the source. These messages tell you how many megabytes of free space remain in the private and public stores after defragmentation finishes. This free space is white space; the IS can use it for expansion, or you can reclaim it by stopping the Exchange Server services and using Eseutil to do an offline defrag.
Another way to get the same information is to use the new Eseutil command-line switch /ms, which Microsoft added in SP1. This switch commands Eseutil to walk through the database and count the total number of database pages it finds. Each page takes up 4KB of disk space, so multiply the number of pages by 4 to get the total storage in kilobytes, then convert the total to megabytes. By design, this estimate is higher than the estimate the event log provides. (Note: The SP1 updater doesn't update the copy of Eseutil in \exchsrvr\bin; Microsoft moved the new version of Eseutil to \winnt\system32.)
One of my Outlook Web Access (OWA) users reached the mailbox storage limit my company applies to all users. However, whenever she tries to use OWA to delete mail, OWA says it can't delete the selected item. Why?
This behavior is a flaw in the original Exchange Server 5.5 version of OWA. The workaround is to use another client (e.g., Outlook Express, Eudora, Netscape Communicator) to remove items until the mailbox size drops below the threshold. Microsoft fixed this problem in SP1, so installing SP1 or later is the permanent solution. To greatly increase OWA's stability, install the Active Server Pages (ASP) hotfixes for Windows NT and install NT 4.0 SP4.
Is the Microsoft Exchange Conference (MEC) worth going to? My boss said I had to choose between TechEd and MEC this year. Do you know when and where MEC will be?
MEC is a valuable conference. The 1998 event was jam-packed with good material, ranging from introductory overviews of custom applications you can deploy with Exchange Server to achingly detailed presentations about Exchange I/O performance and database structures. The sessions are in tracks, so if you're most interested in migration, deployment, application development, or something else, you can attend a track with sessions about that specific topic.
As for choosing between TechEd and MEC, my answer is, "It depends." MEC focuses completely on Exchange. TechEd covers many topics, including some Exchange coverage. However, most Exchange sessions at TechEd discuss topics that are more relevant to resellers and support staff than to administrators. If you're a full-time Exchange administrator, you can recoup the $1200 price of admission to MEC the first time you correctly perform a complex task, such as a multiserver recovery, as a result of what you learned.
This year's MEC will be in Atlanta October 4-7. You can get more conference information on the Exchange Server pages on Microsoft's Web site closer to the scheduled date. You can also download the PowerPoint presentations from the 1998 MEC at http://www.microsoft.com/ exchange/55/gen/mec98.htm. Stop by to get a taste of what you can expect.
My company upgraded a test server to NT 4.0 SP4 to see whether the service pack had any effect on the Exchange Server setup. Now, none of the Internet protocols work. Event log messages say the protocols can't accept clients on an external interface. Why?
SP4 introduces a change to the way TCP/IP address resolution works. Before SP4, the network device interface specification (NDIS) driver returned IP addresses in no particular order. The SP4 scheme returns addresses in the order the network needs to bind them, even if they're not bound yet. This occurrence means that when the individual Internet protocols try to start, the address they attempt to use might not be bound yet. If the address isn't bound, you get the event log message, and the protocol won't start.
You can obtain a hotfix for this problem from Microsoft, in the form of a new version of rnr20.dll. The fixed Intel version is dated 1/29/99 at 6:27 p.m. and is 43,792 bytes; the fixed Alpha DLL has the same date, a timestamp of 6:51 p.m., and a size of 72,464 bytes. You need to obtain these hotfixes from Microsoft PSS; they're not currently available on the Web site.
How can I append a legal disclaimer to every outgoing message from the Exchange server?
This question pops up with surprising frequency. Many sites want to tack on some sort of disclaimer that says, "Don't read this if you get it by mistake." Other sites insist on adding several paragraphs of legal mumbo jumbo about email confidentiality. However, Exchange Server doesn't support adding disclaimers.
You can configure Outlook's AutoSignature function to add a disclaimer, but an AutoSignature disclaimer might not be suitable if users can edit or suppress it. Third-party products (notably Content Technologies' MIMEsweeper at http://www.contenttechnologies.com/index2.htm) can perform this task.
A better question to ask is what the disclaimer is for and whether including it provides any discernible benefit. The legal community seems to disagree about whether boilerplate disclaimers tacked on to email provide any legal protection. If your management insists on having disclaimers or confidentiality notices, you might be wise to investigate whether the cost of MIMEsweeper or another product will gain your organization any legal protection. Some fascinating white papers (try http://www.contenttechnologies.com/hotdog/legal.htm for an example) lay out all the potential risks of email, many of which seem pretty laughable to me (but then, I'm not an attorney).
My company doesn't want its Exchange Server users to return delivery status receipts to the Internet. How can I turn off this feature?
Internet messages can contain headers that ask the recipient's mailer to send a return receipt when the recipient reads the message. Because this receipt contains the recipient's mail address and display name, it exposes some information about your users. Some sites don't want even this tiny amount of information leaked, so they asked Microsoft for a way to turn this functionality off.
Version 5.5.2539.1 of the Exchange file imsmsg.dll lets you plug this hole. You can get this file from Microsoft PSS. After you've installed the file, you have to add a new REG_DWORD value named AlwaysSuppressDR to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIMC\Parameters Registry key, then set its value to 1. That addition forces the Internet Mail Service (IMS) to suppress read receipts the system sends to the Internet, although the IMS can still send other types of automatic replies (such as the dreaded Out of Office), depending on how you configure your IMS.
We recently upgraded one of our older Exchange servers to Exchange Server 5.5 SP2. When we reboot the server, occasionally we get an error message stating that there was an initialization failure in user32.dll. What causes this problem, and how can we fix it?
You can usually trace this error back to one of two causes. The first possibility is that the version of user32.dll on your machine doesn't match some other component. This problem can occur when you've installed service packs (either for NT or for another application, including Exchange Server, Internet Information Server—IIS, and Microsoft Office) in the wrong order. If you think you've installed the wrong service pack, double-check the time and date of your user32.dll against the correct user32.dll version for the service pack you've installed. If you've accidentally mixed up the versions, reinstall the offending service pack.
The second possible cause is that the combined set of services you're running takes up too much of NT's desktop heap pool, the memory pool that you can carve into smaller chunks as you need them. NT uses this pool of memory when it starts services. If you run seven Exchange services (including the IMS, the Microsoft Mail services, and the Message Transfer Agent—MTA) on your machine, they might suck up the entire pool, resulting in the error.
To fix this error, edit the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ Session Manager\SubSystems\Windows value in the Registry. This value usually looks something like
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDl lInitialization,3 ServerDll=winsrv:ConServerDll Initialization,2 ProfileControl=Off MaxRequestThreads=16
(although in your Registry editor, the value will be on one line). Edit this value by adding ,512 to the second SharedSection value. The result will look something like
SharedSection=1024,3072,512
Save your changes and reboot. This change forces NT to allocate only 512KB to each new service it starts, which helps your services run in the allocated amount of space.
Sometimes when I try to add a new mailbox, distribution list (DL), or custom recipient, I get an error message (0xc105001c) from the Directory Service (DS) claiming that insufficient disk space is available to do what I want, even though my disk has plenty of free space. Do you know why?
No one seems to know why this error occurs. The Microsoft article "XADM: c105001c Popup When Adding or Deleting a Mailbox" (http://support.microsoft.com/ support/kb/articles/q198/5/54.asp) doesn't explain the cause of the error. The suggested workaround is to stop and restart the DS. However, before you stop any Exchange service for any reason, always check the event log to make sure the log doesn't contain any warning messages. For example, if your IS database is corrupted, when you stop the IS and try to restart it, it won't restart, and you'll be hating life. Don't stop a service until you're confident you can restart it when you need to and then only after you perform a complete online backup.
My company is running Exchange Server Standard Edition, and the private IS is approaching the 16GB limit. What happens if the IS surpasses the limit?
First, your IS stops. Next, you get a call from Microsoft's telemarketing sales department. Actually, I'm half-joking. Operators are not standing by, but when the size of either the public or the private IS database surpasses the 16GB maximum limit, the IS service stops and refuses to restart until the database shrinks. The IS will preserve, in log files, whatever transactions were pending when the service stopped.
You can shrink the database in several ways. First, consider using Eseutil to do an offline defragmentation of whichever store is over the limit. (For information about Eseutil and defragmentation, see "The Exchange Server Troubleshooter," November 1998.) After you complete the defragmentation, you can use Mbclean or the Tools, Clean Mailbox command in Exchange Administrator, to strip out old messages that you no longer need. If your public store is the problem, consider setting more aggressive age limits on some or all of your replicas. After you've taken action to shrink the database, you'll be able to restart the IS, and the IS will be able to process any pending transactions.
