I installed Exchange Server 5.5 Service Pack 1 (SP1) on my server. Now when my Outlook Web Access (OWA) clients try to open messages, they occasionally receive the error message Failed to open this message. Why?
The culprit is probably the dreaded "gotta put your service packs everywhere" monster. Most sites run Internet Information Server (IIS) and Exchange Server on two separate servers. This practice is good, because it lets you better control the load and resource usage on each machine. However, when you install any Exchange Server service pack, you don't install it just on your Exchange servers; you also have to install it wherever you've installed other Exchange Server components. In your case, you need to install the service pack on the IIS server, too.
You might remember that previous columns have recommended the same fix for problems with Performance Monitor counters and Exchange Administrator. In general, it's a good idea to keep a list of which components you've installed on which machines so that when a new service pack arrives you can update all the machines you need to.
Windows NT 4.0 SP4 fixes many problems in the IIS Active Server Pages (ASP) component. Make sure you upgrade your Exchange Server 5.5 SP2 and IIS machines to NT 4.0 SP4.
Can I configure my system to reject messages from specific senders on an X.400 connector?
If you've upgraded to Exchange Server 5.5 SP2, you can filter out incoming messages based on any part of the originator's distinguished name (DN). For example, if you were running a server for Iraq's Ba'ath Party, you could arbitrarily reject messages from anyone in the United States or the United Kingdom; if you were running a server for the Internal Revenue Service, you could reject any messages from Steve Forbes or Ross Perot (who promised to abolish the agency). In short, if you figure out a legal DN value to express whom you want to block, Exchange accepts it.
The key to these restrictions is the Bar P1 Originator Registry value, which implements blocking. This value is a REG_MULTI_SZ datatype that you add to each connector's Registry tree under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\connectorName\. For example, if your X.400 connector is NorthAmerica, you add the new value to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\NorthAmerica.
The connector examines the values attached to the Bar P1 Originator when it sees an incoming message; if the sender's DN is on the list, the connector rejects the message. Because the Bar P1 Originator is a REG_MULTI_SZ datatype, it can hold multiple values. Use the Registry editor of your choice to add full or partial DNs to the list of values. For example, to avoid messages coming from the US Department of Defense, just type
c=us, o=US Government, ou=US Department of Defense
In my Iraq example, you need two entries: one reading c=US and one reading c=UK.
You can control whether the Message Transfer Agent (MTA) sends back a nondelivery report (NDR). By default, Exchange doesn't send an NDR. To force the MTA to return an NDR, add the REG_DWORD value NDR to barred originator to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeMTA\ Parameters\connectorName key and set its value to 1. In either case, the MTA logs an event in the event log each time Exchange rejects a message.
For security reasons, my company wants to completely blank out deleted data on its Exchange servers, including on backup tapes. Can I do this?
With SP2, you can add a Registry value that forces the Exchange Server database engine to zero out empty database pages before backing them up. This action guarantees that no deleted information makes it on to your backup tapes. However, as SP2 implements this action, it works only at backup time, and it affects only pages in the public Information Store (IS)—the private IS has no equivalent.
To turn on page zeroing, add the REG_DWORD value Zero Database During Backup to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIS\ParametersSystem key, then set its value to 0x00000001. The setting will take effect on the next online backup you run. You need to be careful with your old backup tapes (i.e., any tapes that you made before you changed the setting), because they contain deleted data.
However, this switch doesn't meet the US government's requirements for erasing classified or sensitive data. I don't know of any approved solution for erasing classified data on an Exchange server. If you know a solution, please tell me about it.
To control backfill replication in my site, I ran authrest.exe from the Microsoft BackOffice Resource Kit and got an error saying that Exchange Server couldn't find edb.dll. What can I do?
Upgrade your server to Exchange Server 5.5 SP2. This fault surfaced in Exchange Server 5.5, but Microsoft didn't fix it in SP1. Don't you hate it when that happens?
I've tried several times to repair a damaged public IS with eseutil /P, but I receive error 1526 (JET_errLVCorrupted) every time. What's happening?
This error message is frustrating. Eseutil has a fault that occasionally causes it to falsely report error 1526. You can prevent this problem by upgrading to SP2. If you have the problem now, you can safely upgrade to SP2, but make sure you have a good offline backup first.
What's the tmp.edb file for? I noticed that it's in my database directories, but I can't find it on any of my backup tapes.
Exchange Server has two of these files: one in the mdbdata directory and one in the dsadata directory. The file's name suggests its function: It's a temporary working area that the Directory Service (DS) and the IS use to hold transient data. For example, when the DS or IS creates a new temporary database index, Exchange Server puts the index in tmp.edb, instead of putting it in the real database (from which you would have to remove it later). The reason these files don't appear in your backups is that the DS and IS delete their temporary files as part of their usual shutdown process, so when you stop the services to do an offline backup, Exchange Server automatically removes the files.
My company uses several public folders to store customer feedback. Because employees want to be able to search for old messages, I haven't set any age limits on messages. Browsing these folders and reading messages from them takes time. How can I improve performance without removing all the archived messages?
The server keeps track of which public folder messages each client has read in each folder. When you have lots of messages in a folder, the server needs time to collect all the read and unread flag information and send it to your client. This activity leads to the performance slowdown you mentioned. You can fix the problem in three ways: Limit the folder size by removing items (which you don't want to do), limit the folder size by moving old messages somewhere else, or tell the public IS not to track which users have read which individual messages.
The first solution is the easiest to implement, but the second is close behind. Just create a set of folders (e.g., one for each quarter of the calendar year). Move most of the messages from your current folders into these archive folders. Voila! Performance improves, because each folder has fewer items in it.
In SP2, Microsoft added a new Messaging API (MAPI) property that you can apply to individual folders. This property tells the IS whether to keep track of which items each user has read. The default setting is for the IS to act like pre-SP2 versions and track the read status of every item. To turn off this setting on an individual public folder, you need to write some code to toggle this property on the items. The property to set is PR_DISABLE_PERUSER_READ; in brief, your code needs to get a pointer to the folder you want to modify, then set the property value for that folder to 1.
Another alternative is to use Microsoft Site Server to index the contents of the public folder, then use a Web browser to search the index. This technique frees you from having to write any MAPI code, but it requires you to install and use Site Server.
When I installed Key Management Server (KMS), I wrote down the KMS startup password. How can I change the KMS startup setting so that I can use a disk with the password on it instead?
Good news! If you're running Exchange Server 5.5, you can change the KMS startup setting with a simple Registry tweak. Add the string value MasterPasswordPath to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\KMServer subkey. In that value, specify the full path to the location you want to use. In your case, you need to set the value to A:\. When you start the KMS, it will look in the specified path for the file kmserver.pwd. This file must contain one line with the KMS server password, and nothing else. (This trick also works in the opposite direction: If you've set your KMS to start with the disk and you don't want it to, stop the KMS and remove this value from the Registry.)
A word of caution: You might want the convenience of putting your KMS password directly on your server, instead of a disk. This practice is a poor idea from a security standpoint, because as soon as you expose your KMS password, an attacker can start your KMS and use it without your knowledge. You're much better off leaving the password on a disk and keeping it locked up except when you start the KMS. However, this arrangement means that you can't start the KMS without the disk; if you've set the KMS to start at boot time, it won't start unless a human is there to plug in the disk. You can't simply leave the disk in all the time, because when your server reboots, NT won't be able to boot (unless you've disabled disk booting in the BIOS). Consider the security vs. convenience trade-offs very carefully before you put the password on your server's hard disks.
My IIS server, which does nothing more than service OWA users, keeps hanging. When I check it with Performance Monitor, it shows a very high CPU utilization. What's happening?
This problem is yet another reason to install SP1 or SP2, because one of the OWA DLLs has a fault. If you have an OWA user who cancels an attachment upload before the upload is complete, the Exchange Server upload DLL goes into an infinite loop. This glitch usually happens when users send very large files (such as that 40MB marketing presentation) or use slow links to reach the OWA server.
One of my customers uses the Internet Mail Service (IMS) to send mail from an Exchange Server 5.5 SP1 server. Sometime recipients who are using Netscape can't open the attachments. Instead, they get an unreadable attachment that says it's type application/x-ms-tnef. How can I solve this problem?
The problem in this case is that Exchange converts message contents between its internal format and formats it thinks the outside world can read. This content conversion happens in both directions with the IMS, because the IMS is responsible for converting incoming MIME or UUencoded mail to Exchange format and outgoing mail to either MIME or UUencode, depending on the corresponding setting in the IMS. In this case, the problem is that Exchange thinks it needs to send a Transport-Neutral Encoding Format (TNEF) message. When Netscape receives the message, it doesn't know how to process the TNEF content, so it happily shows it to your customer's recipients as a MIME attachment.
Most of the time, this problem suddenly appears because the sender has accidentally included Rich Text Format (RTF) material in a message. If your IMS recipients haven't had any problem but TNEF pops up unexpectedly, the sender probably has started using fancy colors, text styles, and formatting. The AutoSig feature in Outlook is frequently the culprit: A user creates a nifty formatted signature—not realizing that it will convert the message to TNEF for some clients—then forgets the TNEF is turned on.
In other cases, you might need to tell your IMS to use UUencode instead of MIME for message attachments; you usually need UUencode when you're sending to non-MIME-capable clients such as MS Mail and older versions of cc:Mail. Your customers might also need to configure their Outlook client to use UUencode instead of MIME for messages the client sends.
We upgraded our servers to SP1 so we could let our users use X.509 v.3 certificates for Secure/MIME (S/MIME). Encrypted messages work fine, but why can't our clients send signed messages using their certificates?
Microsoft made a design decision in SP1: The IMS default is to not select the Clients Support S/MIME signatures check box. Because pre-SP1 Exchange clients could use only X.509 v.1 certificates (which aren't very useful for most applications), the IMS default wasn't a problem. However, the default doesn't work in your case. You need to instruct your IMS that your clients have the capability to send signed messages. To do so, open the IMS Properties dialog box, switch to the General tab, and select the Clients Support S/MIME Signatures check box.
One caveat: Don't flip this switch until all your clients are S/MIME capable. If you're using Outlook 98 everywhere, you'll be OK. If you have Exchange or Outlook 97 clients, you need to upgrade them to Outlook Express or Outlook 98, both of which have full S/MIME support.
