The Exchange Server Troubleshooter - 16 Oct 2000

We want to use Exchange Server's Advanced Security for our worldwide messaging system. However, when I install Exchange on a server running the French version of Windows NT, why can't I install the Key Management Server (KMS)?

For about 100 years, the export of cryptographic equipment (software and hardware) from the United States was subject to a variety of byzantine laws. Because the United States has begun to relax these laws in the past few years, you can now export some types of encryption software.

However, the problem you describe has nothing to do with US laws. The French government had long prohibited its citizens from using encryption, and Microsoft couldn't have shipped cryptographic software to French customers even if the US government had allowed it.

Because the French have recently liberalized their policies, you can now use the KMS with Exchange, provided you can install it successfully. Installation requires a hotfix for Exchange Server 5.5 and a separate patch for Outlook clients. The Microsoft article "XGEN: Installation and Use of Encryption on Exchange Server with French Settings" (http://support.microsoft.com/ support/kb/articles/q248/0/52.asp) explains the fixes. After replacing the version of Exchange Setup on the product CD-ROM with the hotfix version and making a few Registry changes, you can install the KMS. As an alternative, you could just install the KMS on an English-language server, but what fun is that?

We set up a test lab with Exchange 2000 Server. Now, I want to remove the first server in our test Exchange 2000 organization. I know that Microsoft offers a procedure for removing the first Exchange Server 5.5 server in a site. Does Microsoft have a corresponding procedure for removing the first-installed Exchange 2000 server?

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) describes the procedure for Exchange Server 5.5. The Microsoft article "XADM: Removing the First Exchange 2000 Server from the Site" (http://support.microsoft.com/support/kb/articles/q252/4/86.asp) describes a similar procedure for Exchange 2000. However, this article's seven-step procedure doesn't provide enough details. Here's my explanation of the steps.

We have a mixed environment of Macintosh and Windows Outlook clients using our Exchange server. Windows users get warnings when their password is going to expire, but the Mac users don't. Is any method available to make Mac Outlook aware of password expiration?

This omission is a longstanding irritation to people who are using anything other than Win32 Outlook. Outlook versions exist for Windows 3.x and Mac and for a variety of POP3 and IMAP4 clients that can use Exchange, but none of these versions receive advance warning of password expiration. The Microsoft BackOffice Resource Kit (BORK) includes the Password Expiration Warning Application tool. PEWA scans the domain, looking for accounts whose passwords are about to expire. The tool then searches the Global Address List (GAL) to find matching mailboxes and sends a warning message to any user whose password is about to expire. This tool lets Mac, UNIX, or even Windows 3.1 users receive password warnings. However, the bad news is that Win32 Outlook users receive two warnings: one from Outlook and one in their Inbox from PEWA.

I know I need to change the Lightweight Directory Access Protocol (LDAP) ports that Exchange Server 5.5 uses if I want to run Exchange Server 5.5 on a Windows 2000 machine. Do I need to make that change to Exchange Server 5.5 servers in the same organization that aren't running Win2K?

The requirement to change the TCP/IP port that the Exchange Server 5.5 Directory Service (DS) uses for LDAP traffic comes about because Win2K and the Active Directory Connector (ADC) both expect to use port 389 exclusively. You don't have to make this change to other Exchange Server 5.5 servers in your environment until you want to upgrade them to Win2K domain controllers or have them host the ADC. If you try to upgrade an Exchange Server 5.5 server to Exchange 2000 and you have previously changed the port number to something other than 389, the upgrade will fail unless you change the port number back. (Thanks to reader Rob Pescatore for this question.)

I'm using the Ed Crowley Server Move Method. How do I change the cost of my mail exchanger (MX) records?

First, if you don't know what the Ed Crowley Server Move Method is, run (don't walk) to http://www.exchangefaq.org/managing/0007.php3. (Hint: It's a painless method of moving users and data between servers.) One key to this method is changing the cost of the MX records that DNS uses to keep track of where to route mail bound for your domain.

The method you use to change the cost of MX records depends on the OS you're using. If you're running your DNS service with Win2K or NT, the DNS management software makes changing the cost of the records easy. If your DNS service is on a UNIX machine under your control, the changes are somewhat harder to make, but not much (depending on which UNIX version you're using). If you're not running your own DNS, your DNS provider must make the change.

My organization is fairly large, and most users keep their mail in Personal Folders (PSTs). However, the organization will migrate the files to the Information Store (IS) fairly soon. What's the most efficient way to accomplish the migration? I bet that Exmerge works best.

You win the bet. The most efficient way to move users' mail to the IS is to avoid the need to move it in the first place by not using .pst files. PSTs have many disadvantages: For example, you can't easily manage them centrally (e.g., for backups), they're not available for shared access, and they don't let you take advantage of server-based features such as single-instance storage and server-based rules. However, if you're stuck with .pst files, you can use Exmerge to speed up the migration. Exmerge is available from Microsoft Product Support Services (PSS); always call PSS to get the latest version before embarking on a major mailbox move. An alternative—if users will tolerate it—is to make users keep their PSTs as archive folders and not move any of the mail at all. (Thanks to reader Dave McCrosky for this question.)

We're trying to decide between the Enterprise and Standard editions of Exchange. What are the differences between the editions and the system requirements for each?

In both Exchange 2000 and Exchange Server 5.5, the Enterprise and Standard editions have significant differences. The biggest difference is that Standard databases are limited to 16GB of data, whereas the Enterprise edition databases can grow as big as your disks allow. The Enterprise edition also comes with the X.400 connector and supports clustering. The editions have other differences, too. For example, the Exchange 2000 Enterprise Server includes the chat service and supports front-end/back-end configurations and multiple storage groups.

As for OS requirements, Exchange Server 5.5 runs on any version of NT Server. However, if you want to use clustering, you need NT Server, Enterprise Edition. Likewise, Exchange 2000 runs on any of the Win2K Server family members, but clustering requires Win2K Advanced Server or Win2K Datacenter Server. (Thanks to reader Mike Fulton for this question.)

Senior management at my company is worried about the possibility of administrators' reading mail on the system. How can I safeguard against this practice? Are any auditing mechanisms available that can reveal snooping?

Exchange Server 5.5 uses a service account, under which all system services log on. Anyone who gains access to that account can read any message on an Exchange Server 5.5 server—the activity you're trying to avoid. The first step toward protecting mail is to make sure that no one has access to that account's username and password for that account. One popular approach is to split the password into two parts. Write each part in an envelope, seal it, sign the flap, then put one envelope in the CEO's safe and another someplace else. Exchange 2000 deals with this problem by not using a site service account; in addition, Exchange 2000 explicitly denies administrators access to other mailboxes.

As for protection against snooping, Exchange's Advanced Security features protect stored mail on the servers, but only if the sender chooses to encrypt the mail before sending it. Even if an administrator has permission to read the mailbox, encrypted mail appears as gobbledygook. For highly important mail, you can consider requiring the sender to use a third-party product such as Network Associates' PGP Security product line to encrypt the message. No solution is guaranteed—a really determined administrator can rifle the end user's machine, looking for telltale scraps of information.

With regard to auditing, Exchange logs an event ID 1016 whenever someone logs on to a mailbox of which he or she isn't the primary owner. However, this event doesn't give you network details (e.g., a workstation ID, an IP address), just an account name. Worse still, these events appear under legitimate circumstances, such as when the CEO's assistant opens the CEO's calendar. You might find it difficult to sift out illegitimate accesses from the many legitimate accesses, but if you're familiar with the access patterns of your network, you might have some success with this approach. (Thanks to reader C. M. Wong for this question.)

Our Exchange server is overloaded. When we reached 10.5MB of free disk space, the Message Transfer Agent (MTA) shut down. Even after we removed some mailboxes, only about 10MB is free, so the MTA won't start. How do I fix this problem?

By design, the MTA stops when it sees disk space fall below 10MB because stopping operations cleanly is always better than having an operation fail because of inadequate disk space. Just removing the mailboxes won't necessarily free up any disk space for two reasons. First, changes to the store result in Exchange applying transactions to the logs, and those transactions stay around until you do an online backup of your server. Second, after you perform a backup, you won't notice the store getting any smaller until you stop the IS service and use Eseutil to perform an offline defragmentation. (Thanks to reader Piyush Gajjar for this question.)