Sembee Blog of Exchange MVP Simon Butler

Changes to SSL Certificates

There have been a lot of changes to the way that SSL certificates are issued and the impact of those changes are now being particularly felt within the Exchange community. 

What has changed?

The CA/Browser forum (made up of the companies that issue the certificates and the browser developers who use them) decided that that all certificates issued with an expiry date after 1st November 2015 will be restricted to internet resolvable FQDN's only. 
This means that you cannot have an SSL certificate with:
- Single name hosts - such as intranet, server, exch01
- Internal only domains - such as server.example.local
- Internal IP addresses (both Ipv4 and Ipv6). 
This applies to both the common name and any additional names on the certificate. 

Furthermore, if you have a certificate that is still in force with an invalid name from the list above, then it will be revoked on 1st October 2016. 

How does this affect Exchange?

Exchange 2003 isn't really affected by this, because most people simply purchased standard single name SSL certificates. 

Exchange 2007 and later however are being impacted. 
During the early life of Exchange 2007 the advice for SSL certificates was to include both the internal and external host names of the Exchange server. This was because the default configuration of Exchange uses the server's real name and therefore did not require additional modification.

However it quickly became apparent that this wasn't the best way to deploy Exchange web services, as end users were entering the same address internally as they were externally. Split DNS was the answer there http://semb.ee/splitdns

Following the changes to the guidelines for issuing certificates, the changes to Exchange, including setup of a split DNS system is almost mandatory.
I have instructions on how to do that on my main web site at http://semb.ee/hostnames 

Going Forwards

With this change, you can now get away with just two host names on an SSL certificate for full client support:
- host.example.com
- autodiscover.example.com
With our own certificates coming with five "names" available by default, and unlimited server licence, this means you can use the other slots to secure additional services. Once the certificate has been installed on the Exchange server, export it and then import the certificate in to other servers that need it - along side the required intermediate certificate. 
If your DNS provider supports SRV records, then you can even use a standard single name SSL certificate. However mobile devices in particular seem to have some problems with the SRV autodiscover method, so if you are going to deploy mobile devices, stick with a UC (Unified Communications) type certificate. One of the cheapest sources for those is our own site CertificatesforExchange.com http://semb.ee/certs

If you have a certificate with internal names that expires after 1st October 2016, then you should get it rekeyed with the internal names removed, so the certificate is not revoked. 

What else is changing?

From April 2015, the maximum period a certificate can be issued for is being reduced to 39 months. This is to ensure that the names on certificates are checked frequently that they still belong to the original purchaser.

SHA-1 certificates are being phased out very quickly and in 2017 Microsoft will stop trusting them. However a lot of browsers will start showing warning messages on these kinds of certificates in 2016. Therefore to protect yourself, ensure that you are requesting SHA-2 certificates and have replaced any SHA-1 certificates by the end of 2015.

Action Points

What should you do about your own SSL certificates?

  1. Check whether they are SHA-1 or SHA-2. 
    To do that, browse to the SSL site, then open the SSL certificate. Click on the Details tab and then look for Signature Hash Algorithm. It should NOT say SHA1. 
    Do not confuse with Thumbprint Algorithm, which will always say SHA1, no matter the type of the certificate.
    If they are SHA1, then get them rekeyed to SHA-2. If your provider doesn't allow that, then change provider. http://semb.ee/certs

  2. Check your server configuration and start to move everything over to use the same host name internally and externally. This is easily done by setting up a split DNS system, then changing the Exchange configuration. If your certificate still contains the internal names they will continue to work until you change the SSL certificate, providing a time to educate the end users about the names to use. 
Remember if you replace a certificate before it has expired, revoke the old one. This will often happen automatically when you get a certificate rekeyed, but it does no harm to do that yourself anyway. 

Farewell Exchange 2003

8. April 2014 14:55 by Simon Butler in Exchange 2003, MS Exchange Server

Today is the day that support for Windows XP ends, but it is also the end of another product that was much loved in its day and even now is still in widespread use, and that is Exchange 2003.

 

Exchange 2003 was where I really got heavily involved with the Exchange product. I had played around a bit with Exchange 5.5 and 2000 at previous employers, but it was around the time of Exchange 2003 SP1 release that I really started to spend time with it.

 

I was thrown in to a migration from Exchange 2000 to 2003 within weeks of starting a new job, and having built my first server, interest in the product grew very quickly. It was working on Exchange 2003 problems within the community that first got me recognition from Microsoft via their MVP programme - which I have just been received for the ninth year.

 

Getting RPC over HTTPS to work was my first major achievement, and it became one of the most popular articles on my web site. Documentation wasn't great and it required manual registry changes to work correctly.

 

I remember the joy of having the 16gb database limit increased to 18gb initially, up to 75gb with a registry change that was introduced with one of the service packs.

 

By the time we got to service pack 2, Exchange 2003 was a pretty rock solid product. Reliable, with plenty of third party support. The introduction of ActiveSync over HTTP was particularly important, as just a short time later the iPhone was released which took advantage of it. Until that point, mobile sync support was limited to Windows Mobile devices or Blackberry.
There was a version of ActiveSync at RTM, but until the HTTP version came out, it only really worked for users in the USA, who had free email to text services.

 

Looking at it now, Exchange 2003 is a fairly basic email application, but for many companies it does all that they need. However it is starting to show its age. There are problems with some modern ActiveSync devices and OWA does not like the modern browsers and unless you are using Internet Explorer, the OWA experience is pretty painful. The limitation of 75gb on a database in standard edition is very limiting for all but the smallest of companies.

 

It was also the last version of Exchange that was administrated purely through a GUI. However with email platforms becoming bigger all the time, a GUI only approach quickly showed its weaknesses and the move to a modern scripting language like PowerShell was overdue.

 

 

As with many things, it was good for its time, but the more modern versions of Exchange, particularly Exchange 2010 are simply much better, more feature rich and a lot more suitable for the demands of a modern IT infrastructure. 

Where to get free support for Microsoft Exchange Server

If you are having problems with your Exchange server, you have a number of sources for assistance. 

You can Google for the problem, and in many cases this will bring up something that can assist you.

If you have a fairly specific problem though, you might need to actually explain it to someone to get assistance. For that you have two main sources. 

1. Microsoft Support - this is of course a chargeable solution. 

2. Peer to peer support. 

The second option is very popular and is where you can get assistance from some of the top Exchange experts. Exchange MVPs (like myself) post in peer to peer locations, as do some Microsoft employees. 

Where to find peer to peer support

With the demise of the Microsoft Newsgroups, peer to peer support pretty much comes in two forms. 

  • Forums
  • Email Lists

Email Lists

One of the most active email lists was hosted by Sunbelt Software, who were acquired by GFI. GFI have now announced the lists are going away, so the new list can be found at "My IT Forum" http://myitforum.com/myitforumwp/services/email-lists/  

Yahoo Groups also have email lists for each version of Exchange, however these appear to be very low traffic. 

Use an Outlook.com account or a public folder to store the list traffic - they can get very busy and by putting the content in to a separate place it will keep it from your main email. 

Forums

There are lots of forums where you can get support for Microsoft Exchange. 

Microsoft Technet

Exchange 2013: http://social.technet.microsoft.com/Forums/en-US/category/exchangeserver

Previous Versions: http://social.technet.microsoft.com/Forums/en-US/category/exchangeserverlegacy 

Very busy forums, which are monitored by Microsoft staff. However there are a lot categories therefore working out where to post can be a challenge. 

Experts Exchange

The Exchange section is very active and is one of the main places you will find me posting. Contrary to popular belief, you don't need to pay to either see the solutions or post a question. A free account can be created here: http://semb.ee/ee

Petri

Exchange 2000/2003: http://www.petri.co.il/forums/forumdisplay.php?f=12 

Exchange 2007/2010/2013: http://www.petri.co.il/forums/forumdisplay.php?f=36  

Another forum where you will find me posting, I also moderate the Exchange forums. Not quite as busy as some, but knowledgeable people post. 

Msexchange.org

http://forums.msexchange.org/ 

Another forum divided in to categories. 

There are other forums out there, but have very low traffic, which means your question may go unanswered. 

You can also find groups on Linked In, if you have an account there. 

More ways to get assistance can be found on my list of Exchange resources at http://exbpa.com/ 

SSL Compatibility and Testing

SSL certificates are a constant source of pain for Exchange administrators. With Exchange 2007 and 2010 so heavily dependant on web services, getting SSL setup correctly is important for correct operation. 

A lot of SSL certificate deployment is now being done for mobile device support, and then you open a new issue - SSL certificate compatibility. 

Recently I found a large list of SSL certificate and client compatibility. 

It is from a Danish SSL reseller called FairSSL:

http://www.ssltest.net/compare/sar.php 

Most useful for mobile platform compatibility, the combinations it lists are significant. 

On the same site they also have a tool to verify that your SSL certificate is installed correctly. Most of the SSL vendors also provide this, but if you don't have the login details (perhaps because the certificate was just supplied to you) then it is a useful service to have:

http://www.ssltest.net/ 

With more SSL providers now using intermediate certificates to issue the certificates, rather than the root, getting the certificates installed correctly can mean the difference between SSL working and not. 

[ad]

Got a Blackberry on BIS - Got Exchange/SBS - You Need a BES Express

 

If you were affected by the Blackberry Internet Service outage today (10th October 2001) and your Blackberry connects to an in-house email server running Exchange server (2003 or higher), then you really should be running a BES (Blackberry Enterprise Server) or BES Express (BESX).

A Blackberry connected to a BES/BESX gives you the full functionality of the Blackberry with true two way synchronisation of Email, Contacts, Calendar and Tasks. It is an extension of your Inbox. No need to maintain two sets of data that kind of synchronises. 

If you use BESX, then the software is free and you do not have to change your device subscription/tariff. For smaller installations the software can be installed on your server in  a few hours and give you complete control over the devices that connect. 

If you are in an industry where the email traffic is sensitive, the data exchange between your Blackberry and the BES/BESX cannot be intercepted as the encryption is managed by your server, not the one at RIM. This provides a more secure mobile email solution. 

Through my company Sembee Ltd, I can install and configure a BES Express for you for just £250 plus VAT if installed on to an existing server (other terms and conditions apply). That includes post installation configuration and guidance on maintenance, handset setup etc. 

For more information, contact me through the company web site at http://www.sembee.co.uk/ 

 

Sent Items Storage for Shared Mailboxes

The default behaviour of Outlook with regards to sent items continues to come up on forums as an issue.

By default, when you send an email using the From field via your Send As permissions, the item you have sent goes in to your own Sent Items folder. This is because you sent it, not the person whose mailbox it was sent from. This can be useful from a tracking point of view (who sent the email).

However it may also be useful for the item to be stored in the Sent Items folder of the Shared Mailbox so that other users or even the mailbox owner can see what was sent.

How you achieve this depends on the version of Outlook that you are running. The version of Exchange doesn't matter.

For Outlook 2003 and 2007, a registry change is required, following the installation of an update. If you are keeping the machines up to date, then further updates should not be required.
These registry changes are outlined in the following articles:

Outlook 2007
http://support.microsoft.com/kb/972148
Requires Outlook 2007 Hotfix: 970944
http://support.microsoft.com/kb/970944/

Outlook 2003
http://support.microsoft.com/kb/953804/
Requires Outlook 2003 Hotfix: 953803
http://support.microsoft.com/kb/953803/


For older versions of Outlook, you will need to look at third party tools. The only one that I am aware of are the tools from Ivasoft: http://www.ivasoft.biz/

For OWA, you will need to use a server side tool, again the third party tools from the above site are the only ones that I am aware of - and support for latest version of Exchange isn't available.

For Outlook 2010, no registry change is required, you just need to add the mailbox in a different way.
Instead of adding the mailbox as an additional mailbox through the Properties of the primary mailbox, add the additional mailbox as an additional Account. That means going through the new Account wizard again. This feature also allows you to have connections to another mailbox in another Exchange forest at the same time - I have used this to migrate public folders (see http://blog.sembee.co.uk/post/Cross-Forest-Public-Folder-Migration.aspx)

However if you are using Outlook 2010, you should also be aware of the issues  in this KB article: http://support.microsoft.com/kb/2297543 (Performance problems when you try to access folders in a secondary mailbox in Outlook 2010).

(Late posting because I forgot to press publish).

Cross Forest Public Folder Migration The Easy Way - Use Outlook 2010

Anyone who has done a cross forest public folder migration will almost certainly be reliving their nightmares about it simply from reading the title.
I was just the same.

Extract the content to a PST file, either manually (selecting about 1000 items at a go) or by using a rule, move the PST file to a machine in the new forest, then import.

Slow, mind-numbing dull and therefore not the most fun part of a migration and always the bit that I don't look forward to. 

However a recent migration was done almost completely hands free. I moved almost 9gb of data in an afternoon, while I went to the cinema.

To do this, I took advantage of the new feature of Outlook 2010 that allows it to connect to two different Exchange organisations at the same time.

This allowed me to create a rule to move the content between the two public folders. Once the rule was set, I left it to get on with it. The speed wasn't great, but compared to moving it manually, it was a considerable time saver. After returning from cinema I was able to do more of the migration work, while I waited for the rule to finish.
Furthermore, by using multiple machines, I could move lots of large public folders at once. Once the process was completed, the rule was discarded.
Even before moving the data, when creating the new folders it was easy to setup the permissions as I could compare them side by side.

Where an item was corrupt and couldn't be moved, or the few items that didn't match the rule, I simply moved those items manually or deleted them. In most folders this was only a few hundred items at most.

You still can't copy and paste large numbers of items, as the problem with trying to copy/cut and paste more than about 1500 items is still in Outlook, but a rule effectively moves each item individually, so that isn't a problem.
For the folders with small number of items, a straight copy and paste works well.

I used the same procedure to move a stubborn mailbox which wouldn't move on the regular cross forest move mailbox procedure. Much faster than exporting the mailboxes out to PST file and then importing them. It also allowed me to identify the corrupt items and deal with them.


Even if you aren't deploying Outlook 2010 for your migration, it is worth downloading the trial for this feature alone. Then once the migration is complete, discard the trial software.

Outlook 2007 Certificate Prompts with Exchange 2003

14. June 2010 09:05 by Simon Butler in Exchange 2003, SSL Certificates, Outlook

A common complaint in forums for some time has been SSL certificate prompts from Outlook 2007, when running Exchange 2003.
The error is usually along the lines of

"The name on the security certificate is invalid or doesn't match the name of the site."

Often the first response will be connected to RPC over HTTPS, as this is the only part of Exchange 2003 that can use SSL certificates for Outlook connectivity.

However the real cause of this is because of the changes made to Outlook 2007 to accommodate the changes to Exchange 2007 and its move to web services. Web services are used to reduce the dependency on Public Folders.

The specific cause of this is a process known as autodiscover. Anyone who has managed Exchange 2007 will be very familiar with Autodiscover, as it can be a key pain point.

Outlook 2007 will attempt to connect to autodiscover.example.com - where example.com is the part of your email address after the @ sign. It will also attempt to connect to a number  of other URLs if that one fails.
 
If your domain does not have an entry for autodiscover, but does have a wildcard entry in its DNS (which is common) then you may get this issue.

Therefore from a client where you have the problem, attempt to ping 

autodiscover.example.com

Where example.com is your email domain, then repeat with your internal Windows domain.

If it resolves, pinging either autodiscover.example.com, example.com or similar, even if it fails, then you may well be on to the cause. The final test is to bring up a web browser and type in autodiscover.example.com and see what happens.
It is likely that you will get the same SSL certificate prompt that Outlook receives and then it will load another web site completely.

The reason for this is quite simple.
Web hosts will often share the IP address of their server with a number of web sites, could be 100s. However to use SSL, a web site must have a dedicated IP address. Therefore a single web site with that IP address will have SSL support.
By using a wildcard in your DNS (so anythingyoulike.example.com resolves) means that all hosts will resolve to the same IP address.
As SSL cannot share an IP address, and does not see the host name being used, it will connect, and generate the SSL certificate mismatch.

How to resolve? Either remove the wildcard entry on the external DNS or have an entry for autodiscover.example.com put in to your domain with a dummy IP address - 127.0.0.2 for example. This will cause the host name to resolve, but fail to connect. See the single host replacement method on this page for instructions on how to do it: http://www.amset.info/netadmin/split-dns.asp

However if you ever deploy Exchange 2007 or higher then remember to remove it!

Short URL for TestExchangeConnectivity.com

One of the most useful online tools to come out of Microsoft for the Exchange product is their testexchangeconnectivity site - or to give it's correct name - the Microsoft Exchange Remote Connectivity Analyzer (ExRCA). However the URL is a mouthful, and if you are typing it as often as I do, it is easy to make mistakes.

Therefore I have setup a short URL for it using our Exchange community site exbpa.com  - you can get to it via http://et.exbpa.com/

I was going to use te.exbpa.com (which also works) but I thought et would be easier to remember.

Catch All Mailboxes and the POP3 Connector

I have recently seen an issue with the POP3 connector which I haven't seen before, but will be very widespread. In this particular circumstance it caused the client's server to get blacklisted and have a server processing many thousands of messages which it shouldn't need to.

It is yet another reason why using the POP3 Connector is a bad idea. I have blogged on the POP3 connector being a bad option in the past: http://blog.sembee.co.uk/archive/2006/09/25/25.aspx .

This client was not only using a POP3 connector, but they were also using a catch all mailbox at the ISP - I have posted today why using a catch all is a bad idea here:  http://blog.sembee.co.uk/archive/2010/02/15/117.aspx (posting that item was inspired by this one).

The Problem

The actual problem was quite simple, and something that Exchange could have dealt with on its own if the server was setup for SMTP delivery. However it became a noticeable issue because of the way this particular server was configured.

The domain was subject to an NDR or directory harvest attack (I cannot tell which due to the nature of the SBS Connector) and ended up with large numbers of email messages in their queues.

What puzzled the client was that port 25 wasn't open to the internet, and they had followed my guides on recipient filtering and authenticated user relay so that the server was secure ( http://www.amset.info/exchange/spam-cleanup.asp ).
As I wrote in that article, messages can continue to appear in the queues for some hours after the initial clean-up due to the way Exchange displays the queues when there are a very large number of messages in the queues. However for this client, the messages continued to appear for weeks. Eventually, fed up with cleaning the queues daily, I was asked to look at the server.

What I found was that the messages in the queues were all from postmaster@ so had the classic hallmarks of an NDR or direct harvest attack, but the client was using the POP3 Connector.

Due to the way the POP3 connector works, messages that come in to the server through it are not subject to the recipient filter. The recipient filter works at the connection point, but the POP3 connector simply drops the in to the queue for delivery. This is the key point and the result was the same as a standard NDR attack through SMTP without recipient validation  - the messages that could be delivered were, and the messages with invalid external recipients, or where there was a delivery problem, hung around in the queues. As time went on, the server became blacklisted by most major ISPs for being a source of spam and back scatter.

Furthermore, the client also had the POP3 connector setup to send a copy of messages that could not be delivered to a valid user  in to a mailbox, so not only were the messages being delivered there (and the client had what they considered to be a major spam problem) but the NDRs were going out as well. The user concerned thought they were receiving large amounts of spam - when in actual fact they were receiving email that wasn't even addressed to them.

In short, it was a complete mess.

This will be a widespread problem

In many respects, the client was not to blame for this problem. This configuration is quite common, and would therefore affect everyone using the POP3 connector with a catch all mailbox. However you may not see the messages in the queues and therefore be unaware that your server is a source of spam or backscatter.

The most common configuration when SBS is used with a POP3 connector is to route email OUT through a smart host - usually the ISPs SMTP Server. If you are doing that in combination with a catch all mailbox then you wouldn't see the symptoms of this problem. When a smart host is used, Exchange is sending the email straight back out again and the smart host is responsible for the delivery of the email.

It was only because this client was using direct delivery rather than a smart host that the email messages were shown in the queue causing further investigation. The client had accepted large amounts of spam in the mailbox as something that happens - and asked me to look at that as another issue - not realising that it was all caused by the same thing.

If the server had been configured in the usual way for POP3 use, that is to use a smart host, then the first the client would have known there is a problem is when their ISP called to tell them - although many do not.

Furthermore the email messages also do not appear in message tracking logs as they do not pass through Exchange, but simply bounce off SMTP. The only messages that do appear in message tracking are those delivered to the user set to receive the messages that could not be delivered.
Therefore a server could be the source of back scatter and the administrators (whether in house or an external support company) would be completely oblivious to the issue.

I haven't been able to verify if the email messages showed in the volume reported by the SBS Reporting tool, because as with most SBS Servers I see, it wasn't turned on.

The Solution

Changing the client to SMTP delivery of email resulted in the spam level dropping immediately. In the 24 hours after the change, the number of messages the server dropped for non-valid recipients was measured in 1000s. The account which received a copy of the unmatched addresses from the POP3 connector saw the level of spam almost completely drop away - as most of the spam wasn't addressed to the user.

Conclusion

There is a very simple conclusion to this blog posting.
Don't use a catch all mailbox with the POP3 Connector. Ideally you shouldn't use the POP3 connector at all.

If you are using the POP3 connector and do not wish to move to SMTP delivery, then you should look at switching to user specific POP3 mailboxes instead of a catch all. While that is more tedious to setup, it does mean you are only downloading email that you may want, rather than lots of spam that you almost certainly do not, only for it to be rejected.