The Exchange Server Troubleshooter - 01 Mar 2000

The Exchange Server Troubleshooter

When does using a separate connector server make sense?

In Exchange parlance, a connector server is a server that hosts connectors (e.g., the Internet Mail Service—IMS, Lotus Notes connectors, third-party fax or integrated messaging connectors) without hosting any mailboxes or public folders. Connector servers let you centralize some or all of your connectors on a smaller, less powerful server, while keeping the big iron available for your mailbox and public folder users. Splitting up servers this way has some benefits, apart from the potential performance increase. One benefit is that you can provide redundant connectors more easily—you just add several cheap servers to your existing site and install the IMS on them.

One important benefit is that connector servers don't have to use the same type of sophisticated disk and storage subsystem that you need on mailbox servers, primarily because messages passing through the connectors are transient. For the same reason, you don't need fast backup solutions. Therefore, connector boxes don't have to be expensive servers.

Another benefit is that load-balancing incoming mail is easier because you can use the free Microsoft Windows NT Load Balancing Service (WLBS). The regular Exchange routing algorithms automatically handle outgoing mail.

A less obvious benefit is that putting troublesome connectors (such as some third-party fax products and even the IMS) on separate machines means that when you need to reboot a server to fix a balky connector, you don't affect mailbox users. Likewise, if you need to add or remove a connector, or even swap out an entire server, you minimize the effect on users. Finally, putting connector servers in separate sites lets you build an administrative wall between mailboxes and connectors so that different people can manage mailboxes and connectors.

How can I customize the appearance of the Outlook Web Access (OWA) logon screen?

Because Microsoft implements the Exchange Server 5.5 version of OWA as Active Server Pages (ASP), you can customize the pages' appearance by editing the files in the exchsrvrwebdata subdirectory that matches your language. For example, if you're in the United States, open exchsrvrwebdatausalogon.asp and you'll see the familiar yellow logon page. You can change the page as often as you like. However, remember that Microsoft has completely rewritten the Exchange 2000 Server version of OWA, so don't expect your changes to either be necessary or operational when you migrate. Also, remember to keep good backups of the webdata subdirectory because service pack installs might not preserve its contents.

How can I identify the party who deleted my boss' mailbox?

Ah, nothing like a little forensic Exchange administration! The answer to this thorny question comes in two parts: finding the server where the changes were made, then pinning down the perpetrator. Every object on an Exchange server—mailbox, public folder, connector, organization—has an entry in the Exchange directory. Each directory entry, in turn, has attributes that the Directory Service (DS) uses to keep track of when the object was modified and replicated.

In this case, you need to check two attributes: Invocation-ID and DSA-Signature. Each server has a unique ID that Exchange stores in the Invocation-ID attribute. Each object in the directory also has a DSA-Signature attribute, which contains the Invocation-ID value of the last server to make a change to that object. Think of the DSA-Signature as a fingerprint. To obtain this valuable clue, use the Microsoft Exchange Administrator program's raw mode, open the raw properties of the object you're interested in, and write down the DSA-Signature value. To match the long hexadecimal DSA-Signature with a server name, open the raw properties sheet for your site object (the sheet will include your site's name), then check the Reps-From attribute (scrolling its contents if necessary). Each line of the Reps-From attribute in a site contains several fields; the last field on each line is the server name, and the next-to-last field is the Invocation-ID for that server.

Knowing the server from which the change was made might or might not help you pinpoint the culprit. You can also use diagnostic logging to help unmask the culprit. When you turn on security logging for the Exchange DS (by opening the target server's properties sheet, switching to the Diagnostics Logging tab, and using the logging controls to set Security logging to maximum), the Exchange DS will log event ID 1053 whenever someone changes an object. Check the event log for security event ID 1053 generated by MSExchangeDS; each 1053 message will contain the logon ID of the user who made the change. The Microsoft article "XADM: How to Find What User Is Deleting or Editing Objects in Administrator" (http://support.microsoft.com/support/kb/ articles/q183/6/74.asp) has details about this process.

I want to use the Tools, Move Mailbox command to move about half our users to a new server. How can I make sure this process goes smoothly?

The Move Mailbox command is pretty slick, considering the amount of labor it saves you. Each mailbox has a distinguished name (DN), and part of the DN is the name of the site where the mailbox resides. To move a mailbox between servers in different sites, you have to manually export all its mail to a Personal Folder (.pst file), delete the mailbox in the original site, recreate it in the new site, and import the mail. Following that laborious manual process is the only way to make sure you update all the appropriate object names. When you move a mailbox between servers in the same site, the Move Mailbox code performs the same process, only automatically. It even fixes the Home-Server attribute for the mailbox, so Messaging API (MAPI) users automatically get their profiles updated the next time they log on. Move Mailbox preserves single-instance storage whenever possible, too.

In an ideal world, you'd move user mailboxes only when the users aren't around. Sometimes, though, circumstances require you to move them during hours when users are accessing their mailboxes. Generally, a polite request to not access the mailbox works well with most users, but a few always either don't get the word or don't think it applies to them. Even though technological solutions seldom work for interpersonal problems, one trick you might use is to restrict logon permissions to the Information Store (IS). Refer to my explanation in my September 1999 column; the Microsoft article "XADM: How to Prevent Logons during Move Mailbox" (http://support.microsoft.com/support/kb/articles/q218/9/20.asp) provides the details.

If you encounter a mailbox that won't move, make sure the user is logged off. If it still won't move, the mailbox probably contains a corrupt message. If it does, you'll have to export its contents by hand and reimport them to the target server.

We just installed OWA. My users love it, except for having to type their logon domain into the authentication dialog. Can I eliminate that requirement?

Don't you love it when you can provide some feature that makes users bubble over with joy? Most people usually like OWA but find it annoying to have to type their logon domain into the authentication dialog. The fix for this problem is simple: Use the Internet Service Manager (ISM) application to set the default domain for the Exchange virtual directory to the domain your users' accounts are in.

I'm debating whether to apply Exchange Server 5.5 Service Pack 3 (SP3) to our servers that contain our employees' mailboxes. I'm apprehensive about the long list of problems with hotfixes listed in the Microsoft article "XADM: Exchange Server 5.5 Post-SP3 Information Store Fixes Available" (http://support.microsoft.com/support/ kb/articles/q248/8/38.asp). What's your opinion?

Service packs are a double-edged sword. On one hand, they always include necessary fixes and frequently contain desirable functionality as a bonus (such as the new, and quite nice, Mailbox Manager in SP3). On the other hand, every service pack has thorns, and SP3 is no exception. The Microsoft article you cite and its companion "XGEN: Updates to the Exchange Server 5.5 SP3 Release Notes (http://support.microsoft.com/support/kb/articles/q235/4/52.asp) point out some serious problems. Are the fixes worth the potential downside?

In general, I advise administrators to test service packs on lab systems before installing them on production servers. Testing is especially valuable if your lab configuration closely matches your production configuration because the similar configurations let you be more confident that your results will carry over outside the lab. I also recommend keeping a close watch on mailing lists, such as the list maintained at http://www.swynk.com, to find out what problems early adopters have run into.

In the specific case of SP3, unless you're worried about one of the problems in the Microsoft articles, go ahead and install it. However, be sure to install the post-SP3 hotfixes and run the Performance Optimizer after you perform the install. (Thanks to reader Dave Cole for this question.)