Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 264
  • Last Modified:

Exchange 2010 DAG with Outlook client cert warnings

I am creating an Exchange 2010 DAG.

At this point, I have just added the 2nd Exchange 2010 server into the organization with MB, HT, CAS roles.

EX10.mycompany.com - existing Exchange 2010 MB, HT, CAS
EXDAG.mycompany.com - newly added MB, HT, CAS
(note: internal domain is the same valid public domain as the public domain name - "mycompany.com" is just for the purposes of this post)

I have NOT created the DAG, or moved any active mailbox databases to the new server.  The new server has a mailbox database (created during install).  There is also a Receive connector between the 2 with Exchange Server authentication and permissions.

Outlook Clients are getting certificate warnings about the server name for EXDAG (the new server) when they open Outlook.

I assume this is related to Autodiscover, but I can't see how or why a client would even know EXDAG exists because it is not any of the key names.

I also assume I can export the cert from EX10 and import it to EXDAG, but the cert does *not* have a SAN for EXDAG.

Do I need to rekey the cert to include the internal FQDN of EXDAG?

Current SAN's:
ex10.mycompany.com -- internal computer fqdn
autodiscover.mycompany.com -- for autodiscover
mail.mycompany.com -- external URL for owa, etc.
  • 3
1 Solution
MASTechnical Department HeadCommented:
-->Do I need to rekey the cert to include the internal FQDN of EXDAG?
No. In future you wont be able to add internal FQDN  in your certificate.
BTW you dont need ex10.mycompany.com. You need only mail.mycompany.com and autodiscover.mycompany.com
Please check my article. This will help you to configure your exchnage URLs and clear the error

You should configure the same URL on both servers if you have a plan for DAG
snowdog_2112Author Commented:
Thanks - I'll check that out.

Part of my question is why the Outlook clients would touch EXDAG in the first place (the new server with no mailboxes or active connectors).

If Autodiscover uses:

Where in the process would the client even determine there is a new server in the organization.  At this point the 2 Exchange servers are "standalone" servers in the same organization - there is no cluster or DAG defined.

This would be like an Outlook client in the NewYork office connecting to "newyork.mycompany.com" throwing a cert warning for "london.mycompany.com" because there is an Exchange MB, HT, CAS server in London.
Adam FarageEnterprise ArchCommented:
EX10.mycompany.com - existing Exchange 2010 MB, HT, CAS
EXDAG.mycompany.com - newly added MB, HT, CAS

Because the way internal clients will look up Autodiscover. For internal, domain joined clients who have access to Active Directory they will query the servers ServiceBindingInformation attribute within the AutoDiscover service. This is also known as the "Service Connection Point" or "SCP" for AutoDiscover. You can view this attribute by running the following:

Get-ClientAccessServer | Select Name, AutoDiscoverInternalUri

Open in new window

Since you have two servers, and what sounds like split DNS (where the Internal FQDN and the External FQDN for the domain are the same) I would assume you are using some type of load balancer (two CAS = load balancing required for any HA). In that situation I would run the following command and within the AD DNS Forward Lookup Zone add an A record for "autodiscover.company.com" that points to the Virtual IP of the CAS load balancer.
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverInternalUri https://autodiscover.company.com/autodiscover/autodiscover.xml

Open in new window

So when a client that is internal, and domain joined looks up the autodiscover SCP (when starting Outlook) it will point to autodiscover.company.com, which will then point to the VIP of the load balancer and then become a load balanced service :)

Furthermore, MAS article is absolutely correct. You should be setting your internalURL and externalURL for the Client access services to the same name (that is resolvable within DNS both internally and externally) for OWA, Exchange ActiveSync, ECP, EWS, Offline Address Book, Outlook Anywhere, ect. These DNS A records INTERNALLY should point to the Virtual IP of your load balancer.

Moving past that to the certificate, you can export the existing SSL SAN from the first Exchange 2010 server and import that into the new Exchange 2010 server, then assign it. If you need help with this, let me know and I can walk you through it.
snowdog_2112Author Commented:
Awesome answer - thanks!

(I haven't been able to address this - tied up on other projects).

I'll check it out and report back.
snowdog_2112Author Commented:
sorry for the delay - better late than never for the points!

Featured Post

Independent Software Vendors: 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!

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