As you should be aware, certain directories on an Exchange server should be excluded from scanning by antivirus products.
These are Microsoft's recommendations on which directories those should be:
Exchange 2007: http://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx
Exchange 2003: http://support.microsoft.com/kb/823166/
Exchange 2000: http://support.microsoft.com/kb/328841/
However if you have setup the AV software as per the recommendations, how do you know that it is working, or more importantly it is not scanning things you have told it to exclude?
The best way to do this is to use the EICAR test file. This is a standard file that all AV vendors support that can be used to simulate alerts.
You can download the file from here: http://www.eicar.org/anti_virus_test_file.htm
Simply copy the file in to the same directories as your Exchange databases or whatever else you have asked the AV product to exclude. If it is ever detected then the AV product is scanning things that it shouldn't be.
If you have set the product to exclude file types instead (For example edb files) then change the extension to edb. If the AV product has been configured correctly and is following that configuration then it should ignore it.
Of course the problem will be putting the file in place initially, particularly if you have already deployed the AV software. In that case setup a directory exclusion on a special directory for the purpose and create the EICAR file there instead. After copying the file to the relevant location, delete the exclusion.
If you are using Exchange 2003 then you may have experienced the greylisting bug.
This is the issue where messages disappear from the queues only to reappear as Non Delivery Reports when the server or the SMTP Server Service is restarted.
At last, Microsoft have released an update for this problem which is described here:
http://support.microsoft.com/kb/950757/
You can also download the hotfix from that page.
Hopefully Microsoft will push this out via Automatic Updates/WSUS soon so that more Exchange 2003 servers will not suffer from this problem.
At last Microsoft have released an official method to maange Exchange 2003 from Windows Vista. No more copying DLLs around and generally hoping for the best.
http://www.microsoft.com/downloads/details.aspx?FamilyID=3403d74e-8942-421b-8738-b3664559e46f&DisplayLang=en
Although using Terminal Services to connect to the Exchange server is still the best way to do it, and is what I continue to do.
I hinted in my Exchange 2007 SAN certificate posting (http://blog.sembee.co.uk/archive/2008/05/30/78.aspx) that I had written an article on how to setup Exchange 2007 with a single name certificate. After cleaning it up I have now published the article. However it isn't here, as it contains screenshots which the blog seems to struggle with - you will find it on my company technical site: http://exchange.sembee.info/2007/install/singlenamessl.asp
Do note that if you are using Unified Messaging that you cannot use a single name certificate. Also note the hard requirements of SRV record support at your public DNS provider (ie your domain name registrar) and Outlook 2007 SP1.
While researching an article for my main technical site amset.info on how to use a single name SSL certificate with Exchange 2007 (I hinted at that in my blog post from last week http://blog.sembee.co.uk/archive/2008/05/30/78.aspx) I discovered an annoying little quirk that I think deserves a separate blog posting as I think some people may trip over it.
I also mentioned it in the same blog post from last week.
As you may be aware, Exchange 2007 allows you to assign certificates to specific roles and services. It can also generate its own self generated certificates.
The Unified Messaging role requires an SSL certificate. While trying to assign the certificate to the UM role you might find that while the command is accepted, when you query the services enabled on that certificate that UM is not listed.
Furthermore if you remove the certificate that is currently assigned to the UM role, then when you restart the Exchange services, Exchange simply recreates it - a separate certificate from the main certificates used for the other roles (SMTP, OWA, IMAP, POP3 etc).
The reason for this is quite simple. It would appear that UM will not accept a certificate UNLESS it has the server's real name listed. However I haven't quite worked out whether it is just the server's NETBIOS name or the FQDN that is required - as the commercial SAN/UC certificate I used had both.
Therefore the recommendation I would make for a SAN/UC certificate URLs are:
mail.example.com (this is the common name, the name that your MX records point to will be used for OWA, POP3/IMAP/SMTP and ActiveSync - plus it is the reverse DNS record on your static IP address)
autodiscover.example.com (self explanatory)
server.example.local (this is the Exchange server's real internal name)
server (this is the Exchange server's NETBIOS name).
"mail.example.com" is the primary name so that it appears on the certificate if a user clicks on it, and ensures that anything external that is connecting to the server without support for SAN/UC certificates.
SAN (Subject Alternative Name) / UC (Unfied Communications) certificates are available from US$60 (At the time of writing) from http://DomainsForExchange.net/
