The Exchange Server Troubleshooter - 01 Oct 1999

The question I receive most frequently is "Is it OK to send you questions?" Of course, it's OK—I welcome your questions. The newsletter's goal is to provide you with the information you need to do your job, so I need to hear what problems you're grappling with. Just write me at [email protected].

Another valuable resource for you is the excellent list of Exchange FAQ that Internet Mail Service (IMS) guru Andy Webb has assembled at http://www.swinc.com/ resource/exch_faq.htm. Webb continually expands the list to answer new problems as they crop up.

Finally, here's an important security alert: Microsoft Security Bulletin MS99-025 (http://www.microsoft.com/ security/bulletins/ms99-025.asp) describes a serious vulnerability in servers that have Remote Data Services (RDS) installed. The vulnerability can let a Web site visitor take unauthorized actions on a site hosted with Microsoft Internet Information Server (IIS), which means your Outlook Web Access (OWA) server might be at risk. NTBugtraq (http://ntbugtraq.ntadvice.com/ default.asp?sid=1&pid=47&aid=47) has complete coverage of the problem and a checklist for securing your IIS machines.

How can I forward all of a user's mail to another email address?

The approach depends on your goal and the limitations you're willing to put up with. The easiest way to forward mail is to set up a client rule that lets the user forward all incoming mail somewhere else. This solution ensures that all incoming mail goes to the new recipient, but the drawback is that the original user must stay logged on to the server or Exchange won't forward the mail. Another technique is to add the new destination mailbox as an alternate recipient to the original mailbox; however, this technique works only for mail destined to another Exchange mailbox.

Usually, people want to forward mail sent to an Exchange mailbox to an external address, such as an Internet email account or an email-capable pager. In that case, the proper solution is to create a new custom recipient for the target address, then add the custom recipient as an alternate recipient to the original mailbox. You add the custom recipient on the Advanced tab of the original mailbox's Properties page. (For best results, hide the custom recipient from the Global Address List—GAL—so no one sends mail directly to it.)

After restoring my public Information Store (IS) to a test server, I noticed that some public folder information is wrong—the folder instances aren't in the same order on all the servers. None of the diagnostic tools report any errors, but errors 172, 173, and 174 appear in the event log. Could the public IS have some corruption that Isinteg and Eseutil haven't caught?

Exchange generates those event IDs when the Exchange database engine (Extensible Storage Engine—ESE) detects that the underlying version of Windows NT has changed. For example, if you back up the public IS on a machine running NT 4.0 with Service Pack 3 (SP3) and restore the IS on a machine running NT 4.0 SP5, ESE detects the change and rebuilds the database indexes to prevent corruption. If the errors you mentioned are the only errors you see in the log, you're OK. (For details about the problem, see the Microsoft article "XADM: WinNT Version Change May Cause Exchange DB Indexes To Be Rebuilt" at http://support.microsoft.com/ support/kb/articles/q215/2/97.asp.)

How do I restrict the amount of bandwidth the IMS uses? I don't want Internet mail using all our bandwidth.

You can't limit bandwidth at the IMS level. The IMS only opens TCP/IP connections to other sites, and it doesn't have any concept of the amount of bandwidth it's using. The IMS will use as much as it can get, just like any other TCP/IP service will. If your routers support the Quality of Service (QoS) extensions, you might be able to configure your system so that SMTP traffic receives a lower priority than other traffic types. (See your router documentation for details about changing this configuration.) However, this adjustment has nothing to do with the IMS. An acceptable workaround might be to limit the size of messages the IMS can accept.

Despite many warnings to the contrary, I deleted the X.400 addresses on some mailboxes. Now, incoming and outbound mail for those mailboxes is hopelessly messed up (e.g., we get nondelivery reports—NDRs—for valid addresses that used to work). How can I fix the problem?

Because you've probably suffered enough already, I won't lecture you about deleting X.400 addresses in the future. To recreate them, open the Site Addressing object in the Configuration container from the Microsoft Exchange Administrator, select the Site Addressing tab, make a small change to the content of the X.400 address, then click Apply. This action forces Exchange Administrator to go out and give every object in your directory a new X.400 address. When it finishes, change the X.400 address back to its correct form, then let Exchange Administrator reapply the proper addresses to all the directory objects. (Reader Ed Crowley points out that the content of the X.400 addresses doesn't matter unless you're using an external X.400 provider—what matters is that every object must have an X.400 address.)

The government agency I work for must comply with an open-records law that mandates long-term email retention. This requirement is a problem because the agency can't afford to keep deleted items around forever in the dumpster. What practices can you suggest?

Making your Exchange server compliant with these laws creates serious overhead. Your best bet is to investigate a system such as Compaq Enterprise Vault (http://www.compaq.com/products/ software/ntenterprise/ vault/index.html) or the CommVault product line from CommVault (http://www.commvault.com/ com_hg_exch.htm). These products can store every message ever generated (on optical media or regular disks), then keep an up-to-date index so you can find even very old messages. Optical storage is expensive, but because you can use other media, you might be able to engineer a relatively inexpensive solution. Happy hunting!

Is a tool available to move mailboxes between recipient containers?

No, once you create an object in a container, it's stuck there forever because the recipient container name is part of the object's distinguished name (DN). The only way to move a mailbox, distribution list (DL), or custom recipient from one container to another is to delete it from the original container and recreate it in the new one.

However, you can obtain tools that automate the delete-recreate process. One such tool is Exmerge; you can obtain the latest version from Microsoft Product Support Services (PSS). However, the delete-recreate process might cause you to lose some useful attributes (e.g., public folder permissions, rules) when you delete the old mailbox. Your best bet is to be wary of creating objects in any container other than Recipients unless you're sure you'll never have to move them. Instead, you can create multiple Address Book Views (ABVs) to simulate having multiple containers in your GAL.

I want to keep a public folder with contact information in it, then query the folder via Lightweight Directory Access Protocol (LDAP). That way, my Outlook users can use Outlook to manage contacts, and non-Outlook users can search and modify contact information with LDAP clients such as Netscape Communicator. Is this solution feasible?

Exchange Server stores public folders in the public IS, not the directory. When an incoming LDAP query arrives, the Directory Service (DS) handles it, so you can search only for directory objects. Your public folders of contacts aren't in the directory, so you can't see them through an LDAP client. You can write some code to access the contacts via Active Directory Service Interfaces (ADSI). The code is simple, but it won't work for non-Windows clients. You can give non-Windows users read-only access to the public folder by enabling IMAP4 on your servers.

We're auditing our servers and removing or disabling accounts and mailboxes that we no longer need. Can we use a utility to disable accounts and mailboxes in batches or from the command line?

Yes, although you have to use two separate methods. First, let's talk about disabling accounts. Most administrators disable accounts with NT's User Manager for Domains, but you can also use the underappreciated Net User command with the /active switch. For example, to turn off an account named bjones, enter

net user bjones /active:no /domain

The /domain switch is important because it tells Net User to make the change on the domain controller, not the local server.

After you've deactivated the account, you need to hide the corresponding mailbox from the GAL. You can do this manually by selecting the Hide from address book check box on the Advanced tab of the mailbox Properties page, but that process is a lot of mousework when you have to disable many mailboxes. Instead, use the directory import tools built into Exchange Administrator. Include a field named Hide from AB in your Comma Separated Values (CSV) file, then give the field a value of 0 to show the entry or 1 to hide it. The really cool thing about this technique is that when you use the Tools, Directory Export command to export a list of mailboxes, the needed field is already there—just load the CSV file into Microsoft Excel, change the Hide from AB value to 1 on the mailboxes you want to hide, reimport the file, and you're in business.

I need to move my transaction logs to another disk because they keep filling up the partition they're on now. What's the best way to move the logs?

You've hit on the only real drawback of Exchange Server's transaction-oriented architecture. Because each change to the IS databases generates a transaction in the transaction log files, anything that makes lots of changes to your IS (e.g., a mail loop, moving lots of mailboxes) will make your log files balloon in number; because each log file is 5MB, adding a lot of log files can use up disk space quickly. If you don't have enough space on the disk where you store the log files, the IS writes an error message in the event log and shuts down. When this situation occurs, you have a problem—deleting log files manually isn't a good practice, but if you don't make more space available, you can't restart the IS.

You can prevent this problem by performing daily online backups using an Exchange-aware backup utility (e.g., Ntbackup). The backup process automatically removes log files. If the log files aren't disappearing, you're not getting good backups and you need to check your event logs for errors. However, when this space squeeze occurs, three actions will help correct the problem:

  1. Clean up unnecessary files on the log drive. Be very careful if you choose this route—don't delete any log files. If you follow the recommendation of putting your log files on a separate physical disk, no other files might be there, so this step might not help unless your logs are sharing disk space with some unrelated files.
  2. Use the Performance Optimizer to move the log files to another drive. If you need to move them, this action is the only safe way to do so—don't do it manually, and don't edit the Registry key that shows where the files are. The IS databases contain references to the log file paths, so if you move log files manually, you're heading for trouble.
  3. Extend the log drive's partition, but only temporarily, by creating a volume set. I learned this neat trick from Andy Webb. To create a volume set, you need to install an extra physical disk in your server (because you've already stopped your IS, the installation won't be a problem). Add the disk, then follow these steps:

    • Launch the NT Disk Administrator. Partition the new disk if you need to, but don't format it. Note that you can build volume sets only on NTFS volumes, so you need to convert your log drive if it's still FAT.
    • Select both the current log drive and the new drive (select both drives while holding down the Ctrl key) to tell Disk Administrator that you want to perform an action on multiple drives.
    • Use the Partition, Extend Volume Set command. This command tacks the free space on your new drive onto the end of your existing log drive. When you tell Disk Administrator how much space from the new drive to weld onto your log drive's volume, you'll be set.
    • After you've added space, restart Exchange and perform an online backup to remove the log files. While the backup is executing, identify what's making the logs grow so fast; if it's a mail loop, fix it to keep the same problem from recurring.
    • After the online backup completes, shut down the IS and DS and perform a full offline backup for safety's sake.
    • Break up the volume set with the Disk Administrator's Partition, Delete command. Note that this command deletes all the data, so make sure you have a good backup first.
    • Use Performance Optimizer to move the log files to the new drive if the new drive you installed is larger than the old one.
Hide comments

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