Exchange Server Troubleshooter - 24 Aug 2000

Read about secondary proxy addresses, Organization Forms replication, front-end/back-end servers, reducing priv.edb, messaging protocol bandwidth, spanning multiple domains, uninstalling Exchange 2000, the /forestprep switch, and chargeback accounting.

Paul Robichaux

August 24, 2000

7 Min Read
ITPro Today logo

Can I set up multiple user aliases in Exchange Server? I want to define multiple addresses for a mailbox so that when email arrives for bob@xyz.com, Exchange will look at alias entries for "bob" and find robert@xyz.com, rather than send me an inbound delivery failure report.

What you want is called a secondary proxy address, which is an additional address that attaches to an existing mailbox and that Exchange Server can resolve. For example, paul@
robichaux.net, [email protected], and [email protected] all reach the same mailbox on my server. You can use the E-Mail Addresses tab in Microsoft Exchange Administrator's Mailbox Properties dialog box to manually add secondary addresses to individual mailboxes. Or you can add these addresses to multiple mailboxes en masse by using the Secondary-Proxy-Addresses header attribute as part of a directory import. (Thanks to reader Harold Tengelin for this question.)

If I publish a form into the Organization Forms library, will Exchange Server replicate the form to all sites? If so, can I easily stop this process?

When you put a form in the Organization Forms library, Exchange Server replicates the form so that it's visible to all servers in all sites throughout your organization. To prevent such visibility, keep the form out of the library. Don't try to establish multiple Organization Forms libraries in different sites, or you'll experience exciting replication conflict adventures.

Can I use the version of Outlook Web Access (OWA) that comes with Exchange 2000 Server Release Candidate 2 (RC2) to put together an OWA/Microsoft IIS 5.0/Windows 2000 Server combination in a demilitarized zone (DMZ)?

Yes. This type of combination is called a front-end/back-end server configuration, in which the front-end server or servers directly handle client requests. Front-end machines don't have any mailbox or public-folder stores; those stores reside on the back-end servers. You want at least one front-end server in the DMZ, and you want that server to talk to the back-end servers in the protected part of your network.

Our Exchange server currently has a 34GB private Information Store (IS). Can we move user mail to personal stores (PSTs) to reduce the size of priv.edb?

You can, but first think about whether you want to. Start with the dubious assumption that everything in your 34GB store is important enough to keep. If you split up your store into PST files, you'll end up with more, not less, than 34GB of data. Exchange Server uses single-instance storage in the IS, so if you send a message to 25 people on one server, Exchange Server keeps only one message copy in the store. But if you use PSTs, Exchange Server keeps 51 copies: 1 copy in your Outbox and 2 copies (i.e., 1 plaintext copy and one Rich Text Format—RTF—copy) in each recipient's PST file. By using PSTs, you're only moving 34GB of centrally stored, regularly backed up and maintained data to your client PCs, where the data will be subject to corruption, user mistakes, and other vagaries (including PST-password intruders). You'll also have much more difficulty disinfecting virus outbreaks because you must track down and clean each PST.

If you need to make your IS smaller because you can't back it up or restore it in a reasonable time, help your users clear old junk from their mailboxes. If everything in the mailboxes is valuable, add a second server and move half your users to it. That situation would yield two 17GB stores, which isn't an unreasonable size. You could also upgrade to Exchange 2000 and split the mailboxes across two stores. This route might seem expensive, but it's more affordable than dealing with PST management headaches. (Thanks to reader Dot Harris for this question.)

Which uses the most bandwidth: Messaging API (MAPI), POP3, or IMAP4?

MAPI, by a significant amount. MAPI is a more flexible and capable protocol than either POP3 or IMAP4, but it also has the most on-the-wire overhead of the three protocols. When you look at the back-and-forth communications that each protocol uses to retrieve one 10KB message, you see an astonishing difference between MAPI and the other protocols. POP3 and IMAP4 add almost no overhead. (POP3, for example, requires only about 32 bytes to log on to a mailbox and retrieve that 10KB message.) MAPI, by contrast, can use several kilobytes before you even start downloading the message. (Thanks to reader Gilles Vanpeene for this question.)

I'm trying to remotely install a new Exchange Server 5.5 server to an existing site, which is in another domain at the other end of a WAN. Mutual trust exists between the domains. I'm logged on as Administrator. When I enter the name of the server in the existing site, the Exchange setup program says I don't have sufficient rights. What's happening?

The problem is occurring because the account you're using has administrative permissions on the domain but not on Exchange Server. You need to verify that the account you're using has permissions on the Exchange Server's site and organization containers.

As a side note, spanning multiple domains with a single Exchange Server site isn't an optimal situation because if the domains' trust relationship breaks, you'll be in for some bizarre behavior, including services that may refuse to start. If you can't flatten the domains (e.g., to prepare for a Win2K rollout), create a second Exchange Server site in the foreign domain, then use the site connector to link it to your site.

How can I cleanly uninstall Exchange 2000?

You can't at present. Microsoft admits to "some issues" (their words, not mine) with the uninstaller; Microsoft will probably fix these problems when, or after, it releases the final Exchange 2000 version. In the meantime, you can clean the local machine fairly well by following these steps:

  1. Stop the Exchange services.

  2. Remove all the MSExchangeXXX entries under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices.

  3. Reboot, and verify that none of the services started.

  4. Remove the Exchange subkey and all its subkeys from HKEY_LOCAL_MACHINESOFTWAREMicrosoft.

  5. Remove the binaries from program filesexchsrvr. Beware: This step might also remove your mail databases. Make sure to back them up first if you want to keep them.

Remember that this procedure removes Exchange Server from only the local machine; a lot of entries will still point to Exchange Server in Win2K Active Directory (AD) unless you use ADSI Edit to remove them.

Why must I use the /forestprep switch when I install Exchange 2000?

AD is, at heart, a big database. Sure, AD is highly optimized to quickly answer directory queries, but its schema reveals AD's true nature. The schema defines what objects can be in the database; specifies which attributes they can, can't, and must contain; and sets out the format for each attribute.

Because the schema controls the AD data and how that data looks, installing Exchange 2000 requires a substantial number of schema changes: approximately 1800 changes. The /forestprep switch lets you update the schema when it's convenient for you. When you make a schema change, AD must replicate it to all domain controllers in the forest. For a large site, you want to update the schema and propagate the changes before you install Win2K—and using /forestprep, you can.

In a Win2K forest, one computer is the schema master. This computer provides a central collection point for all schema updates in the forest. (Because each schema change must replicate, multiple schema changes on multiple computers are a recipe for disaster.) For best performance, run Exchange 2000 Setup, with the /forestprep switch, on the schema master.

What's the best way to perform chargeback accounting with my Exchange server?

Accounting, tracking, and billing mail usage within a company is a sure way to waste a lot of time for relatively little return. However, if the powers that be are forcing you to use chargeback, you can take a couple of routes.

One method is to roll your own tool that uses Microsoft Collaboration Data Objects (CDO) or Active Directory Service Interfaces (ADSI) to interrogate the store to get information about the mailboxes, then generates billing or chargeback information. This method is possible, but it isn't simple. As an alternative, you can use a commercial product, such as Tally Systems' Veranda, which has reporting features that can summarize mailbox size and usage, then generate billing reports from this information. As a compromise between these alternatives, you can use Seagate Software's Crystal Reports to talk to the store and generate data, then write code to interpret the data. (Thanks to reader David Presson for this question.)

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like