Today I'm gonna tell you more about an error I've seen in my own environment after I configured it to you an official Thawte SSL-certificate (http://www.thawte.com).
First some background story about SSL certificates:
When Exchange server is initially setup, it creates a self-signed SSL-certificate which refers to the internal NETBIOS machine name of the server. When connecting from the outside to a friendly URL like https://webmail.pdtit.be/owa (in a future post I'll write about how to make this URL even more friendly , it gives you an SSL error popup. This could be one of the reasons for buying a certificate from an official instance, known as a Root Certificate Authority. Examples are Verisign, GlobalSign, Thawte,... of which Thawte is my favourite. When using ActiveSync with Windows Mobile 5.0 or 6, the best option is also going for an official certificate, as it is not possible (by default - I know there are some tricks) to install SSL-certificates on your mobile device.
Oke, that step was easy: www.thawte.com/buy certficate/import in IIS => after 2 days max I had my server running smoothly with a brand-new official SSL-certificate. No more nasty popups in my Internet Browser and ActiveSync running like charm, yes !!
However, when I first launched my Outlook 2007, a f****ing SSL-error comes up again, now referring to the https://webmail.pdtit.be being not the correct name for the SSL CLient/Server connection, AAAAARRRRRGGGGHHHH What's happening ???
I'll explain you here:
As you probably already knew, security is an important aspect of an Exchange Server environment. As such, all communication in an Exchange server environment is trying to flow by SSL encryption (Exchange <-> Exchange, Exchange <-> OL2007,...). You probably think, Outlook?? SSL ?? isn't it using RPC / MAPI anymore?? Well, yes it is... for some services. Others are using HTTP(S). Some examples are Outlook Anywhere, Autodiscover (again, more on this in a new post in the near future). Technically speaking, when Outlook2007 is launched, it uses a service called Autodiscover (if configured on the server which you should do in an Outlook 2007 environment) to find the server where the user's mailbox is on. This communication uses SSL-encrypted tunneling to the Exchange Environment.
Owkay, So I first had my SSL popups showing up in the "external" clients, I installed an official certificate, and now my "internal" clients are suffering from the SSL-popups. How in the world can I make them happy living together?
That's explained here in the last paragraphs:
The catch is, MOST Client Access Server Role services are bound to the SSL-certificate you configured in IIS for the Default website (and as such, the sub sites which are used for Exchange services), except the AutoDiscover. The reconfiguration that needs to be done is binding all services to use the official SSL-certificate and the official outside URL (webmail.company.com) as there primary connection. As this configuration is really deep in the Exchange Environment, you understand it is executed by using PowerShell cmdlets:
Set-WebServicesVirtualDirectory -Identity "EWS*" -ExternalUrl "Https://webmail.pdtit.be/EWS/Exchange.asmx" -InternalUrl "Https:// webmail.pdtit.be/EWS/Exchange.asmx"
the previous command will update all of the services (OAB,Free/Busy,OOF,GAL) address, but if you are interested in updating the Autodiscovery SCP only you can use the following CMDLET:
Set-ClientAccessServer -Identity CASserver1 -AutoDiscoverServiceInternalUri https://webmail.pdtit.be
this will allow you to use a commercial certificate along with your secure deployment of exchange 2007 and avoid the common errors when using AutoDiscovery service.
'Till next post...
mei 28 2007, 08:23
Peter De Tender