1

Hello all,

Calling on any and all Exchange 2010 experts here. Here’s the situation:

  • Server Exchange 2010 – all exchange roles & services are installed on a single VM

  • Outlook anywhere is enabled

  • Currently the SAN SSL cert for all exchange services (mail., webmail., autodiscover., ect) is expiring in a few days, and we can’t renew it. (he internal exchange server name has a non-routable FQDN “server.Internal”)

  • There’s a Wildcard cert that we can use for now.

  • We’re also planning to migrate this client to O365 soon (within the next few month)

My questions are:

  1. I have used wildcard certs on exchange boxes before. I know it’s not best practice, but are there any major (gotchas) in using the Wildcard cert

  2. Do I need to change any DNS settings/records if we are to implement a wildcard SSL

  3. How will end users be effected? My understanding is that she just need to close out of outlook, re-open it, and accept the new wildcard cert

  4. will that wildcard cert on the exchange box through a wrench in things come O365 migration time?

Your assistance is greatly appreciated guys. Thanks in advance.

6 Spice ups
2

No issue with wildcard, just not best practice.

The issues may revolve around the CertPrincipalName option if it’s currently setup. Change it using my guide below and you wont have a problem.

You need to make sure your OutlookAnywhere and AutoDiscover settings are setup properly along with Split-DNS. OutlookAnywhere and Split-DNS are vital for future-proofing your Exchange configuration and making it work properly now, regardless if you use Exchange 2007, 2010, or 2013. For Exchange 2013, OutlookAnywhere is a requirement and Split-DNS is Best Practice. If you are on Exchange 2007 or 2010, and you do not have OutlookAnywhere enabled, enable OutlookAnywhere and follow this guide.

You should always use NTLM over Basic authentication, as Basic sends the username and password in the clear, and NTLM is Windows Authentication. On Exchange 2013, you also have a new option called Negotiate, which is recommended. As you follow this guide, you will set the ClientAuthenticationMethod (Internal and External if on Exchange 2013) to NTLM and IISAuthenticationMethods to Basic,NTLM (and Basic,NTLM,Negotiate for Exchange 2013). Please also turn on SSLOffloading.

As DNS is a vital component in any network, please make sure that Split-DNS is setup first before doing anything else. To make sure Split-DNS is working properly, ping the OWA URL and AutoDiscover URL (eg. mail.domain.com and autodiscover.domain.com). These should both respond from an internal computer to the internal IP of your Exchange server (eg. 192.168.1.55). Then from an external source, ping the OWA URL and AutoDiscover URL (eg. mail.domain.com and autodiscover.domain.com). They should both respond externally to your external IP of the mail server (eg. 38.55.11.55). To confirm that Split-DNS is working correctly:

From an internal computer:

ping mail.domain.com

ping autodiscover.domain.com

These should resolve to your internal IP of your mail server (eg. 192.168.1.55).

From an external computer:

ping mail.domain.com

ping autodiscover.domain.com

These should resolve to your external IP of your mail server (eg. 38.55.11.55).

To fix the external records (more than likely, autodiscover is the one that doesn’t exist and needs to be created), on your domain’s name servers create an A record for autodiscover.domain.com and point it to the external IP of your mail server (eg. 38.55.11.55).

To fix the internal records, the easiest way to do this is to create a DNS Zone (Active Directory - Integrated) for mail.domain.com (assuming that is your OWA URL) and then create a blank A Record and point it to your internal IP Address for your mail server (eg. 192.168.1.55). Then create another DNS Zone (Active Directory - Integrated) for autodiscover.domain.com and create a blank A record and point it to the internal IP Address of your mail server (eg. 192.168.1.55).

After Split-DNS is confirmed working, the next thing to check is the Virtual Directories and the Client Access Server Autodiscover URI and fix them accordingly too. All InternalUrl and ExternalUrl’s should be setup using the hostname mail.domain.com (assuming mail.domain.com is the OWA URL that you chose).

If some of these Exchange PowerShell commands error out, don’t worry, these are to provide everything from Exchange 2013 back to 2007. Run these commands and keep them as a text file as a backup of what you currently have for settings should you need to reference what something used to be.

Get-OutlookProvider | fl

Get-OutlookAnywhere | fl

Get-ClientAccessServer | fl

Get-ActiveSyncVirtualDirectory | fl

Get-AutodiscoverVirtualDirectory | fl

Get-EcpVirtualDirectory | fl

Get-OabVirtualDirectory | fl

Get-OwaVirtualDirectory | fl

Get-PowerShellVirtualDirectory | fl

Get-WebServicesVirtualDirectory | fl

After taking a backup of the output above, let’s proceed with the steps to fix your environment. Change the ExternalClientAuthenticationMethod (ClientAuthenticationMethod on Exchange 2010) to NTLM and turn on SSLOffloading. If you’re on Exchange 2013, with all Outlook 2013+ clients, I would suggest setting ExternalClientAuthenticationMethod, InternalClientAuthenticationMethod and IISAuthenticationMethods to Negotiate, otherwise, keept it with NTLM for backwards compatability of Outlook 2010 and Outlook 2007 clients.

For Exchange 2010

Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM

For Exchange 2013

Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate

Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate

Set the CertPrincipalName for the OutlookProvider settings.

Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:(Subject name of certificate)

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:(Subject name of certificate)

Set-OutlookProvider -Identity WEB -CertPrincipalName msstd:(Subject name of certificate)

Set the CAS Autodiscover to the OWA Hostname:

Set-ClientAccessServer -Identity "SERVER" -AutoDiscoverServiceInternalUri "https://OWAHOSTNAME/Autodiscover/Autodiscover.xml"

Set All VirtualDirectories to the OWA Hostname except for the AutodiscoverVirtualDirectory which stays blank for InternalURL and ExternalURL.

Set-ActiveSyncVirtualDirectory -Identity "SERVER\Microsoft-Server-ActiveSync (Default Web Site)" -ActiveSyncServer "https://OWAHOSTNAME/Microsoft-Server-ActiveSync" -InternalUrl "https://OWAHOSTNAME/Microsoft-Server-ActiveSync" -ExternalUrl "https://OWAHOSTNAME/Microsoft-Server-ActiveSync"

Set-EcpVirtualDirectory -Identity "SERVER\ecp (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/ecp" -ExternalUrl "https://OWAHOSTNAME/ecp"

Set-OabVirtualDirectory -Identity "SERVER\OAB (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/OAB" -ExternalUrl "https://OWAHOSTNAME/OAB" -RequireSSL $true

Set-OwaVirtualDirectory -Identity "SERVER\owa (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/owa" -ExternalUrl "https://OWAHOSTNAME/owa"

Set-PowerShellVirtualDirectory -Identity "SERVER\PowerShell (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/powershell" -ExternalUrl "https://OWAHOSTNAME/powershell"

Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/ews/exchange.asmx" -ExternalUrl "https://OWAHOSTNAME/ews/exchange.asmx" -InternalNLBBypassUrl $null

Restart IIS and the Microsoft Exchange Transport Services

Another thing that is really handy, is to make OWA accessible by http redirecting to https so that your users don’t have to remember to type https. The easiest and best way that I’ve found to do this is to edit the Default Website’s Error Pages and set the 403 error to redirect to https://mail.domain.com/owa . You will need to re-apply this after every Cumulative Update (CU) that you perform as the CUs will revert these settings to defaults.

To do this:

  1. Open IIS
  2. Navigate to the Default Web Site on the left.
  3. On the right, double click on Error Pages
  4. Double click on the 403 Status Code.
  5. Change the Response Action to “Respond with a 302 redirect” and in the Absolute URL: type in https://mail.domain.com/owa
  6. Press OK and close IIS.
  7. Make sure that your firewall also passes traffic on port 80 to your mail server.
  8. In your browser, type in mail.domain.com and hit enter. It should find it and redirect you to the OWA Login.

If you don’t already have a proper 3rd party certificate, I would suggest taking the plunge for $37.10 CAD / $29.88 USD

https://www.namecheap.com/cart/addtocart.aspx?producttype=ssl&product=positivessl-multi-domain&action=purchase&period=1-YEAR

NameCheap has PositiveSSL Multi Domain certs with the first 3 hostnames included.

You’re going to need at least 2 - mail.domain.com (OWA URL, and Subject of the Cert) and autodiscover.domain.com (Subject Alternative Name - or SAN). A wildcard certificate will work, but a SAN certificate is best practice as if a wildcard certificate is compromised, any name can be secured, but if a SAN certificate is compromised, then only those hostnames specified can be secured.

The time it will take you to troubleshoot trying to use a self-signed certificate or one from an in-house CA (if you have one)… will cost your company more money in terms of time than just buying a certificate using the link I gave you above. Oh, and I don’t make any commission or anything from that link - it’s a direct link to the SSL Cert you need.

Also, for Exchange testing, (Autodiscover and Connectivity) you can use Microsoft’s TestConnectivity site to help troubleshoot your issues.

https://testconnectivity.microsoft.com

3

This is probably going to be the main issue that you might run into. As long as you follow his instructions you should be fine.

4

Thank you both. I can confirm that OutlookAnywhere is enabled, and SplitDNS is also configured as host names (mail and autodiscover) are resolving to the internal address while on the network, and to the external IP address while off the network.

I will confirm the rest of the guide and will report back. Again, thank you so much.

Finally, you guys don’t see any issues using the wildcard cert for O365 migrations?

Thank you

5

And finally, do you foresee any issues with clients/users connecting, other than just accepting the new SSL cert whenever they connect?

Thank you,

6

worked like a charm. Thank you all for your assistance.

Thank you,

7

Nope shouldn’t be any issue with wildcard cert. While it isn’t the recommended way it will still work so long as everything is setup properly on both ends.