The Exchange Server Troubleshooter - 29 Nov 1999
The troubleshooter discusses changing user names, connectors, message journaling, database attribute names, the Last Logon Time, tracking users who exceed mailbox limits, deleting logging files, virus scanners, OWA, and Mapisend.
November 29, 1999
I have a user who changed her last name. I renamed her mailbox, but the directory name on the Advanced tab still has her previous name. How can I change the directory name?
You can't. The directory name is like the serial number on a dollar bill—it uniquely identifies only one object. For some objects (e.g., an X.400 connector object), you can specify the directory name when you create the object. For other objects, various Exchange DLLs assign the directory name. After you or an Exchange DLL assigns a directory name, you can't change it. However, although you can't change a directory name, you can change your user's mailbox alias and display names because Exchange components use the directory name for internal purposes only.
I have only about 100 users. Can I keep my connectors on my primary mailbox server, or do you recommend that I put the connectors on a separate server?
You can keep your connectors on the primary mailbox server, but that setup isn't optimal. In a perfect world, you'd never need to reboot a server to fix a malfunctioning or stuck connector or apply a hotfix or patch. In reality, though, connectors (whether from Microsoft or third parties) have a higher failure rate than the core components. Thus, putting your connectors on a separate server gives you several important benefits:
You can reconfigure, update, or move connectors without touching your mailbox servers and interrupting your users.
You can easily and inexpensively improve redundancy by adding multiple connector servers. In many environments, an inexpensive, old Pentium box can serve as a backup Internet Mail Service (IMS) or Lotus Notes connector server.
You can move mailboxes or public folders to a connector server as a temporary measure in an emergency.
If you have two instances of each type of connector, you can reboot, reinstall, reconfigure, and tweak your connector servers, which is a wonderful change from the usual requirement of keeping your hands off servers during the workday.
After I installed Exchange Server 5.5 Service Pack 2 (SP2), I enabled message journaling for my company's site. However, some messages that went through the IMS aren't in the journal. What happened?
By default, journaling catches only messages that pass through the Message Transfer Agent (MTA). Messages that users send to public folders and system-generated messages such as nondelivery reports (NDRs) and replication messages don't pass through the MTA. However, messages that users submit and receive pass through the MTA, provided that you enabled journaling on the server containing users' mailboxes and that Messaging API (MAPI) clients submitted or received those messages. (For an explanation of message journaling, see Mark Ott and Greg Dodge, "Enabling Message Journaling on Exchange Server," December 1999.)
If your journal doesn't include messages that you think should be in there, investigate these possibilities:
You can enable journaling at the organization, site, or server level. Make sure you haven't forgotten to enable journaling somewhere you intended to.
If your users have access to external SMTP servers, make sure they aren't routing messages around your servers.
If you want to ensure that Exchange journals all messages, you can force the private Information Store (IS) to route its messages through the MTA. To do so, add a REG_DWORD value named No Local Delivery to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersPrivate key. Set the value to 1.
The IMS won't journal messages that pass through it unless you add a Registry value. Add a REG_DWORD value named RerouteViaStore to the IMS settings at HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeIMCParameters. Set the value to 1, and restart the IMS. If you set this value but not the No Local Delivery value, you might miss some messages.
I'm writing Microsoft Active Directory Service Interfaces (ADSI) code to retrieve items from the Exchange directory. What's the quickest way to find the names of specific database attributes?
Until you memorize the entire X.500 database schema, you can use Microsoft Exchange Administrator in raw mode to see the Lightweight Directory Access Protocol (LDAP) names for attributes. Here's what to do:
Run the Exchange Administrator program (exchsrvrbinadmin.exe) with the /r switch to access the raw mode.
Select View, Raw to access the raw-mode displays.
Double-click the Schema object in the container pane to expand it. The contents pane will fill with a list of Schema objects.
Find the object whose LDAP name you want to know in the contents pane, then double-click it.
Note the attribute value in the Description field. That value is the LDAP name for the object.
I give management a monthly report on all the Exchange mailboxes that haven't logged on within certain parameters. Exchange Administrator records the last time each user logged on to the server, but I can't find the Last Logon Time attribute in Exchange Administrator's raw mode. How can I export this logon information?
Exchange stores Last Logon Time information for each mailbox, but Last Logon Time isn't a mailbox attribute—that's why it doesn't show up when you use Exchange Administrator's raw mode to look at the mailbox attributes. However, you can see the Last Logon Time column in the Mailbox Resources object, which you can find beneath the private IS container of a server in your site. After you're in this view, use Exchange Administrator's Save Window Contents command under the File menu to dump the mailbox data to a text file. Then use a script to parse the text file.
You can also use the Microsoft BackOffice Resource Kit's (BORK's) Crystal Reports tool to generate your report. Using Crystal Reports takes a little more effort, but it can give you a great deal more flexibility.
How can I obtain a list of users whose mailboxes are over the size limits I've specified on the private IS?
If you want to know the users who have exceeded the limit during a particular time period, you can force the IS service to record messages in the event log by increasing the logging level for the Storage Limits item. Follow these steps:
In Exchange Administrator, select the server whose logging settings you want to change.
Select File, Properties to open the server's Properties sheet. Select the Diagnostics Logging tab.
Expand the MSExchangeIS object, then expand the Private item.
Select the Storage Limits item, and set the logging level to Maximum.
Click OK or Apply to apply the settings.
After you set the logging level, the private IS logs three events:
Event ID 1077, which lists users who are over the issue warning limit
Event ID 1078, which lists users who break the prohibit send limit
Event ID 1218, which lists users who exceed the prohibit send and receive limit
In conjunction with changing the logging settings, you might consider changing the storage-warning interval. After you set the size limit on the private IS, a background IS maintenance task regularly generates warning messages (and turns on the prohibit send flag when appropriate). By default, this task runs daily, but you can change that interval by opening the IS Site Configuration object's Properties page and changing the schedule on the Storage Warnings tab.
Another way you can obtain a list of users whose mailboxes are over the size quota is to use the same technique I described in my answer to the previous question. However, instead of extracting the Last Logon Time information in the Mailbox Resources object, you extract the details of the mailbox size. You can then import the mailbox size information into Microsoft Excel and compare that size against the size limit. The advantage of this method is that you can sort and highlight offenders.
I've enabled circular logging and perform a full backup nightly. However, my exchsrvrimcdatalog directory contains many large, old files. What are these files, and how can I get rid of them safely?
The exchsrvrimcdatalog directory holds the log files that Exchange generates when you turn on (or up) the level of diagnostic logging for the SMTP protocol. You can safely remove all the files in this directory, but only after you stop the IMS. I recommend that you follow these steps:
In Exchange Administrator, select the IMS.
Select File, Properties to open the IMS Properties page.
Select the Diagnostic Logging tab, and reduce the logging level for the SMTP Protocol Logging item to None.
Stop the IMS.
Remove the files.
Restart the IMS.
In past columns, you've suggested using a server-based antivirus package in conjunction with desktop- and firewall-based scanners. However, one of my administrators tells me that Microsoft recommends against using virus scanners on Exchange servers. What's the story?
Two types of virus scanners exist (at least for the purposes relevant to this situation): file-based scanners (which open individual files on a disk and scan them) and Exchange-aware scanners (which access messages through public APIs that Microsoft has defined). If you run a file-based scanner on your Exchange server, the scanner might decide to "repair" a transaction log or database file, with potentially disastrous results. In contrast, Exchange-aware scanners look at individual messages in the store, altering the message contents only through Exchange-safe methods. Microsoft's warning specifies that you must not use file-based scanners on an Exchange server; more specifically, you must not let them scan any area where Exchange stores its data.
How can I add a Sent Items folder view to Outlook Web Access (OWA)?
You must modify the Active Server Pages (ASP) files that OWA delivers. You need to customize the messages.asp file that comes with OWA, then add a new file that creates and displays the view. For complete details about this procedure, see the Microsoft article "XWEB: How to Create a Sent Items View in Outlook Web Access" (http://support.microsoft.com/support/ kb/articles/q237/4/30.asp).
I configured my Exchange server to accept SMTP mail for three independent domains. Mail reception works fine with one exception: I don't get mail sent to the postmaster address on two of the three domains. How can I fix this bug?
This situation isn't a bug—it's a feature. When you enable the IMS on your server, you use the Internet Mail tab of the Internet Mail Connector object's Properties page to link a mailbox to the postmaster mailbox for whichever domain you added support for first. To get mail for the other two domains' postmaster mailboxes, you need to add secondary SMTP addresses to those mailboxes.
To add the secondary address, select the mailbox you want to add the address to and open its Properties page. Select the E-Mail Address tab, and click New. Specify that you want a new Internet mail address, and type [email protected].
What utility can I use to send mail to an Exchange recipient from the command line?
Several utilities are available. The utility you choose will probably depend on how you prefer to send mail. The BORK includes the Mapisend utility (formerly known as Sendmail). Mapisend uses a MAPI profile to log on and send mail through the private IS. Because Mapisend acts as a MAPI client, Mapisend requires you to use logon credentials that have access to a MAPI profile.
From a security standpoint, this requirement is undesirable. Thus, as an alternative, I recommend that you use Infradig's Postie (http://www.infradig.com/index.shtml). Postie sends mail through SMTP (and can retrieve it with POP3, too), so you don't have to provide any logon credentials to get your mail sent. As a bonus, Postie comes with source code and versions for UNIX machines. Postie is free for personal use and $125 for commercial use.
About the Author
You May Also Like