Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 251
  • Last Modified:

Exchange 2013 workaround for single domain certificate

Hello,

even though I realize that a multi domain unified communications certificate has been the way to go since Exchange 2007, it has always been possible to also work with a single-domain-certificate.  SBS2008 and 2011 did it, and it was could also be done with Exchange Standard in both versions.

I now have my first Exchange 2013 and I am struggeling with this.  A certificate is already there and paid for for 5 years, and I would hate to waste it.

This is the setup:
Exchange 2013 on Server 2012 R2 Standard, One DC running Exchange locally (I know it is not recommended).
AD-Domain "company.local", hostname "server.company.local", external domain "remote.company.com".  Certificate issued to the external name.
There will be roughly 40 mailboxes on this host.  No other servers are involved.
Features required include Outlook Anywhere.
When opening Outlook it connects and syncs fine, then after a rather longer while than I expect, it complains that the certificate, which is valid and issued by a trustworthy CA, was not issued for server.company.local.

I proceeded with the setup the way I always did in 2010 and worked through several of the tutorials including this:
http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/
which has helped me get 2010 up and running with single domain certificates more than once.

Does anybody know if this can be done at all with 2013 and if so then in what way it works different from 2010?

Thanks,
Ralph
0
Ralph Scharping
Asked:
Ralph Scharping
  • 5
  • 4
1 Solution
 
Philip PortnoyCommented:
There's a way to work-around it.
Just go to Servers -> Servers, edit your Client Access server -> Outlook anywhere.
Make sure to specify your internal URL as remote.company.com. DO NOT specify your external hostname. Select "Basic" auth and enable SSL offloading.

After it make sure that internally there's a DNS record "remote.company.com" that is pointing to CAS/NLB (whatever balancing/connection method you're using).

Make sure that cert is installed on CAS (In Servers -> Certificate) menu and that it's used for all services.
Use SRV autodiscover records in external DNS, that will point to remote.company.com.

And just to reassure you - even though Exchange is going to treat every client as internal, there's no actual difference with 2013, it's using RPC over HTTP(s) for both internal and external clients anyway.

Voila!
0
 
Ralph ScharpingDigital TherapistAuthor Commented:
Hi Philip,

thanks for your response.  Outlook Anywhere was already configured the way you suggested.  
My internal DNS resloves remote.company.com to the CAS-Servers internal IP-address through a regular A-record.  I have created a forward lookup zone "remote.company.com" and added an A-record without a hostname pointing to server.company.local

In addition to that I set a SRV-record at company.local\sites\Default-First-Site\tcp
The record is _autodiscover priority 0, weight 0, port 443 pointing to remote.company.com

Is there anything else I could have missed?
0
 
Philip PortnoyCommented:
What about external DNS SRV record? For Anywhere clients that are OOF and using public DNS servers to configure Outlook?
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
Ralph ScharpingDigital TherapistAuthor Commented:
Haven't gotten that far, yet. So far I am still struggeling with internal clients.
0
 
Philip PortnoyCommented:
Can you check if External/Internal URLs for all directories is correctly specified at Servers -> Virtual Directories tab?
0
 
Ralph ScharpingDigital TherapistAuthor Commented:
Those are okay, but aren't there some more that are not changeable in the GUI?
0
 
Philip PortnoyCommented:
Actually in your case only autodiscover, OWA and OAB might cause such problems.

Hm, the only difference between my and your implementation is that I have NLB between client and CAS, which actually has the correct name and cert on it.
In this case I guess there's no workaround (because clients are not using RPC MAPI anymore, they're always using HTTPs, which checks for real and cert host names).

In your case I'd recommend going with new cert, which will include all the hostnames and URLs in SAN (subject alternative name). You will need it sooner or later.
0
 
Ralph ScharpingDigital TherapistAuthor Commented:
Well, turns out it was the autodiscover internal url.
This is the guide that spelled out to me how to check everything:

http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2013/

This is the PowerShell-command to set the value needed:

Set-ClientAccessServer -Identity <servername> -AutoDiscoverServiceInternalUri https://remote.company.com/Autodiscover/Autodiscover.xml

This is the only URL that STILL cannot be set in GUI.
0
 
Ralph ScharpingDigital TherapistAuthor Commented:
See specifics in the rest of the thread.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now