Microsoft Exchange and Remote Desktop Services Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

More on SSL Certificates with Exchange 2007

SSL certificates with Exchange 2007 continue to be a reoccurring question on forums, and I have recently had some common points continue to come up. 
If you are looking for my guide on SSL certificate requests for Exchange 2007 then it is here:

The Self Signed Certificate
As Exchange starts to mature, and installations have been in place for over 12 months, the question of renewing the self signed certificate comes up.
What these people do not seem to realise is that they shouldn't even be using the self signed certificate. It is designed for interim use only and should be replaced with a commercial SAN/UC certificate as soon as possible.

This is Microsoft's official stance on the use of the self signed certificate:

One of the key lines is this:

"Important:  The self-signed certificate is not supported for use with Outlook Anywhere or Exchange ActiveSync.  "

Therefore if you are using either of those features with a self signed certificate you are actually in an unsupported environment.
The fact that getting the certificate to work for those two features can be tricky at the best of times, makes it even more pointless to continue to try and use self signed certificates.

The main argument for not using a commercial certificate is the cost and the perceived complexity of the certificate acquisition. When Exchange 2007 was first released the first UC/SAN certificates were expensive. However with vendors releasing low cost certificates for US$60/year ( for example) that has now changed.
As for the perception of complexity for the purchase, I outlined what required in a previous blog posting:

SAN/UC Certificates and Outlook Anywhere

The other thing that appears to be catching people out is when using Outlook Anywhere (aka RPC over HTTPS) with SAN/UC certificates.
When you setting up Outlook Anywhere in the client, if you choose to enable the "mutual authentication" option then you cannot use one of the alternative names on the certificate - you must use the primary common name. For most people this shouldn't be a problem, particularly if you follow the recommendation to put the most common name that will be used (the URL used for OWA) in as the common name and the other URLs (auto discover, the server's FQDN and real name) as additional names.
However if you have used SAN/UC certificates to support multiple domains on the same server, then it could cause you a problem.
The answer of course is to disable that option. Outlook Anywhere will continue to work correctly without that option enabled, although users may get authentication prompts. The most likely scenario where you would disable that option is when hosting, so the clients are likely to be off your domain anyway.

SAN/UC Certificates and POP3/SMTP/TLS

Similar to the issue above, to ensure maximum compatibility, the primary name on your certificate should also match your MX record. Therefore what I am recommending is the same URL is used for OWA, Outlook Anywhere and the MX records - usually

Certificate Prompts where the Certificate is Issued to Another Domain Entirely

Another issue I have seen a few reports of is Outlook 2007 generating a certificate prompt, and when you look at the certificate it is issued to someone else.
The cause of this is a combination of a missing URL and a wildcard on your DNS.
If you have not configured a split DNS system on your public domain for internal use, then Outlook 2007 will attempt to connect to as part of its startup process. If you have a wildcard DNS entry on your public DNS (so * resolves) which resolves to your public web server, AND you do not have defined, then you may get the prompt if your public web server has an SSL certificate protected site on it.

Always define and preferably setup a split DNS system so that you can point to your Exchange server.

Certificates when Using Unified Messaging

You can also run in to problems when you are using Unified Messaging. I have blogged on that subject before:

Experts Exchange - Free Access

If you have used Google to look for IT solutions you will be unable to avoid Experts Exchange. However many IT professionals avoid their answers because they are in the mistaken belief that they need to pay for access.

As a previous user of Experts Exchange, including expert of the year for three years in a row, I never paid them a penny, even before I started clocking up the large number of points.

However, Experts Exchange do not help themselves or their reputation in the IT community by hiding the free signup page away. I know this has been raised with the management team of EE in the past, but they seem to ignore it.
If you follow the public sign up links you will not see the free link - all it is pushing you to is the paid options. Even the free trial requires a credit card to sign up.

In some ways you can understand why, EE is a business and they want the subscriptions which pay for the servers, developers etc.

So how do you get free access?

At the time of writing if you choose "Think you're an expert" in the lower right corner, you can then choose another link to get to the free signup - which requires a username and email address.

However to make things easier here is the link to the free sign up page:

Sign up, save the password and then you don't have to worry about it again.

If you want the advert free site (I actually forgot what it looked like with the ads) then you need to get 10,000 points. That is five, 500 point questions. (EE has a point multiplier which means a question which costs 500 points earns 2000 to the expert who answers it) and then you need 3000 a month to maintain the premium access.

There is an awful lot of information in the site, I contributed in excess of 10,000 answers personally. It would be a shame to not get access to them just because of the way that Experts Exchange decides to sell themselves, when there is a free option available.

Testing Antivirus Exclusions

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:
Exchange 2003:
Exchange 2000:

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:

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.

Hotfix for the Exchange 2003 Greylisting Bug

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:
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.

Manage Exchange 2003 from Windows Vista

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.

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.