I want to use the /forestprep and /domainprep switches with Exchange 2000 Server. What permissions do I need?
When you install Exchange 2000 for the first time, you need to take two preliminary installation steps: You need to prepare the forest that will contain Exchange 2000, and you need to prepare each domain in which you plan to install Exchange 2000 servers. To accomplish these tasks, you can use the /forestprep and /domainprep switches with the Exchange 2000 setup.exe program, which requires some elevated permissions.
To run /forestprep, Exchange 2000 requires that you use an account that is a member of the Enterprise Admins and Schema Admins groups. These permissions are necessary because /forestprep makes more than 900 changes to the forest's Active Directory (AD) schema. The account you use must also be a member of the Administrators security group and have administrative privileges on the machine you use to run /forestprep. The /domainprep operation involves creating two new security groups (Domain EXServers and All Exchange Servers) in the domain; each Exchange 2000 server that you add to the domain will be added to these groups when you first install Exchange. The /domainprep switch requires that you be a member of the Domain Admins security group for the domain you're preparing. You must also have administrative privileges on the computer on which you run /domainprep.
How do I change the service account in Exchange 2000?
You don't need to change the service account. Exchange 2000 services all run in the system's security context, more widely known as the LocalSystem account. To verify the security context, open the Microsoft Management Console (MMC) Computer Management snap-in's Services node and look at the properties for a particular service, such as the Information Store (IS). Although technically you can change this behavior and make the Exchange 2000 services run under some other context, doing so is a bad idea because you might break authentication for that service. In addition, not needing a service account any more is a boon—ending potential problems that you might encounter when you use the account across domains. The OS automatically changes the password for LocalSystem every 7 days, which is probably more often than you would change it. Best of all, the absence of an all-powerful service account means that no one can log on and simply read any mailbox on the server. One complication is that in a mixed-mode Exchange site, you'll still have a service account for your Exchange 5.5 servers, and all the usual complications and requirements that accompany the use of the service account still apply.
My Exchange Server 5.5 server has 1.2GB of RAM. How big should my pagefile be?
For Exchange Server 5.5, Microsoft recommends that you set your paging file size to the amount of your server's physical RAM plus 125MB. Depending on your disk configuration, you might want to consider using two pagefiles on two physical disks—assuming that you can put the pagefiles on disks that don't contain the databases or transaction logs. You can, however, typically put the pagefile on the same partition as the OS. (Thanks to reader Simon Galloway for this question.)
One day recently, every time I tried to open Microsoft Outlook 2000 I received a mailbox corrupted error. I can't find anything out of the ordinary in the event log. Should I be worried?
This kind of message can be pretty unnerving, particularly on a server that's been working fine. In your case, Outlook reported the error when it attempted—and failed—to open a mailbox. This message doesn't necessarily mean that anything is seriously wrong, though you should examine the event logs for errors or warnings as soon as Outlook starts to complain. Most likely, your mailbox had some problem with its logical structure that Outlook couldn't handle. Running Isinteg—with the test switch only, please—might confirm a problem, at which time you can consider how to carefully fix that problem. In the meantime, please be sure to make regular backups and confirm that you can restore them when needed. (Thanks to reader Ed Avila for this question.)
Can I keep users from autoforwarding their messages to an Internet account?
I don't know of any way to prevent this behavior. Of course, external forwarding isn't necessarily wrong—until it causes a mail loop. Consider the following scenario: Joe User forwards his mail to an MSN Hotmail mailbox. This arrangement works until the Hotmail box fills up, at which point each new message to Hotmail generates and sends a nondelivery report (NDR) back to Joe. Each NDR is forwarded back to Joe's Hotmail account, which in turn generates another NDR. This process can create millions of messages if you have enough disk space. Often, you'll discover a loop when your inbound SMTP volume suddenly spikes up or your transaction logs suddenly fill up for no apparent reason. (Thanks to reader William Harding for this question.)
My employer has one server running both Exchange Server 5.5 and Microsoft SQL Server. I want to separate them. What's the best way to go about this task?
You're definitely on the right track because both Exchange Server and SQL Server will probably be happier on their own machines. Exchange Server 5.5 will attempt to use all the RAM on the server, as will SQL Server; eventually the two will reach equilibrium, but you'll probably get better performance and more stability by splitting them up. The easiest way to do so is to take the following steps:
- Install a new server in the same site as the existing server.
- Move users' mailboxes from the old server to the new server.
- Move any connectors from the old server to the new server.
- Follow the instructions in the Microsoft article "XADM: How to Remove the First Exchange Server in a Site" (http://support.microsoft.com/support/kb/articles/q152/9/59.asp), except for the final step of deleting the server.
- Wait a few days to make sure that everything is working properly.
- Use Microsoft Exchange Administrator on the new server to delete the old server; after the old server disappears, you can use the Exchange Server setup application to remove Exchange Server from the old server.
Make sure to have a good backup on hand before embarking on steps 2 through 6. (Thanks to reader Vishard Birusingh for this question.)
We're using Exchange Server 5.5 without the Internet Mail Service (IMS). Next month, we're going to cut off our existing SMTP gateway and add a second Exchange Server to our site, moving all our SMTP traffic to Exchange. Do we need to watch out for any potential problems?
This process is remarkably straightforward. Servers in an Exchange Server 5.5 site (or in an Exchange 2000 routing group) share message routing information. Therefore, when you install the new server and put the IMS on it, other servers in the site will recognize that the IMS exists and that they can route Internet mail to it. When you install the second server, be sure to join the correct site and organization. You might want to consider now whether you want to put any mailboxes on the IMS; keeping separate servers for your connectors simplifies administration. (Thanks to reader Judy White for this question.)
We installed a third-party product on our server. Since installing the product, we've been having problems sending and receiving Internet mail. The problems are random and inconsistent. Any suggestions?
Whenever you install a third-party product on your Exchange Server machine, you're stating that you trust the vendor to do everything right. Sometimes this statement turns out to be wishful thinking. In general, Microsoft recommends against installing third-party products on your server, but many vendors claim their products work just fine with Exchange Server. Some of these products are better designed and better supported than others.
The first thing to do when you have problems after installing a third-party product is to determine whether the problems continue after you disable or uninstall the product. If the problems continue, the problems lie either with Exchange Server or with some component that was installed but not removed (e.g., a registry change). If the problems stop, they lie with the product, and the vendor is the best source for figuring out what's wrong. In your case, my guess (based on the NDR you sent me) is that the product you're using is sometimes messing up its attempt to queue incoming mail for delivery. Only the vendor can fix a problem like that one. Of course, you should always test third-party products on a test server that mimics your production environment before you introduce the product to real servers. (Thanks to reader Jacob Matusevich for this question.)
How can I develop applications that use the Web Storage System (WSS)?
The WSS is the core of Exchange 2000's storage subsystem; more than that, the WSS provides a good set of features for building Web-based applications that store data and documents. If you've ever used Outlook Web Access (OWA) 2000, then you've had a taste of how the WSS works. You create items in the IS (in OWA's case, you use built-in item types, such as contact and message), then register forms that let users see and edit data in a format you control. Along the way, you can write and register code that runs when the IS sends, receives, or processes particular item types.
This process might seem complicated, and it is. However, several sources offer good ways to learn the ins and outs of the process. You can download the WSS software development kit (SDK) from Microsoft (http://msdn.microsoft.com/downloads). This SDK will give you a good start in understanding the available tools and functions. Also, you can read Mindy Martin's excellent book, Programming Collaborative Web Applications with Microsoft Exchange 2000 Server (Microsoft Press, 2000). And you can find sample code in presentations from the 1999 and 2000 Microsoft Exchange Conferences (MECs). The 1999 presentations are on Microsoft's Exchange Server site (http://www.microsoft.com/exchange); Microsoft is due to post the 2000 sessions soon.
How does Exchange 2000 compare with Sendmail or Quarterdeck Mail (Qmail) as an SMTP smarthost?
That's a good question. The answer depends on what you consider to be the best measure of utility for a smarthost:
- Performance—Exchange 2000 will substantially outperform Sendmail or Qmail running on similar hardware. You can expect to see Exchange Server SMTP performance on a suitably configured four-processor server exceed 150 messages per second. Do you need that much performance? Probably not, but having something fast at your disposal is always nice.
- Unsolicited commercial email (UCE) protection—Sendmail and Qmail can both integrate with Internet UCE filters such as the Realtime Blackhole List (RBL) and the Open Relay Behavior-modification System (ORBS). Exchange 2000 can't integrate with such filters, although you can write a transport event sink to do so. If RBL, ORBS, or Mail Abuse Prevention System (MAPS) support is important to you, the UNIX-based packages will be your best bet for the time being.
- Security—Both Exchange 2000 and Sendmail/Qmail offer a way to integrate with third-party SMTP firewalls that can perform virus and content scanning. Configuring Sendmail (or Qmail, for that matter) and UNIX to be secure is very difficult to do, and unless you're a UNIX expert, you aren't likely to succeed at the task. Configuring Windows 2000 and Exchange 2000 is no cakewalk, either, but is less arcane.
- Ease of administration—If you don't already know how to administer Sendmail or Qmail, setting up either tool as a relay host and expecting it to work will be a tough row to hoe. Using advanced features such as address rewriting*although Exchange 2000 has only minimal support for address rewriting*is even more difficult. Overall, Exchange Server is much easier to configure and manage on an ongoing basis. (Thanks to reader Brian Williams for this question.)
We need to exchange our Exchange Server 5.5 address books with other organizations, but for political reasons we can't set up any connectors. We want to use directory export and import to do the job. Can we automate this process?
Yes, you can automate directory export and import. Exchange Administrator's /e and /i switches let you export and import from the command line. To automate this process, use the WinAt or At command or whatever task scheduler you prefer. Then, you can set up a transfer mechanism—putting the exported files on shares, scripting an automatic FTP transfer, or whatever other method works for you. (Thanks to reader Rick Wurster for this question.)
How can I automatically add a disclaimer to all outbound mail that passes through our Exchange 2000 server?
As you've probably discovered, you can't accomplish this task by using Microsoft's Exchange Server 5.5 version of the IMS extension DLL. Several third-party products (e.g., GFI's Mail essentials for Exchange/SMTP, Baltimore Technologies' MIMEsweeper) can help. If you're handy with code, you can swing over to Microsoft's site (http://www.microsoft.com/exchange/55/gen/mec99_code/4-402.exe) and obtain the sample code the company distributed during the 1999 MEC, then adapt it to your needs.