We want to implement virus scanning on our Exchange Server computers. What's the best way to keep macro and executable viruses off our network?
The best way to safeguard your system is to use a combination of products that cover three separate but overlapping areas. For viruses that enter your system directly from users, you need a desktop scanner. For viruses that come in from the Internet, you need to use an SMTP scanner to catch incoming infected messages before they do any harm. For stored messages that contain viruses, you need a scanner that runs on your Exchange server to disinfect mailboxes and public folders.
Which desktop scanner to choose is entirely up to you. Several good scanners are on the market; most organizations choose a desktop scanner on the basis of which vendor is offering the best deal on scanner licenses. SMTP scanners are a little more esoteric. Some scanners, such as InterScan's VirusWall (which Microsoft uses) and Content Technologies' MIMEsweeper, are standalone server products, and other scanners (such as Check Point's FireWall-1 and Omniquad's Mailwall) are integrated into firewall software or appliances.
Any good SMTP virus scanner lets you configure specific patterns that cause the software to quarantine incoming messages. The product also needs the capability of automatically fetching virus signature updates from the vendor.
The third area, Exchange server scanning, is the downfall of most people. The primary cause of problems I see with Exchange server antivirus products is failure to get a product that is "Exchange aware." Exchange-aware products scan the store message by message instead of scanning the files themselves. In addition, they're smart enough to leave the store and log files alone.
An ordinary scanner looks for particular patterns, or signatures, in every file on disk. When it finds a signature, it attempts to disinfect the file by changing the signature to something else. The Exchange database files can be full of bytes that can falsely trigger the antiviral package to attempt a repair. Log files are just sequences of bytes, so if the file scanner sees a suspicious byte sequence, it might attempt to quarantine, or worse, repair the file. When the scanner starts changing data in log files and so on, you're heading for a fall.
Database files aren't the only potential problem area; Message Transfer Agent (MTA) queue files, Internet Mail Service (IMS) files, and other files can also cause problems. Avoid problems by choosing an Exchange-aware scanning product (e.g., Trend Micro's ScanMail for Exchange or Sybari's excellent Antigen product). Newer products can use the antivirus API (AV API) built into Exchange Server 5.5 Service Pack 3 (SP3) and later (including Exchange 2000 Server) to get more robust access to the store for scanning and disinfecting. However, adoption of this API seems to be lagging; as I write this, I don't think any AV API-based products are available to consumers yet.
We started evaluating an antivirus program that uses Microsoft's new AV API included with SP3. However, we noticed frequent crashes in store.exe, so we concluded that this product isn't ready for prime time. Are we better off sticking with antivirus utilities that use Messaging API (MAPI) for scanning?
The AV API supposedly offers a broader range of functionality, plus vastly improved performance compared with MAPI-based scanning. I bet that the problem you saw wasn't entirely the fault of the antivirus vendor. Microsoft has acknowledged a flaw in some builds of the SP3 store.exe that causes any attempt to use the AV API to crash the store. You can solve this problem in two ways. You can ditch the AV API-based utility, as you did; or you can obtain the hotfix mentioned in the Microsoft article "XADM: Information Store Crashes When Using Antivirus Application Programming Interface" (http://support.microsoft.com/support/kb/articles/q262/4/91.asp). This fix replaces store.exe versions later than 5.5.2652.42.
I used PerlScript to write some event scripts. They run OK in standalone mode, but they don't fire when they should on the server. What's wrong?
The Exchange event scripting service doesn't support all the scripting languages that Windows Script Host (WSH) supports. In particular, although the clever folks at ActiveState (http://www.activestate.com) have produced a version of Perl that works with WSH, that version doesn't work with the Exchange Event Service. To write scripts that can run from the Event Service, use VBScript or JScript.
After I installed SP3, I noticed that the message size limits I had set in the IMS were no longer correct—they're more than 100 times too large. What's going on?
You found a flaw in SP3 that causes it to multiply the size limits by 102.4 when it displays them (but not when it applies the limits to messages). According to the Microsoft article "XCON: Internet Mail Service Message Size Restriction Is Not Correctly Displayed" (http://support.microsoft.com/ support/kb/articles/q243/8/22.asp), you need new versions of mseximc.exe (the IMS executable) and imcadmin.dll (the administrative extensions that let you manage the IMS from within Microsoft Exchange Administrator). These fixes will be part of the next service pack.
I run Isinteg and Eseutil occasionally, just to get a feel for what is happening with our Exchange server data. The program doesn't find any errors, but more and more often, I get warnings when I run Isinteg on priv.edb. How can I eliminate these warnings?
First of all, running Eseutil is a good way to mess something up unintentionally. I don't recommend running it unless you need it. By default, Isinteg is a nondestructive tool that looks for logical errors in the structure of the database. If you run only isinteg test alltests pri, you might get warnings or you might not. If you want to fix the problem that is causing the warnings, first make a good backup (and test it), then run Isinteg with the fix switch. You might have to run the utility a few times to clear up all the warnings. (Thanks to reader Pico Nazzaro for this question.)
I just installed Exchange on a standalone Windows NT server. The company's other email system is Seattle Lab's SLmail, which is on the PDC. (My company is small.) How do I migrate my users over to Exchange?
The answer depends on which mail clients your users are using. SLmail handles only POP3 clients, and POP3 clients usually keep the mail on the client, not on the server. One approach is to migrate your users to Outlook, because Outlook can import mail from Outlook Express, Netscape, or Eudora. When the mail is in Outlook personal folders (.pst) files, you can easily move it to folders on the server (which I recommend doing). Third-party tools from ComAxis Technology, Wingra Technologies, and others can convert mail stored on various servers. In addition, Exchange includes a migration wizard that you can use to import mail from IMAP clients and accounts from Lightweight Directory Access Protocol (LDAP) directory servers.
Because you have a small number of seats, the easiest route is likely to be manually creating Exchange accounts, then migrating your users by moving them to Outlook and helping them move their mail. Of course, you don't have to take down the SLmail server until you're satisfied with the direction and speed of the migration to Exchange. (Thanks to reader Sheila Terrell for this question.)
I'm trying to use the Active Directory Connector (ADC) to establish a connection agreement (CA) between Active Directory (AD) and an Exchange Server 5.5 site. Why do I keep getting error c1031b95 when I try to specify the credentials I want the ADC to use?
This problem is common among people who are experimenting with setting up small Windows 2000 AD networks and want them to synchronize with their existing Exchange Server 5.5 organizations. ADC creates connections between AD and Exchange Server 5.5. The error message complains that either the credentials are invalid or they don't have sufficient permissions to access the Exchange Server 5.5 directory. Three problems can cause this message:
- The credentials are wrong. Make sure the username and password you specified are correct.
- You're trying to use the ADC to talk to something other than Exchange Server 5.5 SP2 or later. The target bridgehead must be running at least SP3.
- The Win2K or Exchange permissions for the target account in the target domain are wrong. The Exchange Site Service Account (SSA) must have Service Account Administrator rights on the site, organization, and configuration containers. The target account you use to set up the ADC must have Log on locally and Access this computer from the network rights granted in the local computer, default domain, and default domain controller policies.
If I put an Exchange server in my demilitarized zone (DMZ), should I place the server in a separate domain from the domain in my internal network?
You could set up your Exchange server in a separate domain, but you don't have to. If you create separate domains, you have the burden of establishing and maintaining trust relationships between the two domains, but you also get the benefit of keeping your internal domain information out of your DMZ.
From a security standpoint, the more important issues to consider revolve around why your Exchange server is in the DMZ in the first place. If you're trying to provide Exchange access to remote clients, make sure that you have adequate security precautions in place. One easy, cheap, and fairly secure solution is to put a PPTP server in the DMZ and configure it so that Exchange clients can reach your server, either in the DMZ or inside your network. (Thanks to reader Duane Joseph for this question.)
We currently have a RAS dial-up through the IMS to our ISP. I've noticed a number of very large files in the \exchsrvr\mcdata\log directory. Can we delete or shrink these files?
Yes, you can delete these large files. These files contain copies of all the inbound and outbound messages sent through the IMS; the IMS logs this traffic when you have SMTP diagnostic logging turned on. To clear the files, first turn diagnostic logging down on the Diagnostic Logging tab in the IMS Properties dialog box, then stop and restart the IMS. After it restarts, remove the Lnnnnnnn.log files from \exchsrvr\imcdata\log and you'll be in good shape. (Thanks to reader Steve Schroeder for this question.)
