A few of my users are complaining that they received email messages that took hours—and sometimes days—to be delivered. How can I locate the source of the delay?

Figuring out where messages are getting stuck in a messaging system can be difficult. Of course, the more sites, servers, and connectors you have, the more complicated the problem is. Sometimes you can make an educated guess by examining the message originator and recipient. For example, if everyone who reports delays is on the same server, a reasonable starting point is to make sure that the Message Transfer Agent (MTA) and connectors on that server are configured correctly and that no errors are appearing in the event log.

To get a better systemic overview of message flow in your organization, you can use Exchange's message-tracking feature. When you enable message tracking on a server, the server logs each message that enters or leaves that server through the MTA or a connector, as well as messages that are locally delivered. To get a complete record of message flow, you must turn on tracking in three places in Exchange Server 5.5: the General tab of the MTA Site Configuration Properties dialog box, the General tab of the IS Site Configuration Properties dialog box, and the Internet Mail Service (IMS). The logs are plaintext files. Exchange automatically creates a share called tracking.log to store these files. Exchange generates a new log each day. In "How Message Tracking Works," June 1998, Tony Redmond explains how to read tracking logs.

Although you can search the logs manually, a better approach is to use the tracking tool that Microsoft includes in the Exchange Administrator program (for Exchange Server 5.5) or Exchange System Manager (ESM—for Exchange 2000 Server). The logs help you localize where the message last appeared, which can help you discern where a problem has occurred. The logs' format is different in Exchange 2000 and Exchange Server 5.5, so if you're using a third-party or homegrown tool to parse the logs, you might need to adjust the tool when you migrate.

One useful message-tracking feature specific to Exchange 2000 lets you also log the subject of each message as it's being tracked. You must enable subject-logging separately; the feature is on the same General tab as the message-tracking setting. Although this feature might expose information you don't want logged in some cases, it gives you an additional attribute to search by when you're hunting for a particular message.

We have a large multisite Exchange organization, which we built with hub-and-spoke replication topology. We migrated the central site to Exchange 2000, and now we're migrating the other sites, one server at a time. When can we safely remove the Site Replication Service (SRS) from the satellite sites?

In "The Site Replication Service," October 2000, Kieran McCorry describes this tool and its function. You must use the SRS whenever you have an organization in a mixed-mode Exchange 2000 site. If you have one or more Exchange Server 5.5 sites, you must have an SRS in each native or mixed site that has a connection to the Exchange Server 5.5 site. In your case, if you maintain an SRS in the hub site, you might think that you can remove the SRS in each satellite site as soon as you've upgraded all servers in that site to Exchange 2000. However, the SRS in each site has to read information about the site and server topology, then pass it to Active Directory (AD) through the Active Directory Connector (ADC). If you remove the SRS in a particular site, the Knowledge Consistency Checker (KCC) will locate a different SRS somewhere else and use its Configuration Connection Agreement (ConfigCA) to replicate site objects. At that point, AD no longer knows that objects in that site exist, so the ADC replicates them again with a different set of distinguished names (DNs). The Exchange Server 5.5 Information Store (IS) expects to see objects with a particular set of names. In particular, public-folder replication stops working if the name of the public store is anything other than Microsoft MDB—and when you remove the SRS and force re-replication, that is exactly what happens. In summary, removing the SRS in a migrated site causes public folder replication to stop on all Exchange Server 5.5 servers. This activity causes equally nasty side effects that involve duplicate routes in the Gateway Address Routing Table (GWART). In short, don't remove the SRS from your satellite sites. (Thanks to reader Matthew Tunnicliffe for this question.)

How does Exchange 2000 choose which Global Catalog (GC) it uses for directory lookups?

Ordinarily, Exchange 2000 randomly chooses a GC from the GCs available in the same AD site. If Exchange can't find a GC in the same site, it chooses one in a well-connected site by looking at AD's site topology. If you want Exchange to bind to a particular GC every time, you can create a new registry subkey called UserGC1 under HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\MSExchangeDSAccess\Profiles\Default and set its contents to two backslashes followed by the DNS name of the server (e.g., \\testGC.exchangeadmin.com). The choice of GC is important because if Exchange talks to a GC that has out-of-date information (e.g., if the GC is too slow to keep up with replication or if it has been offline for an extended period), you might see odd behavior, including seemingly spurious nondelivery reports (NDRs) and public-folder replication conflict messages.

I want to run a virus scanner on my Exchange server. Do I need to take any special precautions?

If you're going to run a virus scanner on your Exchange server, make absolutely sure that you don't scan the directories that contain your transaction logs or databases. Virus scanners generally disinfect or remove any files they encounter. In either case, if your scanner decides to disinfect or remove a transaction log or checkpoint file, this will lead to great unhappiness when you try to back up or recover your server because the data in those files will no longer match what the checksum files have recorded. If you're trying to protect mail data, not just the server's files, you need an Exchange-aware scanner. If you're considering migrating to Exchange 2000, make sure the product you choose is, or will be, Exchange 2000-compatible.

How can I retrieve the last logon or logoff times for a mailbox?

If you want to obtain logon or logoff times for a mailbox under control of a program you're writing, you must use the extended Messaging API (MAPI) interface to query the mailbox for two properties: PR_LAST_LOGON_TIME and PR_LAST_LOGOFF_TIME, which record the logon and logoff times, respectively. The Microsoft article "XCLN: How to Retrieve Last Logon Time of Exchange Users Using Extended MAPI" (http://support.microsoft.com/support/kb/articles/q259/5/70.asp) includes a code sample for retrieving the last logon time for all mailboxes on an Exchange 2000 or Exchange Server 5.5 server. A variety of third-party reporting tools can retrieve logon and logoff times, too.

I have an Exchange Server 5.5 server in one site. Can I move it to an Exchange 2000 organization without rebuilding it and losing all the mail?

One way to accomplish your goal is to move the mail with Exmerge, but that method loses Inbox rules and single-instance storage. You can't use the Move Server Wizard (MSW) in a pure Exchange 2000 organization, but you can use MSW if you install an Exchange Server 5.5 server in the Exchange 2000 organization (which you can do only while you're in Exchange 2000 mixed mode). This method works because the MSW communicates directly with the Exchange Server 5.5 Directory Service (DS), so if no DS is in the organization, you can't use the wizard. Adding an Exchange Server 5.5 server will make its DS visible to the MSW, and the move will go fine.

What's the best way to archive users' mail?

The cheapest way to archive users' mail is to use Personal Folders (.pst files) and make your users archive their mail manually. However, this approach has two primary drawbacks. One disadvantage is that users don't always do what you ask them to do, so they might not archive their mail. The other drawback is that you can't use .pst files directly from read-only media such as CD-ROMs. That's too bad, because the ideal low-budget archive solution would be to make a .pst file every 6 months, then transfer it to a CD-ROM.

Your other option is to investigate solutions such as KVS's Enterprise Vault, IXOS Software's IXOSExchangeARCHIVE, or CommVault System's Galaxy. These solutions typically offer flexible archiving features, but their cost might put them out of reach for your situation. Outlook's archiving options are another possibility.

I need to defragment an Exchange Server 5.5 Service Pack 3 (SP3) database. Windows Explorer reports the database size as 20GB, but I think it has only about 12GB of data in it. How much free space do I need to perform the defrag?

Microsoft recommends that you have as much free space as the disk space utilization of the database you're defragging. You can check the event log for event ID 1221 to see what the online defrag engine says about space utilization, or you can stop the IS and check the file sizes again in Windows Explorer (although this action forces you to stop the services). You might be able to get away with defragging a 20GB database in only 12GB of disk space, depending on how much white space is in your database. Don't forget to make and verify a backup before doing the defragmentation in case something goes wrong; perform another backup afterward, because your log files will no longer be usable. (Thanks to reader Andrew Parkinson for this question.)

How can I configure a new Exchange server for company-x.com while a different mail system is handling company-x.com's mail?

People perform this task all the time. The trick is to remember that Exchange doesn't care what MX records point to it. If you have in your DNS server an MX record that points mail for company-x.com to your existing server, you can still set up Exchange 2000 or Exchange Server 5.5 to send SMTP mail and to accept it for the company-x .com domain. However, until you modify the MX record to point to the Exchange server, no mail will be sent there. This approach is equivalent to installing a mailbox at your house while your mail is forwarded to a post office box—until you unforward it, no mail will arrive in your new mailbox. (Thanks to reader Stuart W. Brown for this question.)

I set up a test Exchange 2000 server and was trying to poke around the M drive, but nothing seems to be there. What's happening?

This behavior is by design. The Exchange Installable File System (ExIFS) driver creates the M drive and maps the contents of the store into it. Therefore, on a newly installed server, you can see the M drive, which will have a subdirectory with the name of your AD domain (e.g., M:\entirenet.net). Under that directory are the mbx and public directories; mailboxes usually appear under M:\domain\mbx. However, until you create at least one mailbox on the server, nothing will appear there in that directory. After you create mailboxes, you must send a message to each mailbox (or log on to it through Outlook Web Access—OWA—or Outlook) before the corresponding directory will appear.

I'm using an Exchange 2000 server as an SMTP relay host. How can I maximize its throughput?

With a quad-Pentium III server, Microsoft reports performance in excess of 120 SMTP messages per second—that's a lot of mail! However, you might not need to buy new hardware; a couple of less-expensive routes are available. One option is to ditch Exchange 2000 and use the Windows 2000 SMTP service. The Win2K service is less capable than the Exchange 2000 version, but it's also somewhat faster. If you're just relaying SMTP mail, this solution will do the trick. If you want to continue using Exchange 2000, putting the SMTP virtual server's queue directory on a RAID array will boost performance. Unfortunately, you can't change the SMTP directory from within ESM, although you can change the directory by directly editing the metabase. The Microsoft article "XADM: Cannot Change SMTP Directories in Exchange System Manager" (http://support.microsoft.com/support/ kb/articles/q257/8/35.asp) gives detailed instructions for effecting these changes. (Thanks to David Lemson for the suggestion.)

Where can I obtain the Microsoft Exchange and Collaboration Solutions Conference (MEC) 2000 presentations?

If you attended MEC 2000, you should have received a URL from which you can obtain the presentations. You'll need your conference ID and password to log on. If you didn't attend, you can download the presentations from Microsoft's Exchange Web site.

Our company is going to use Exchange 2000 servers and Outlook 2000 clients. Do you know any requirements or recommendations for network bandwidth depending on the number of clients?

The best way to gather this data is by monitoring your network traffic. The detailed white paper "MS Exchange Implementation: Client Traffic Analysis" (http://www.microsoft.com/technet/ exchange/technote/trafanal.asp) provides good background for planning your system. Although the paper refers to earlier versions of the client software, the IMAP, POP, and MAPI protocols haven't changed since then, so the paper's comments about bandwidth usage are still valuable.