In a discussion about SSL certificates for Exchange 2013 servers the question of whether to include server names in the SSL certificate often comes up.
In this article I’m going to demonstrate how you can deploy an SSL certificate for a simple Exchange 2013 organization without including the server names in the certificate. I’m using Exchange Server 2013 in this example but it also applies to Exchange Server 2016.
But first let’s be clear – including server names in your SSL certificate is supported. For many small organizations, particularly those with a single server, it will look like less effort to just include the server name in the certificate.
However, that is not best practice.
In addition to using as few certificates as possible, you should also use as few host names as possible. This practice can save money. Many certificate providers charge a fee based on the number of host names you add to your certificate.
The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate’s subject alternative names.
As Rajith points out here this best practice is important for larger organizations to reduce costs, reduce administrative overheads, and because in larger scale environments services are configured with namespaces that resolve to load-balanced IP addresses and so on. In addition, using server names in URLs is going to cause problems for you with future migrations.
Since those issues apply to almost every Exchange Server environment, this is a topic worth covering in more detail.
Namespaces for Exchange Server 2013/2016
In Microsoft’s words:
The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange.
More specifically, it is the host names client uses to make TLS/SSL connections to Exchange services. Those services include:
- Outlook Anywhere
- MAPI
- Outlook Web App
- Exchange Control Panel
- Exchange ActiveSync
- Exchange Web Services
- Offline Address Book
- AutoDiscover
POP, IMAP and UM also have certificate requirements but can be enabled to use separate SSL certificates, whereas the above services all use the same certificate. So for this article I will ignore POP, IMAP and UM.
Sticking to a simple scenario we will plan to use one namespace for all of the services. So the hostnames/URLs to be configured are:
- Outlook Anywhere – mail.exchange2013demo.com
- MAPI – https://mail.exchange2013demo.com/mapi
- Outlook Web App – https://mail.exchange2013demo.com/owa
- Exchange Control Panel – https://mail.exchange2013demo.com/ecp
- Exchange ActiveSync – https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync
- Exchange Web Services – https://mail.exchange2013demo.com/EWS/Exchange.asmx
- Offline Address Book – https://mail.exchange2013demo.com/OAB
- AutoDiscover – https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml
Split DNS for Exchange Server 2013/2016
For many organizations the use of split DNS for your Exchange namespace goes hand in hand with eliminating server names from SSL certificates.
Split DNS allows your internal clients to receive a different answer to their DNS lookups than an external client would receive. In effect you have your Exchange namespace (in this example exchange2013demo.com) hosted on your internal DNS server, with records configured to point to internal IP addresses.
[PS] C:\>Resolve-DnsName mail.exchange2013demo.com Name Type TTL Section IPAddress ---- ---- --- ------- --------- mail.exchange2013demo.com A 3600 Answer 192.168.0.187 mail.exchange2013demo.com A 3600 Answer 192.168.0.188
If you’re wondering why mail.exchange2013demo.com has two A records it is because I am using DNS round robin to load balance the name, as demonstrated in this article on Client Access server high availability.
Meanwhile you also have the Exchange namespace hosted on your public DNS servers, with records configured to point to external IP addresses.
C:\>nslookup mail.exchange2013demo.com Non-authoritative answer: Name: mail.exchange2013demo.com Address: 58.7.203.81
Configuring Hostnames and URLs in Exchange Server 2013/2016
Although some of the hostnames and URLs are configurable using the Exchange Admin Center, some others require you to use PowerShell. So for the sake of simplicity I will use PowerShell to configure all of the services.
Remember we are looking at a simple scenario of two servers in a single site as shown in the diagram above, so you will see me piping commands such as Get-OWAVirtualDirectory into other commands to administer multiple objects at the same time.
Note: If you have multiple servers in different sites then you may wish to configure servers individually instead of in bulk, as different sites may have different namespace requirements in your organization.
Configuring Outlook Anywhere
To review the current configuration use Get-OutlookAnywhere.
[PS] C:\>Get-OutlookAnywhere | Select Server,ExternalHostname,Internalhostname Server ExternalHostname InternalHostname ------ ---------------- ---------------- E15MB1 mail.exchange2013demo.com E15MB2 mail.exchange2013demo.com
I’ve already configured the internal host name for Outlook Anywhere in my test lab, but you might see your server’s host names in there instead.
To configure the internal and external host names use Set-OutlookAnywhere.
[PS] C:\>Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname mail.exchange2013demo.com -InternalHostname mail.exchange2013demo.com -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM
Note that in addition to setting the host names you must also explicitly set the SSL requirement for both internal and external clients (default for internal is False, which is fine, but I am enforcing it in this example), and either a default authentication method or an external authentication method (set to NTLM in this example).
Configuring MAPI
To review the current configuration use Get-MAPIVirtualDirectory.
[PS] C:\>Get-MapiVirtualDirectory | Select Server,ExternalURL,InternalURL | fl Server : E15MB1 ExternalUrl : https://mail.exchange2013demo.com/mapi InternalUrl : https://e15mb1.exchange2013demo.com/mapi Server : E15MB2 ExternalUrl : https://mail.exchange2013demo.com/mapi InternalUrl : https://e15mb2.exchange2013demo.com/mapi
To configure the URLs use Set-MAPIVirtualDirectory.
[PS] C:\>Get-MAPIVirtualDirectory | Set-MAPIVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/mapi -InternalUrl https://mail.exchange2013demo.com/mapi
Configuring Outlook Web App
To review the current configuration use Get-OWAVirtualDirectory.
[PS] C:\>Get-OwaVirtualDirectory | Select Server,ExternalURL,InternalURL | fl Server : E15MB1 ExternalUrl : https://mail.exchange2013demo.com/owa InternalUrl : https://e15mb1.exchange2013demo.com/owa Server : E15MB2 ExternalUrl : https://mail.exchange2013demo.com/owa InternalUrl : https://e15mb2.exchange2013demo.com/owa
To configure the URLs use Set-OWAVirtualDirectory.
[PS] C:\>Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/owa -InternalUrl https://mail.exchange2013demo.com/owa WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website. WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website.
Configuring the Exchange Control Panel
As you can see when configuring the OWA URLs the ECP URLs must be configured to match. To configure the ECP URLs use the Set-ECPVirtualDirectory cmdlet.
[PS] C:\>Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/ecp -InternalUrl https://mail.exchange2013demo.com/ecp
I needed to perform an IISreset on my servers for this one to take effect properly.
Configuring Exchange ActiveSync
To review the existing configuration use Get-ActiveSyncVirtualDirectory.
[PS] C:\>Get-ActiveSyncVirtualDirectory | select server,externalurl,internalurl | fl Server : E15MB1 ExternalUrl : InternalUrl : https://e15mb1.exchange2013demo.com/Microsoft-Server-ActiveSync Server : E15MB2 ExternalUrl : InternalUrl : https://e15mb2.exchange2013demo.com/Microsoft-Server-ActiveSync
To configure the new URLs use Set-ActiveSyncVirtualDirectory.
[PS] C:\>Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync
Configuring Exchange Web Services
To review the existing configuration use Get-WebServicesVirtualDirectory.
[PS] C:\>Get-WebServicesVirtualDirectory | Select Server,ExternalURL,InternalURL | fl Server : E15MB1 ExternalUrl : https://mail.exchange2013demo.com/EWS/Exchange.asmx InternalUrl : https://e15mb1.exchange2013demo.com/EWS/Exchange.asmx Server : E15MB2 ExternalUrl : https://mail.exchange2013demo.com/EWS/Exchange.asmx InternalUrl : https://e15mb2.exchange2013demo.com/EWS/Exchange.asmx
To configure the new URLs use Set-WebServicesVirtualDirectory.
[PS] C:\>Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/EWS/Exchange.asmx -InternalUrl https://mail.exchange2013demo.com/EWS/Exchange.asmx
Configuring the Offline Address Book
To review the existing configuration use Get-OABVirtualDirectory.
[PS] C:\>Get-OabVirtualDirectory | Select Server,ExternalURL,InternalURL | fl Server : E15MB1 ExternalUrl : InternalUrl : https://e15mb1.exchange2013demo.com/OAB Server : E15MB2 ExternalUrl : InternalUrl : https://e15mb2.exchange2013demo.com/OAB
To configure the new URLs use Set-OABVirtualDirectory.
[PS] C:\>Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/OAB -InternalUrl https://mail.exchange2013demo.com/OAB
Configuring the AutoDiscover SCP
The final configuration is the AutoDiscover service connection point. Unlike the other host names and URLs this is not configured on a virtual directory (don’t be fooled by the URLs shown when you run Get-AutoDiscoverVirtualDirectory).
Instead we need to use Get-ClientAccessServer to see the existing configuration.
[PS] C:\>Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI Name AutoDiscoverServiceInternalUri ---- ------------------------------ E15MB1 https://e15mb1.exchange2013demo.com/Autodiscover/Autodiscover.xml E15MB2 https://e15mb2.exchange2013demo.com/Autodiscover/Autodiscover.xml
To configure the new URI use Set-ClientAccessServer.
[PS] C:\>Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml
Configuring an SSL Certificate
With all of the namespaces configured the next steps are:
- Generate a Certificate Request for Exchange 2013 (or 2016) that only includes the minimum required names (in this case mail.exchange2013demo.com and autodiscover.exchange2013demo.com).
- Submit the certificate request to your chosen CA to acquire the SSL certificate. I recommend Digicert for their competitive pricing, good support, flexible licensing, and free re-issues if you happen to make an error. Or if you’re using a private CA refer to these steps.
- Complete the pending certificate request
- Export/import an SSL certificate to multiple Exchange 2013 servers (if you have multiple servers)
- Assign the SSL certificate to services in Exchange 2013
Testing the New Configuration
To be confident that the new configuration is working you can run a series of tests.
- On a client with no existing Outlook profile launch Outlook and confirm that the profile is configured automatically and without any certificate warnings.
- Use the Outlook “Connection Status” dialog to verify that Outlook is connecting only to the namespaces you configured.
- Use the “Test E-Mail AutoConfiguration” test in Outlook to verify all services are accessible without error.
- Connect to OWA internally and externally and verify there are no certificate warnings.
- Within OWA navigate to Options and make a change such as enabling out of office.
- Connect to the Exchange Admin Center and verify it works without certificate warnings.
- Run external tests using the Remote Connectivity Analyzer website.
It a good article and all works but when I added a 3rd party cert without the local server name the send connectors complain that they cannot find a cerificate in the local store with the local servername. Therefore they cannot STARTTLS SMTP. I have asigned the 3rd party cert to the send connector but how to I stop it looking for a certificate with the local servername and successfully start TLS. It seems there is no way to override the local server name on the send connector
Useful article, thanks – still helpful in 2020! Just wanted to post a little “gotcha” I hit when implementing this – it took enough time it might even be worth a quick mention in the article itself to avoid others hitting it. Also, it may be semi-related to the issues the other comment-writer mentioned about 401 errors they hit.
I changed my Exchange access urls to be the same internally and externally (mail.domain.com, autodiscover.domain.com). Autodiscover seemed to work fine for mail clients, but my email disclaiming/signature solution (Exclaimer) suddenly stopped updating sent messages with the signature applied (using its Sent Items Update Service – SIUS). It turns out that SIUS uses autodiscover to find the appropriate urls to perform its work. From my investigation, it also seems like other tools such as some spam checkers might do the same. The event viewer showed the 401 unauthorized error in the logs for Exclaimer, as did running Test-OutlookWebServices PowerShell cmdlet from the Exchange server.
It turns out that since Server 2003, there is a security feature called Loopback Check, which prevents access to a server using its FQDN, from that server itself. Microsoft describe it in KB926642 (https://support.microsoft.com/en-gb/help/926642/error-message-when-you-try-to-access-a-server-locally-by-using-its-fqd). It mentions UNCs specifically, but it applies here as well.
Adding “BackConnectionHostNames” to the registry as described in the KB, with the mail.domain.com FQDN appears to be all that is required (no need to disable strict name checking). Alternatively you could manually set the Exchange urls in your affected software.
The Loopback Check is intended to prevent a Reflection Attack, so it’s definitely not a good idea to disable it completely, from my understanding… at current it looks like doing so would immediately expose you to CVE-2018-8581 vulnerability (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8581).
I’ve had trouble finding any information on whether adding mail.domain.com to the BackConnectionHostNames registry value carries any security risk, but perhaps someone else here might be able to contribute on that.
Hi Paul,
Does this apply to the self signed certificate that is automatically created by exchange named “Microsoft Exchange Server Auth Certificate”? I recently migrated from exchange 2013 to 2016 servers and after doing so, this certificate disappeared. Everything worked fine without it except I was receiving event id 2009 saying it can’t find the cert. I followed instructions to re-create the self signed certificate and published it. This crashed all my client connections!
It crashed them when I input *.domain.local into the certificate rather than servername. I went through the instructions again and created yet another certificate with server.domain.local in the cert. This fixed the issue.
The problem is this self signed certificate is now synced across all exchange servers. I’m worried that client connections won’t failover to these other servers. I’m thinking I can create another cert with all the servernames… Is this best practice? Please advise.
Thanks,
Brad
Hello, Mr Paul,
Thank you for such article
I have recently applied SSL for my exchange server 2016 having two exchange server (dag)
And the both servers ssl applied successfully and autodiscover is giving profile to outlook clients internal and external.
However, I have noticed today one of the pc which is joined domain and when we attempt to open outlook its profile is created and got certificate from server issued by CA and it’s states valid but it’s states one of the SAN not included in the certificate can’t be verified (the san is same my internal server name )
I didn’t add my internal server in CSR/Certificate. How can i resolve this issue.
Your reply will be helpful
When I run HCW it changes my default receive connector to use the internal server name fqdn. Then I get a TLS error because the name on my on prem receive connector FQDN don’t match the TLScertificatename because it is not using the internal server name. So do I need another third party certificate for my exchange servers internal name to use with my default receive connector to accept messages from 0365?
Paul,
I have a single server, on premise, Exchange 2016 server. Currently, I have just one domain running–domain.com–which is also my AD domain. I would like to add a couple of additional domains to the server–domain1.com and domain2.com. It’s easy enough to add those to the accepted domain list, and create a new e-mail policy for those new domains. I would also add additional zones to my internal DNS servers pointing the mail.domain1.com and autodiscover.domain1.com to the internal IP of the Exchange server.
My question, is if I would need to modify the certificate to reflect the new domains, so that users are able to send, and receive, externally, as well as connect to the server from any mobile devices. Currently my SAN cert includes mail.domain.com and autodiscover.domain.com. Do I need to add mail.domain1.com and autodiscover.domain1.com to the cert to accomplish my end goal, of allowing users to send, receive, connect, and authenticate using their primary e-mail address–which could be user@domain.com, user@domain1.com, or user@domain2.com?
The Real Person!
The Real Person!
Why do you want to use mail.domain1.com for… whatever you plan to use it for?
For additional accepted domains you don’t need to make any changes at all. Internal domain-joined Outlook clients will look up the Autodiscover SCP in Active Directory, and will happily use the autodiscover.domain.com namespace for Autodiscover. External clients (e.g. mobile) can use Autodiscover on the autodiscover.domain.com namespace as well if you set up SRV records for Autodiscover in public DNS.
Thank you for the help!
Ok…so the additional domains do not need to be added to the SAN certificate–if I create an SRV record in original, and additional, domains public DNS zones, pointing to the primary domains autodiscover record?
That would look something like the following:
Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.domain.com
Priority: 0
Weight: 0
The Real Person!
The Real Person!
Short answer, yes. Long answer, there’s a bunch of articles and blog posts with more detailed steps you can find on Google for how to use SRV records for Autodiscover when you have multiple domains in use for an Exchange org.
Paul,
We have implemented a separate name for outlook anywhere URL in Exchange 2013. This was requested by security. I have made a simple addition to our Cert, we added oa.test.com and made this change to outlook anywhere URL’s. Issue is i am the only user on exchange 2013 that is getting the new URL. Everyone else is getting the old one, positive they still function properly. Do you have an idea on why this would happen?
The Real Person!
The Real Person!
Clients discover the URLs via Autodiscover. It’s possible that the other clients have not polled for Autodiscover recently. It’s also possible that for existing profiles, as long as the old name still works, the new name won’t be used. New profiles should pick up the new URL fine though.
Not sure what security benefit your team sees in this change, but test the above conditions and you might just find you need to wait a little longer, or possibly start recreating Outlook profiles.
Paul,
Currently my SCP of Exchange 2016 is exch16.ad.domain.com – so I want to change it.
All my servers have the DNS suffix ad.domain.com
NETBIOS: ad
AD: ad.domain.com
Email: domain.com
Split DNS is set up for:
ad.domain.com (externally not reachable)
and
domain.com
Can I change the SCP to autodiscover.domain com without any problem since my DNS suffix is different?
I am already using mail.domain.com on all the virtual directories so I am guessing changing the SCP to autodiscover.domain.com won‘t be a problem.
Thanks!
The Real Person!
The Real Person!
Should be fine as long as your SSL certificate has the name on it. Your SCP can literally be anything you like as long as you can meet the DNS and SSL requirements.
Hi,
I have few queries.
1) In 2016 on-premise Exchange Infra if we deploy Edge Transport Server then can we import the same SSL SAN Certificate which we already imported on all Mailbox Servers.
Considering Exchange 2016 has only one Mailbox roles and rest all roles in the form of services.
2) it is mandatory to add a url for Exchange Edge Server in SSL Certificate and if yes
The Real Person!
The Real Person!
No the Edge Transport server name doesn’t need to be on the cert.
Hi Paul,
Only leaving a comment as the thread appears to be still active!
we are running exchange 2010/2016 co-existence and all appears fine in setup. I have migrated over about 150mailboxes to exchange 2016. half our organisation run outlook 2016 and other half outlook 2010 (outlook 2010 will be phased out in desktop refresh)
users running outlook 2016 are fine no issues, but any users I have migrated to exchange 2016 that are still running outlook 2010 keep getting repeated logon prompts even though they enter in their password. workaround is to disable cached exchange mode, I have read in this thread that the issue maybe with public folder query timeouts ?! not sure if this is true. we currently are still using 2010 PFs and it will be last thing to be migrated in the end game process. wondering if there is any issue you are aware of to fix this ?
also same people running outlook 2010 with this issue that also have access to shared mailboxes get the message “cannot expand the folder. the set of folders cannot be opened”. Microsoft exchange is not available” is there a workaround for this ?
I am nearly sure I have authentication setup properly, unless I have not done it right ?
thanks for any info!
neil
The Real Person!
The Real Person!
First thing to check is whether the 2010 clients are fully patched, as there are a number of compatibility issues that can arise for outdated Office builds.
FYI –
my domain is domain.com
my UCC cert I purchased: webmail.domain.com with SANs autodiscover.domain.com, webmailmail.domain.com and domain.com
I got security alert for domain.com
How can I suppress this security alert.
Thanks,
The Real Person!
The Real Person!
You can’t suppress the alert. You can *avoid* the alert by stopping the client from trying the root domain lookup by using the GPO I mentioned earlier.
Hi Paul,
I configured exch 2016 the same way you posted, except ECP pointing to autodiscover.domain.com/autodiscover/autodiscover.xml and I have a split DNS for autodiscover.domain.com and everything works fine. But I just got a cert error for the main domain.com with comodo when create a new profile. we host our domain.com with another company. Any suggestions to block this security alert.
Thanks for your help,
The Real Person!
The Real Person!
You can suppress the root domain autodiscover lookup behavior by using group policy.
https://support.microsoft.com/en-au/help/2612922/how-to-control-outlook-autodiscover-by-using-group-policy
I used office 2013 and so I found under admin template, MS outlook 2013, account settings, exchange and Disable Autodiscover option has “Exclude the root domain query based on primary SMTP…” and enabled this option, but still got the Security Alert. Any suggestions?
Thanks,
The Real Person!
The Real Person!
Are you sure the GPO has applied to the client?
Yes.
FYI –
This policy setting allows you to disable AutoDiscover.
If you enable this policy setting, you can select one or more of the following options to disable in the AutoDiscover feature.
“Exclude the last known good URL” – Outlook does not use the last known good Autodiscover URL.
“Exclude the SCP object lookup” – Outlook does not perform Active Directory queries for Service Connection Point (SCP) objects with Autodiscover information.
“Exclude the root domain query based on your primary SMTP address” – Outlook does not use the root domain of your primary SMTP address to locate the AutoDiscover service. For example, you select this optionOutlook does not use the following URL: https:///autodiscover/autodiscover.xml.
“Exclude the query for the AutoDiscover domain” – Outlook does not use the Autodiscover domain to locate the Autodiscover service. For example, Outlook does not use the following URL: https://autodiscover./autodiscover/autodiscover.xml
“Exclude the HTTP redirect method” – Outlook does not use the HTTP redirect method in the event it is unable to reach the AutoDiscover service via either of the HTTPS URLs: https:///autodiscover/autodiscover.xml or https://autodiscover./autodiscover/autodiscover.xml.
“Exclude the SRV record query in DNS” – Outlook does not use an SRV record lookup in DNS to locate the AutoDiscover service.
Hi Paul
If you have reconfigured all your virtual directories and autodiscover SCP to mail.exchange2013demo.com then why do you need autodiscover.exchange2013demo.com on your SSL certificate?
The Real Person!
The Real Person!
Non-domain joined devices (e.g. mobile devices) will use the autodiscover cname as one method of locating the Autodiscover service.
Thanks for the quick reply Paul,
Would this include a non-domain (remote) workstaion trying to link through Outlook Anywhere?
If so, should I have a public dns record for autodiscover?
The Real Person!
The Real Person!
Yes. Any non-domain joined device that can’t look up the SCP in Active Directory will use an Autodiscover sequence that includes the “autodiscover” CNAME, as well as other methods including an SRV record. You can implement one or several of those. Most orgs I’ve seen just put the “autodiscover” CNAME in, but SRV is also frequently used.
Hi Paul
When there is a secondary replicated zone for the external dns settings on our internal dns server it’s not possible to change the ip’s for the exchange related records. When i delete the secondary replication and start a Primary zone the internal DNS Server is authoritative but cannot resolve all the other external names.
What do you suggest how can i solve the Name resolving in this Szenario ?
Greets
Daniel
I ran the powershell command to update the Outlook Anywhere settings for a new server. I made a typo. I found the error within hours and corrected it, but clients are still getting proxy errors that reference the typo. How long does it take to get the erroneous virtual directory setting out of the system? Rebooting the client computer doesn’t seem to do it. Do I need to do IISRESET?
The Real Person!
The Real Person!
You can try recycling the Autodiscover app pool in IIS to clear that cache.
Hey Paul,
I’ve always found the setting of the internal and external URL’s to the same address infuriating in a single server environment – but meh –
In a multiple server environment though, setting multiple servers to have the same internal and external URL will break proxying wont it ?
The Real Person!
The Real Person!
Not sure what’s infuriating about a simple configuration best practice, so I can’t help you with your feelings there.
No, proxying will work fine. In a multi-server *site*, traffic is usually load balanced, or it will proxy just fine. In a multi-server, *multi-site* environment, Exchange can understand how to proxy to servers even when they have external URLs defined.
Hey Paul,
Yep, when they have external URL’s defined, but what about when they have the internal and external url defined as the same address, across all servers – which is what this article is suggesting? (sorry if I have mis-read it)
The Real Person!
The Real Person!
That works fine as well. Split DNS is used to differentiate internal and external name resolution.
Hi Paul,
I have setup all the internal and external uris to be the same mail.domain.com but as soon as i change the SCP to point to an external name the autodiscover test in outlook stops working and giving 401 error messages if i change it back to the internal domain name autodiscover starts working again, it works fine from outside of the lan using the external name. the strange this is that i can browse to the external name and log in successfully and get the expected 600 error, should is disable loopback checking on the exchange box?
Hope you can help have been battling with this for ages
Many Thanks
Jason
The Real Person!
The Real Person!
The Autodiscover SCP should point to a name that is resolvable internally. It should resolve to the Exchange server’s IP (or a load balancer).
If you’re configuring it to resolve to a public IP address (such as a firewall) then the firewall needs to know how to handle internal requests like that. Some firewalls call this NAT loopback, others call it NAT reflection.
Hi,
I have split dns and the external name i set for autodiscover resolves to the internal IP address of the exchange server i have just tried setingg up NAT loopback and changing the DNS to the external IP address but it still comes back with 401 error on autodiscover when i change the autodiscover SCP to the external name.
Kaspm
The Real Person!
The Real Person!
I don’t know your environment and what you’re describing is a bit vague. You’re going to have to describe the namespaces that you’re configuring before I can make any specific suggestions.
This is all pretty straight foward if you don’t try to over complicate it. The Autodiscover SCP is used by internal, domain-joined clients to locate Autodiscover. You can set it to something like “mail.company.com”, and use your internal DNS zone (this is assuming split DNS is being used, which is recommended), to resolve that name to the internal IP of your Exchange server.
NAT loopback etc on external firewalls shouldn’t be necessary for internal clients to reach Autodiscover, because they are connecting to an internal IP address.
The Autodiscover SCP doesn’t need to be a unique name, e.g in the article above I used “mail.exchange2013demo.com” for the internal and external namespaces for all services including Autodiscover.
Hi,
So i have a single exchange server running all roles and split DNS but as soon as i set the SCP to mail.domain.com or autodiscover.domain.com both of which point to the internal address of the exchange box rather than the internal name i get the 401 error on autodiscover it works with the internal name but get the certificate error when opening outlook because the certificate doesn’t have the internal name on anymore since you can no longer have internal names on certificates.
External clients domain joined or not as long as they aren’t connected to VPN can connect to autodiscover.domain.com perfectly fine, internally i can browse to autodiscover.domain.com and authenticate and get the expected xml 600 error.
Hope this helps describe my issue if not please let me know any specific details you need.
Many Thanks
Jason
The Real Person!
The Real Person!
By “internal name” I guess you mean a .local domain or something like that, that CA’s won’t issue certs for any more?
The Exchange namespaces don’t need to be the same as the AD namespace. If your AD is domain.local, but your email addresses are domain.com, then you can use domain.com (or any other domain you own, for that matter) for your Exchange namespaces.
Whatever namespace you use definitely needs to be on the SSL certificate.
Hi, Paul- Currently I’m in the middle of a 2010 to 2013 migration. All mailboxes are still on 2010. I’ve set up the SCP to https://mail.domain.com/autodiscover/autodiscover.xml but all of our outlook clients still show the exch2010 server name. I moved a test mailbox to 2013 server, but the server setting in the outlook client did not change. Isn’t the server setting supposed to show as serverguid@domain.local? I read another article which says to set the SCP to https://exch2013server.domain.local What do you think? -Kindest Regards
The Real Person!
The Real Person!
Autodiscover is just Autodiscover. Exchange 2010 mailbox users will continue to connect via RPC to the Exchange 2010 CAS. Before you migrate any users to 2013, you’ll need to cutover all of the client access namespaces (OWA, Outlook Anywhere, Autodiscover, EWS, ECP, etc) *excluding* the CAS Array namespace for Exchange 2010, to your Exchange 2013 server.
Then, when you migrate a mailbox to 2013, Autodiscover will update the Outlook profile, and instead of the Exchange 2010 server name, you’ll start to see the guid@domain string instead, because the 2013 mailbox user is now connecting via Outlook Anywhere to Exchange 2013.
More info:
https://www.practical365.com/exchange-server-2010-2013-migration-preparing-co-existence/
https://www.practical365.com/exchange-server-2010-2013-migration-cut-over-namespaces/
Hi Paul,
Excellent site and podcast!
I have a basic question as follows: I am in the process of migrating a SBS 2008 server with Exchange 2007 to a new server running 2012R2 / Exchange 2013. When I ran the get-outlookanywhere command it returned both servers. I want to keep the old server fully functional with the remote.domain.com host scheme until the migration is complete, but for the new server I want to use mail.domain.com. When I run the commands to set the host names how do I target just the new Exchange 2013 server? Will the commands only target the server that EMS is explicitly connected to?
Thanks in advance.
The Real Person!
The Real Person!
Get-OutlookAnywhere has a -Server parameter you can use to target a specific server. If you’re ever unsure about the operation of a cmdlet, then the TechNet page for that cmdlet is your best resource.
Perfect thanks again.
I just had an issue that I was about to post, but figured it out. I thought I would post anyway since it might help someone. You said check the namespace and the certificate. I added a second 2013 server, MBX/CAS. I created a DAG which works great. I am using a single namespace, mail.domain.com. I then proceeded to add RR DNS to provide for HA on my CAS function. Once the DNS change filtered down, people began calling with certificate errors.
I quickly removed the second A record and began troubleshooting. I set up a laptop with a host record pointing mail to the new server. After analyzing the certificate error message, I compared the cert settings in EAC for the two servers and found the difference.
When I added the second server, I installed the SSL cert from the first server. But I forgot to enable the services (SMTP, POP, IMAP, IIS, etc.). The services were still on the self signed certificate. Once I added these to my SSL certificate, it works fine.
One question, if I may, Paul. Is it ok to remove those three self signed certs that are automatically created when Exchange is installed, or do I need them for some reason?
Thanks
The Real Person!
The Real Person!
Leave the self-signed certs in place.
Hi, if I understand correctly including mail and autodiscover will force me to use a SAN certificate. How about if I name everything autodiscover (instead of mail) then I should only need one name in the cert. Is this possible? Any issues?
The Real Person!
The Real Person!
Are you going to tell your users that the URL for Outlook web access is “autodiscover.domain.com”?
Thanks for the quick reply, well if that’s the ONLY downside, it seems like a small price to pay instead of shelling out for a SAN cert. Once they save it in their favorites, shouldn’t be a biggie anyway. Any other issues to consider?
The Real Person!
The Real Person!
SANs are not expensive. SANs are the recommended approach. Use a SAN, or use a wildcard if for some reason a SAN is out of your budget. Single name certs aren’t a good idea, and using “autodiscover.domain.com” as your only namespace is one of those things that someone will come along later and think “WTF were they thinking?”
Thanks for the feedback, will convince client to use SAN cert. 🙂
What about MS best practice for domains?
If i use ad.company.com for my local domain.
The server ist EXC.ad.company.com… we have a wildcard for our domain… but its useless because it just cover “*.company.com” and not “*.*.company.com”.
autodiscover and mail is fine but we get errors that the name of the server is not in the certificat…. so…
can i but a san to a existing wildcard certificat?
or is the only way to resolve this issue a splitt DNS?
Thanks!
The Real Person!
The Real Person!
Your AD namespace can be entirely different from your Exchange namespace.
An AD domain of ad.company.com is fine. Exchange can still use company.com or foo.com or contoso.com or whatever you like.
When you plan your SSL certificates simply plan for Exchange to have a certificate that suits the Exchange namespaces. Don’t try to get one all encompassing SSL certificate for everything in your entire IT environment that needs one.
Pingback: Godaddy Pending Dns Status – Cyber Sun
Pingback: Exchange Server 2016 Client Access Namespace Configuration
Pingback: Godaddy Change Ssl Domain Name – Cyber Sun
Pingback: SSL Certificates for Exchange Server 2016
Pingback: Invalid Tld Error Godaddy – Shop Docomo
Hi,
Great information. I have issue with external autodiscover. Microsoft remote connectivity analyzer first checks domain.com finds nothing there and then autodiscover.domail.com whch passes successfully. When mobile device is setup it goes directly to domain.com and times out resulting in that the use must punch settings manually. Where should I look to resolve this?
This is for an Exchange 2010 installation, so I’m not sure how relevant it is, but if the public IP address of my Exchange server is accessible from my private network (NAT redirect at the gateway), do I need to implement Split DNS?
In other words, right now, without split DNS, I can access OWA with https://mail.domain.com from my private network, even though mail.domain.com resolves to a public IP.
The Real Person!
The Real Person!
Only if you want the traffic going direct to Exchange/load balancer instead of your firewall.
After installing the first exchange 2013 I decided to install a second one as a backup server. Looks like the second server is busy issuing certificates to my clients and this has affected mail flow especially outlook 2010 on Vista. How can I correct this situation?
Thanks for this article. I’m having a problem and wonder if this would apply?
Organisation with an existing Exchange 2013 Server with CAS and Mailbox roles – I have installed a 2nd Exchange 203 Box with CAS and Mailbox Roles. If I create a user with a mailbox on the new server, it cannot connect from outlook as I get a certificate error message which mentions the internal name of the first server.
Does this require a certificate as per your article please? Or should I just remove the CAS role from the first server?
Thanks
The Real Person!
The Real Person!
You can’t remove the CAS role from the server after it’s been installed, so scratch that option.
The solution is to fix your namespace and certificate configurations. Both servers in the site should have the same namespaces and the same certificate installed.
Thanks Paul
This is my first experience of this! Are there steps on your site to achieve this?
Will I need to purchase a certificate to achieve this or can you use a self-certified one?
Paul
The Real Person!
The Real Person!
Here you go:
https://www.practical365.com/exchange-server-2013-ssl-certificates/
It is possible to install the same certificat and enable forms based authentication on the TMG for external clients and on the CAS server for internal clients. To do so you will have to create a second OW virtual directory on a CAS server. Then you can enable FBA on that vdir and still have FBA enabled on the TMG.
Have a look at this blog post which will guide you in doing this:
http://blogs.technet.com/b/exchange/archive/2011/01/17/configuring-multiple-owa-ecp-virtual-directories-on-exchange-2010-client-access-server.aspx
Mikael Ljung
The Real Person!
The Real Person!
No, that is an Exchange 2010 article and should not be used as guidance for Exchange 2013 servers.
Microsoft recently published some Exchange 2013 guidance here. Be sure to read and understand all the caveats.
http://blogs.technet.com/b/exchange/archive/2015/02/11/configuring-multiple-owa-ecp-virtual-directories-on-the-exchange-2013-client-access-server-role.aspx
Outlook 2013 connects fine, but Outlook 2010 does not connect and stays asking for the password, which can be going there?
Pingback: Exchange SSL Requirements when CA's Won't Issue You a Certificate
Hey! we are doing the exchange 2013 pilot for my organization. All the documents refers to have a single URL for both internal and external Access. We have a small problem in addressing the OWA. Currently the owa directory is configured for basic authentication and it is linked with TMG for external access. When my internal users are trying to access the url, they are prompted with basic authentication prompts. Is there any way we can use the authentication like – FBA for internal and basic authentication for external access.
The Real Person!
The Real Person!
Choose one auth type. Use DNS so that all connections for OWA, even internal ones, go to the TMG.
Thanks for the info. Currently my exchange server 2013 outlook anywhere URL and OWA are the same. If i use the point the DNS name to TMG, then all my outlook anywhere request will be forwarded to TMG.
The Real Person!
The Real Person!
Yes. Is that a problem? The TMG can be configured to also publish Outlook Anywhere if you haven’t already done that.
thanks. i re will.
Hi. I have migrated Exchange 2007 to 2013. im having a certificate error only when DBs are moved trough DAG. error: Server name is not correct. There is a problem with the proxy server’s security certificate, %s. Outlook is unable to … Outlook is unable to connect to the proxy server (Error Code 0). There 8 server between 2 sites. 2 cas and 2 MBX per site. all servers have new ssl certificates with all names and autodiscover, and external URL. the email access internal/external is by external url. What urls or certificates do I need to review?
The Real Person!
The Real Person!
All of them.
All the CAS namespaces should be the same, and all your SSL certs should be the same cert with the appropriate names.
Check all of them. That is the common sense approach.
Thanks. all 4 cas are in LB. have the cert is the same due was imported and on the certificate i put the 4 cas server names, the old url, the new webmail. one thing is that the email domain is not internal. and only fail when i move dbs to another server in dag but arent on same datacenter, or if do an iis reset.
thanks.
The Real Person!
The Real Person!
I think you should re-read the article above. It talks about how to avoid putting CAS server names on the cert, and all of the different URLs that need to be correctly configured on the CAS.
Hi paul,
I have a situation where a customer has Active directory as domain.net and emails as domain.com . Customer was silly enough not to register domain.net, so we can’t get a cert for that. I have already arranged a public cert from godaddy for domain.com and the required SAN’s under that.
There are two exchange servers (let’s say ex01 and ex02) with a HW load balancer to be added. But right now the HW load balancer is not there and I’m trying to use the DNS round robin as per your article.
But even after setting all the URL’s to mail.domain.com as you mentioned I still get the warning pop-up box for outlook users. The box still says “ex01.domain.net” and says that the name does not match the certificate. Of course that name does not exist in the certificate as all the names there are under domain.com. what can i do now?
The Real Person!
The Real Person!
Take another look at the namespaces you’ve configured on ex01. I’d say you’ve missed one.
i have looked and looked again. nothing was missed. Only thing different I did is for outlook anywhere I set internal clientrequiressl to false. As your article mentioned that is default i didnot want to change it. Could that be the problem?
Secondly I did restart the IIS Admin service on both servers but not the exchange services, does that make any difference?
The Real Person!
The Real Person!
I can’t see your environment so I’ve got no way to tell what you may have missed, but if clients are still connecting to a server FQDN then something has been missed.
A common mistake is not setting the Autodiscover URI correctly using Set-ClientAccessServer (it is not set on the Autodiscover virtual directory).
Try doing the Outlook test email auto-configuration to see which URLs are being detected by Outlook.
Hi Paul,
Great article thanks for the write up.
I’ve followed your guide using split DNS so we don’t need internal certs..
I have the CN of:
mail.domain.com (outlook anywhere, webmail, exchange control panel, exchange web services, offline address book)
and the SAN CNs of:
autodiscover.domain.com (auto discover)
async.domain.com (exchange active sync)
autodiscover.domain2.com (auto discover)
autodiscover.subdomain.domain.com (auto discover)
for some reason the CSR file generated wants to include
domain.com
I don’t think I need this though. Would you see a reason for having the certificate cover the base domain?
Cheers
Rich
Hi Rich,
I think that Paul has stopped updated the site. I try to give you the answer I think is correct:
Do the external addresses domain.com and http://www.domain.com go to a web hosting company?
If that is so, you will go to your internal network when you type https://domain.com in the browser. You can redirect domain.com to http://www.domain.com
Greetings
Mikael Ljung
The Real Person!
The Real Person!
Some clients (like Outlook) do a domain lookup as part of the Autodiscover process. It’s silly, since almost nobody points their domain name at their Exchange servers, usually it is pointing at a web server hosting a website. This behaviour will probably be changed in later versions of Outlook as it is the source of some frustrating issues that need workarounds put in.
There’s no harm in including it. I do, just to be sure.
Paul
Thanks for your patience
Thanks for your cooperation
Thanks for your interest Paul
please tell me more about this and what I need to do
((Have you added a DNS record to your public DNS zone for the OWA name?))
what kind of records I need to add If my OWA name is https://mail.ab.com/owa?
regards
The Real Person!
The Real Person!
In your ab.com DNS zone you would add an A record for “mail” that points to the public IP address of your Exchange server (ie, the IP on your firewall or router that NATs to your Exchange server).
Hi Paul,
Just want to confirm…
webmail.domainname.com > all web services
autodiscover.domainname.com > autodiscover
do any of the fqdn’s specified on any of the receive connectors (internet or application) or fqdn on the send connector need to be specified on the SSL cert? What would you normally set for a fqdn on your send connector?
Thanks,
The Real Person!
The Real Person!
You can add SMTP namespace(s) to the same cert, or a different cert. SMTP is enabled separately to IIS, so it can be the same cert or a different cert.
The second connector FQDN should resolve in DNS and also ideally match the reverse DNS lookup for the public IP address.
Thanks Paul.
In Exchange 2013, the CAS/MBX roles are combined and setup is as follows:
Default Frontend Receive Connector
FQDN = ServerName
SMTP Banner = mail.domainname.com
Send Connector
FQDN – mail.domainname.com
mail.domainname.com resolves in DNS and reverse lookup works fine.
SSL certificate has the following san names:
webmail.domainname.com
autodiscover.domainname.com
Question: Is mail.domainname.com required on the SSL certificate for successful mail flow?
Thank you for your time, much appreciated.
The Real Person!
The Real Person!
If you do nothing with the SMTP certificate everything will work fine. If you add SMTP aliases to a certificate and enable that certificate for SMTP you are enabling the use of TLS to encrypt mail in transit (this already happens within your org).
http://windowsitpro.com/exchange-server-2010/use-tls-smtp-secure-your-email
So not required, but as Paul says at the end of the article: “Because this is such a simple change to make, and because it provides an immediate privacy benefit, I encourage you to do it sooner rather than later. There’s no downside.”
Thanks heaps Paul.
So with that in mind, if we leave the self signed SSL certificate assigned to SMTP and our receive/send connectors are either $null or using the server FQDN, then all email, both internal and external, will be sent using TLS (if selected) and mail flow will work as normal? However, if we wish to use a custom alias then we will need a 3rd party cert with that alias on it
Dear Paul
* I installed exchange 2013 on win 2012.
* my SAN certificate is assign to only IIS & SMTP services
* Outlook Anywhere configured external and internal host name are the same and the Allow SSL offloading check box is unchecked.
* Internal and external URL for OWA virtual directory is configured as https://mail.ad.com/owa ( this name is exist in SSL certificate )
* I can access owa from internal network , but when I try to access it from out side I faced the message says Internet Explorer cannot display the webpage.
your help is greatly appreciated
The Real Person!
The Real Person!
Have you added a DNS record to your public DNS zone for the OWA name?
So I did the migration and here is what I figured out. The Exchange server deployment Assistant will lead you to success. Exporting a certificate is a copy, not a move. Yes, if you configure for all external access to the virtual directories, you can use a cert that listed the internal name of the old server on your new 2013 server. 2013 exchange connecting to outlook clients in cached mode may ask for authentication because of a public folder query that times out. You can work around the issue with a registry tweak or disable cached mode. (http://blogs.technet.com/b/johnmak/archive/2012/03/26/how-to-stop-outlook-from-using-public-folders.aspx)
Most questions are answered somewhere in the exchangeserverpro site.
Hi Paul,
I’m migrating a small business from Ex2010 to EX2013. The 2010 server is configured to use local URLs for internal access. I want to set 2013 to use external URLs for all queries and I have added a public zone in my internal DNS to point mail.domain.com to the server’s internal IP. Three questions:
1) Will there be issues during the migration as the outlook clients switch to the new server?
2) My current SAN Certificate lists internal and external names for autodiscover and mail as well as the 2010 server name. If all I will need for the new server is the mail.domain.com and autodiscover.domain.com names listed on the SAN cert, can I export the existing cert out of 2010 and import into 2013?
3) If ok to use the existing cert, what is the general order of migration tasks regarding the cert? Configure the new server, move the mailboxes, change DNS to point to the new IP and then do the cert?
I appreciate your willingness to answer questions and thank you for the help
I want to use split DNS to avoid adding server name to SAN certificate .my question is :
after creation of forward lookup zone called mail.ab.com, what kinds of records must be create inside this forward lookup zone? is it only A record? . Is MX and CNAME records are necessary to be created in my private DNS server ?. and is it necessary to create this new forward lookup zone or I can add these records to the existing zone of my domin ?
thanks for your patience and cooperation
The Real Person!
The Real Person!
mail.ab.com would usually be an A record in the ab.com zone, not a separate zone.
Hi Paul!
I have the AD and internal DNS on server01.domain.com, the exchangesrv is on comm01.domain.com. Both on 2012 Srv R2
Anything is new and fresh 🙂
All entries internal and external of the virt srv show to comm01.domain.com
The outlook anywhere set up int / ext is also set to comm01.domain.com
The FQDN in the certificate are comm01.domain.com and autodiscover.domain.com
Actually the certificate was signed by the server01 as it is for a test.
Then the internal connectivity analyzer shows:
+ OutlookAnywhereConnectivitySucceeded 🙂
when it comes to the DNS look up of the hostname domain.com it gets the IP adress of Server01
so it logicaly can not open in the next step the port 443
then the resolving test of autodiscover.domain.com fails with the detail:
the host autodiscover.domain.com could not be resolved in InfoDomainNonexistent ???
same error with the HTTP redirection
then the SRV data _autodiscover._tcp.domain.com could not be found
then the hostname autodiscover.domain.com could not be found.
OK I’ve added the SRV entry and a A Name for autodiscover into the DNS Server
of course the resolving of the host domain.com is still the IP adress if the DNS Server (server01)
as the DNS is updated it can get the certificate but then it comes with the next:
The name of the certificate is not valid???
Details: the hostname: autodiscover.domain.com is not part of the certificate CN=comm01.domain.com
later ..
The name of the certificate is not valid???
Details: the hostname: comm01.domain.com is not part of the certificate CN=comm01.domain.com !aha!
meanwhile after hours and hours of error and fail I don’t know what to do..
1. Do I have to edit the internal DNS Server with the SRV and A Record entry of the autodiscover or any other entries?
2. When I create the certificate request do I have to highlight all services (e.g. Outlook Web App) or just one before click next ?
Regards
Victor
Hi,
One quick question: If you are using mail.exchange2013demo.com for all services (OWA, ECP, Active Sync etc), including AutoDiscover, to where should autodiscover.exchange2013demo.com point to?
The Real Person!
The Real Person!
Same IP address(es) as the rest of the CAS namespaces.
Thanks, Paul. =)
Pingback: heat shrink wrap
Thanks for the article. I’m finally getting to upgrade to 2013 from 2007. I went through all this, exported my cert from the 2013 server and imported it to a 2007 CAS, and Outlook started throwing errors because server.domain.local was not listed in the cert. After some further digging, I fixed with Set-UMVirtualDirectory because one of my CAS boxes has a local server name there, even though we don’t use UM or have it installed on any of our servers. Hope that helps someone else who might run into the same issue.
Hi Paul, after executing the command to change AutoDiscoverServiceInternalUri from server name to public (https://mail.mydomain.com/Autodiscover/Autodiscover.xml) I am getting authentication prompt as i open outlook 2013. So i had to change autodiscover back from public name to the exchange server name. Now i can open outlook without it being prompting for password but i am back to the certificate error prompt. This is some kind of infinite loop… Please advise Thank you
The Real Person!
The Real Person!
It really depends on how all your other namespaces are configured. I assume changing the autodiscover URI got you past that hurdle but the next thing Outlook tried to connect to wasn’t configured correctly.
You really need to review your entire set of namespaces, your certificate, your DNS (ie where the namespaces resolve to) and the auth settings configure for services like Outlook Anywhere.
Also it depends if you’re in a co-existence with a 2007/2010 server. The auth settings on the legacy server for Outlook Anywhere need to be correct in a co-existence otherwise endless auth prompts appear as Outlook tries to connect to legacy resources like shared mailboxes or public folders.
In the article you run ‘Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml‘ to set autodiscover service point to ‘mail.exchange2013demo…. ‘ But on certificate you say you add ‘autodiscover.exchange2013demo.com’. Is it mistyping? Could you please clarify how would it work, whats the meaning? Should not name on certificate match what you set up as autodiscover (or any other service, for the matter) for internal and externtal uri?
Thanks
P.S. Besides – that would make it two names, not one, on the certificate, which implies buying SAN certificate, anyway. Since it seems usually SANs certificates are incrementing in set packs (minimum to my knowledge is 5 names) it makes it kind of a mute point – if you get 5 names cert then you have enough names not to worry about minimizing them, that should be enough for most cases, right?
The Real Person!
The Real Person!
Some non-domain clients (such as smartphones) will automatically search for autodiscover.domain.com when trying to find the Autodiscover service. So it pays to add that record to DNS, and include it on the SSL cert as well.
That makes sense, understandable.
But then is it really important to what AutoDscoverServiceUtnernalUri is pointing to for Autodiscover service to work properly? Any website is capable of binding multiple host names to the same IP (and after all all the Exchange services access points are web based).
That is it seems that Autodiscover.domain.com web access point will work regardless of what is set up with set-clientaccessServer applet. Is it not the case?
In fact, should not other client access points (like OWA or OA) respond to more than one name if you bind IIS corresponding sites to more than one name, as well?
The Real Person!
The Real Person!
What you set the internal URI to is up to you. It can be any name you like. Domain joined clients look up that name in Active Directory.
Non-domain joined clients can’t look it up in Active Directory, so they will try autodiscover.domain.com (as well as domain.com).
Hey Paul,
What are your thoughts on split-brain DNS and Outlook Anywhere?
Ross Smith mentioned in his MEC 2014 presentation that a single namespace design could be problematic for Outlook Anywhere common authentication settings.
http://channel9.msdn.com/Events/MEC/2014/ARC302 – 47 minute mark.
The Real Person!
The Real Person!
Problematic if you’re using different auth schemes for the internal and external URLs. The same namespace means the client will always use the internalURL settings (including the auth settings), which may fail if the externalURL auth settings are different.
So the solution is to use a different external OA namespace if you have different internal/external auth requirements. This doesn’t prevent you from using split DNS though. The two namespaces can still be in the same domain (eg outlook.domain.com and outlookex.domain.com).
As Ross says, the end users don’t need to worry about two namespaces because Outlook is configured automatically for them via Autodiscover anyway.
I have setup my main Internet-facing site with one namespace for both internal and external urls.
My question is on my remote non-internet-facing sites that have Exchange servers:
Do I set the Internal URLs to the local server names ( I want local clients to connect to that server in their site)
or
do I set the Internal URLs to the single name space which DNS resolves to the Exchange servers in the main site (via a F5 with main site servers only configured). If I do this then all the traffic will be going across the WAN.
The Real Person!
The Real Person!
If you want to guarantee clients connect to that local server then you’ll need to plan namespaces for that site.
I don’t recommend leaving them as the server FQDN.
An example might be:
– primary site uses namespaces mail.domain.com and autodiscover.domain.com
– secondary site uses namespaces mail-sydney.domain.com and autodiscover-sydney.domain.com
Hello Paul,
thank you for your example. I have more than 10 Server on remote sites and only 1 internet facing Exchange. I would take also a look at the costs and use only as much SAN Names as i need. But i currently planned to use :
Internet Facing Site
Site 1 : mbx1.domain1.com
owa.domain1.com
autodiscover.domain1.com A Record to local CAS on Site 1
Site 2 : mbx2.domain2.com
owa.domain2.com
SRV _autodiscover._tcp.domain2.com pointing to autodiscover.domain1.com
and so on….
Do i really need to use a OWA Entry in SAN Certificate for each Site ? What do you think about the Design above?
Thank you very much for your reply.
The Real Person!
The Real Person!
If you want each site’s mailbox users to connect directly to their site’s server for OWA, then yes each server needs a unique OWA namespace.
If you want them all to connect to a single site for OWA (which will proxy to the appropriate server), then no you don’t need a unique OWA namespace for each site.
because the urls for external access are not the same as internal.
internal we use servername fqdn,cas2.dom.local and external url mail.etc…
one can not interna server fqdn names for commercial certificates and we must keep separate urls
for external owa and internal owa
is the process I have described before to configure the internal autodiscover scp url to the second cas server
or do I have to do something else?
I have read it in exchange deployment assistent
my problem will be resolved if I get to configure the autodiscover service to only the cas
I know you see that as a complex senario but I really have no other way to implement it.
that is why I asked you those few questions.
I really appriciate your feedback
The Real Person!
The Real Person!
But you aren’t locked in to that solution are you? You can change the internal URLs to anything you like, they don’t need to match the server FQDN or even the internal domain FQDN. It is even quite common to use split DNS and have matching internal + external URLs.
Autodiscover is just one part of the picture too. Autodiscover tells the client the URLs for other services like Exchange Web Services, Outlook Anywhere.
If you’re dead set on this internal vs external split I would suggest moving the internet-facing CAS into a separate site and using Autodiscover Site Affinity to control where clients get their Autodiscover information from.
Another option is to put a reverse proxy in front of Exchange that can handle the public facing SSL connectivity with just the public names on the cert, then you can still use your own CA to provision the cert for Exchange that has both internal and external names on it.
Is not the Site Affinity option depreciated for Exchange 2013? It looks like due to certain ‘decoupling’ of CAS and Mailbox servers it would not work the same way as in 2010, if at all.
The Real Person!
The Real Person!
Site scope still exists as an option for Exchange 2013 CAS/Autodiscover. You might be thinking of the changed requirements around session affinity?
Yes, I guess so. I really need the feature to be able to associate users in one area with their closest mailboxes servers. But googling for Site affinity only brings articles related to Exchange2010. Considering the change of client access architecture in 2013 I have concerns if the feature still works or if changes in functionality change its meaning.
And I don’t see any other way to enforce users, say, in Atlanta to connect to Atlanta site instead of, say, to NewYork site while both sites are healthy and still have the site redundancy (for cases when one of the sites is down).
The Real Person!
The Real Person!
If you want to control which users go to specific sites *and* have site redundancy for that namespace then you’ll need to deploy geo-DNS and/or geo-load balancing.
More complex. More expensive.
If the bandwidth is sufficient between Atlanta and New York to be doing site redundancy anyway (ie stretching a DAG across those sites) then why does it matter who connects where?
Simpler. Less expensive.
Thank You Paul
we have done somthing different. we installed two cas, cas1 will be used only for the external urls and cas2
will be only used for the internal clients
so now I am struggling for more than two hours now to configure the autodiscover scp for the internal clients to use the cas2 but the service is connected to cas1
how can I change this
I used the follwoing command
Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like “Version 15*”) -And ($_.ServerRole -Like “*ClientAccess*”)} | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://cas2.dom.local/Autodiscover/Autodiscover.xml
and when I run the
[PS] C:Windowssystem32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like “Version 15*”) -And ($_.ServerRole -L
ike “*ClientAccess*”)} | Get-ClientAccessServer | Format-Table Name, AutoDiscoverServiceInternalUri -Auto
Name AutoDiscoverServiceInternalUri
—- ——————————
CAS1 https://CAS2.dom.local/Autodiscover/Autodiscover.xml
CAS2 https://CAS2.dom.local/Autodiscover/Autodiscover.xml
but the outlook client wants to connect to cas1
how I can change it to connect to cas2
Thanks alot for your feedback
The Real Person!
The Real Person!
What possible benefit do you think you are providing by doing this? All I can see is needless complexity.
Hello
I have a question about separating exch 2013 certificates for internal and external urls
I currently transition drom exch2010 to exch2013. I have configured a ssl certificate from an enter CA (internal domain) for all internal sites, owa ecp ews autodiscover etc.
I have imported the certificate and everything works fine, I can logon to owa internal url and outlook clients are connecting to exch2013 without any cert errors or a when a new outlook profile is created for a exch2013 user mailbox
so far so good
Now I want to configure the external exch2013 urls from getting a certificate from a commercial ca.
This certificate MUST only be used for the external url.
The internal urls MUST use the already confgured certificate from the local enterprise CA.
So I configured the external access domain name on servers -> virtual directories and the process completed successfully.
I then started the cert request on the exch server to submit the new request to get the certificate.
In the option “Specify the domains you want to be included in your certificate” under option DOMAIN
I removed the internal urls from all domains and left only the external url to be used with this certificate so as under domain for the internal url set .
When I get the new certificate and want to complete the pending request, should I enable iis or both iis and smtp?
for the smtp transport I use the certificate from the doman CA.
According to this I suppose that this certificate will be only applied to external urls right?
The same I did for the internal urls getting the certificate from the enterprise ca. I habe set the external urls
as not specified and left only the internal urls to be used by the certificate from the local ca.
Your feedback is very appreciated.
Chris
The Real Person!
The Real Person!
The certificate you enable for IIS must include all of the DNS names you configure on your virtual directories, both external and internal.
Pingback: Exchange 2010 to 2013 Migration - Reviewing Autodiscover Configuration
Hi,
I followed the article and now outlook giving the certificate error.
information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.
Please help
Outlookproviders are looking good msstd:*.domain.com
AutodiscoverServiceInternalUri is also pointing to mail.domain.com so that looks good to.
And may I ask another question? Since I changed both autodiscover URL’s to the public domain, notebook users who also work externally have a problem that the proxyverification switches back from basic to NTLM. Our TMG server doesn’t do NTLM so you cannot login. If I change the setting in Outlook to basic it switches back after a few hours. Do I need to set the internal verification to negotiate?
Hi Paul,
Got me a situation here. I used a wildcard cert for exchange 2013 sp1. Everything works fine externally but internally Outlook 2010 wines about the cert that mailserver.domain.local is not in the cert.
I don’t understand where this is coming from. All my virtual directory urls (in- and external) are the public urls (we use spit DNS).
When I look in the Outlook accountsettings the proxy adres looks good https://mail.domain.com
Any hints? I have red all internet forums by now.
Thanks in advance.
J-W
The Real Person!
The Real Person!
I would say either an Autodiscover URI or the EWS URL is still using the server FQDN.
It’s weird. Only Outlook 2010 clients (allmost all client pc’s) got this problem.
I figured out whats the problem. Proberbly there’s something wrong with the Outlook profiles. Our Exchange 2013 server was in co-exist with a 2007 server. NOTHING points to this old server anymore. Oab, mailboxes, etc is on the new server. However, last month I turned the old server off to make sure everything works fine. All the Outlook 2010 clients got really slow until I turned the old server on again.
That server is stil on. Yesterday I thought: lets change the internal url of autodiscover on that server to the public one. Now Outlook 2010 doesn’t show the “do you trust the cert Yes or No” error. Only at startup “bla bla cannot connect to the proxy server (error 10).
This is solved when I make new Outlook profile. So proberbly there’s someting corrupted or something and the 2010 clients were also connecting to the old server. Which is strange in my opinion cause there is no A or Cname records that points to that server.
I hope I can turn the old one off now when I give everyone a new profile.
Have you ever heard of this before?
The Real Person!
The Real Person!
It absolutely should not be required to recreate everyone’s Outlook profile to resolve this. I would say that the issue is your oldest server has an autodiscover URI configured with the wrong name. You should probably also check your Outlook providers.
J-W, why, do you think, do your Outlook machines try to connect to the name mailserver.domain.local? You said you are using split DNS which means that your forest root domain has the same name as the smtp domain name domain.com. Did you by any chance rename your AD domain from domain.local to domain.com in the past?
If your AD domain is domain.local it is not enogugh to create the domain.com domain on the local DNS Server to get a split DNS Exchange Organisation. Domain joined clients will still try to connect to the Service Connection Point using host names in the AD domain and you will have to get a new certifcate containing the internal names.
O, I thought this was called split dns:If your AD domain is domain.local it is not enogugh to create the domain.com domain on the local DNS Server to get a split DNS Exchange Organisation.
We use this.
New certificate with internal names is not an options because is 2015 it is not allowed anymore to use local names in certificates.
J-W, Read Paul’s article about certs for .local domains:
https://www.practical365.com/ssl-requirements-for-exchange-when-certificate-authorities-wont-issue-certificate/
There is (in my opinion) no need for you to migrate your .local domain to a public one.
Since you are using TMG the best solution is to create another web site on your cas server and create new virtual dirs. in that one. Enable forms based authentication on this one and use it for internal access. install Certificate Server and request a certificate with the internal names for the internal site.
The public cert can be tied to the default web site. Export it to the TMG.
In this way you get a TMG bridge and forms based authentication enabled both internally and externally.
I always use two web sites on my cas servers to get FBA both internally and externally
Hi Mikael Ljung,
I don’t have plans of going to migrate my .local domain because I know it could work the way it is now.
Yesterday I inventoried how many Outlook 2010 had this “Error 10” problem and found out that not everyone on Outlook 2010 has this issue. So for the users who had the problem I recreated the Outlook profile and the problem was gone.
I only bumped into a other problem discribed in my last post below.
Hi Paul,
Can I run the two cas servers in an nlb cluster instead of having a round robin solution as in your example?
Hi Paul,
Thanks for all great articles,
I was wondering about the Round Robin trick of yours; is there a reason why we should use that instead of Windows built-in NLB. Except for two network adapters there shouldn´t be any additional costs, should there? Or, is there another reason why NLB should not be used?
The Real Person!
The Real Person!
My brief thoughts on the matter of NLB here:
https://www.practical365.com/exchange-2013-client-access-server-high-availability/#comment-19266
Hi Jack,
Can you connect internally to all the virtual directories (owa, ews, ecp …)? I guess that autodiscover.yourdomain.com is not included in your SSL certificate since you are trying srv records.
If this is the case: remove the A record for autodiscover. The srv record will not work if you have an a record or c name for autodiscover.
The address record should be there only if you have an ssl certificate with autodiscover.yourdomain.com included. In that case there should be no srv record there.
Also remember that srv records are not supported by androids and iphones.
Read Paul´s article thoroughly and make sure that all the names that you get from running his powershell commands are in the certificate. If you have problems internally: do remember that the internal domain name that should be used should be the forest root domain …. so if your domain is a .local you will need to create a second web site with owa and ecp virtual directories. Then you need to install a certificate server and issue your own certificate for the internal names.
Good luck with this!
Hi Sir Paul,
Can you please help me? i don’t know where to start. I just want to set up autodiscover in exchange server 2013. Can you give me a step by step procedure on configuring autodiscover? because when i run microsft exchange analyzer all URLs for autodiscover is connection failed. I setup SRV in domain manager, i created host A for autodiscover pointing to public ip address, i created SRV for autodiscover in DNS manager under forward lookup zones and our domain.
thank you and more power!!!
Thanks for this great article. It was really useful. Just two names in the cert makes things a lot simpler especially when you want to add CAS servers.
But, what about exchange 2010 … can I achieve the same thing there?
The Real Person!
The Real Person!
Yes you can. Basically the same concept and process.
Paul, Got an answer for my Question.. was bit confused over things… As stated in the article the self signed cert binded with SMTP still exist in the servers and things are working as desired, next time when I renew the certs will address the TLS needs with the new SAN
http://technet.microsoft.com/en-us/library/bb430748.aspx
Additionally I reviewed one of the Earlier post of our MVP Paul Robichaux where he insists its better to have a 3rd Party Commercial CA installed which address TLS requirements for secure Mail flow sooner or later
http://windowsitpro.com/exchange-server-2010/use-tls-smtp-secure-your-email
One more point to Add I did the binding for IIS which is required and included POP/IMAP and SMTP when performed the Service bindings and over ride the default SMTP when it prompted me as I said above and just want to ensure that will this cause cert warnings on clients or it will work with out issues.. Thanks once again!!
Paul, Thanks for the reply, I have one more query, recently I installed a SAN certificate that did not contained names of my HT servers on it and assigned the SMTP service in the service bindings and when it asked me to override the default SMTP I clicked Yes and I have multi role servers so Installed this cert on all the boxes (with SMTP binding )which was required for a recent change I done in the environment with respect to CAS, Also I did not remove the self signed cert installed on the box and it still showed SMTP service as assigned . In this scenario will the client receive any security warning for this HT names not being on cert or the email flow will continue to work without issues, still I was confused on this part. Kindly educate me on the same… Thanks a Bunch!!!
Paul, Thanks for the great Article!!!
I have a small query and this is not related to Exchange 2013 its for Exchange 2010, Apologize that I ask this here.. my question is do I need to include my HUB server FQDN on the SSL certificate if I have multiple AD sites and I have both HT and CAS installed on the same server if I missed to have the FQDN of HT in place will there be any issues on the mail flow, some where I read that email between AD sites are encrypted for which TLS is used and Need to have the HT server name in cert.. kindly suggest me on the same.
The Real Person!
The Real Person!
SMTP can use a different certificate than the one that is enabled for IIS. So you do not need to include Hub Transport server names in the certificate.
Paul a question from Argentina.
If I have an installation of 2 servers virtualized Exchange 2013 with 600 mailboxes, is it necessary to install a balancer Netscaler?
Can I use only DNS Round robin and a space of unique servers?
What do you think?
Thanks in advance for the article!
Greetings, Angel.
The Real Person!
The Real Person!
How you choose to load balance is entirely your decision.
DNS RR is zero cost and works to provide basic HA but no load balancing.
Load balancers are more robust and have more ability to detect service failures and route traffic accordingly, but come at a cost.
Thank you!,
one more question Paul, knows some comparative load balancers?
Greetins.
The Real Person!
The Real Person!
Look at Kemp and F5.
Hi Paul
Thanks for all your write ups, very helpful and informative.
This may be a stupid question, but if we set both Exchange server virtual directories to all the same url, e.g. mail.domain.com, but only have one DNS record, pointing to one server, then will this not cause problems? So the client will always be directed, via DNS, to the one server? Or will that server redirect the user to the second server if their mailbox is on the second server?
Also, do you know if there are any problems with doing this on an mixed 2010 / 2013 environment? I am wanting to do a migration from 2010 to 2013 but over a number of days, I only have mail and autodiscover on one SSL certificate, so to avoid certificate errors I thought I could just use the same cert on both servers, and as you have suggested set all the virtual directory URLs to mail.domain.com
Does this sound like it will work and keep both servers with valid certs, whilst keeping all users connected to the relevant server where their mailbox resides?
Sorry if this doesn’t make total sense, still trying to get my head around Exchange architecture.
Thanks
I am setting up a new Exchange 2013 Server and I followed your article on configuring the internal / external URL’s to a FQDN. I purchased a UCC SSL Cert From Godaddy and installed it on the Exchange server, but whenever i use the browser to connect to the OWA, I get a Certificate Error. The certificate displays the internal host name of my Exchange server instead of the URL. Any thoughs?
Thanks in advance..
Paul
The Real Person!
The Real Person!
Have you assigned the certificate to IIS?
https://www.practical365.com/exchange-2013-assign-ssl-certificate-to-services/
Thank you Paul. I did have the Cert assigned to IIS but realized with the help of your tutorial that I did not check off any of the services for the SSL Cert. Once I did that and performed and iisreset, the certificate error was resolved. It appeared that the self-signed cert was enabled and providing the errors.
Thanks again for your help and quick response.
Paul
I am building an Exchange 2013 on a server 2012. The Domain is not a tld, it is a .lcl . My question is how do I get the internal e-mails to go to external contacts in other domains?
The Real Person!
The Real Person!
I’m not sure what you mean?
Outbound mail flow in Exchange 2013 requires a send connector to be configured:
https://www.practical365.com/configuring-outbound-mail-flow-in-exchange-server-2013/
Hi Paul,
Ive been following your guides for our exchange server 2013 install. We have 2 sites with exchange servers. Our main site has seperated mailbox and client access servers while our secondary site has a single vm running both mailbox and cas. the mailbox servers are setup in a DAG with a witness server at a third location. I was following the above guide and the virtual directory changes were taking a long time to complete about 10 to 15 mins. I saw the same issue when trying to make the same changes through ECP. All of the changes did take effect but after the final change to the autodiscover uri I can no longer open owa or ecp via internet explorer. Also outlook is no longer able to connect but active sync is still working. I changes the values back to defaults and that breaks everything including activesync. Any advice would be much appreciated.
Thank You,
Jason Adragna
When i run the Get-OutlookProvider command I get no servers listed for EXCH,EXPR, or WEB. Navigating to the autodiscover folder only shows web.config file and no autodiscover file. Please confirm i am looking in the correct location for the autodiscover file?
C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxyAutodiscover
After a restart the owa and ecp through IE are working again and so is outlook. Probably should of restarted before I posted :).
Hello Paul! Thank for this article!
But I have a little question. As far as I know Microsoft’s best practice for now is to use a subdomain of company’s public domain for AD domain name (local.company.com for example). What names should I use in my certificate in this case?
Or your recommendation is to use company.com as AD domain name?
The Real Person!
The Real Person!
I make no recommendation about AD domain names and you’re free to follow the established best practices.
The Exchange namespaces can be the same, a little bit different, or a lot different to the AD namespace. Only the Exchange namespaces need to be on the SSL certificate.
you forgot to change the fqdn on the ReceiveConnectors as they would now only find the selfsigned certificate from the setup to match server1.acme.local and use that for SMTP TLS.
i like to use Server FQDNs in the Exchange Server certificates if the Customer has a local CA, as certificates then dont cost anything and i have easy troubleshooting some scenarios without editing hosts to circumvent the Loadbalancer.
External Certificates are then only needed on the ReverseProxy if services are published to the internet, that is if all internal clients are trusting the internalCA, which should have been a goal when implementing that.
The Real Person!
The Real Person!
Yes, I left SMTP out of this tutorial. Of course with SMTP we also have the option to bind a different cert to that service, as opposed to all the ones in this article which use the cert bound to IIS instead. The SMTP cert is also not something that will cause client-side issues for most orgs.
Agreed, an internal CA is a good way to avoid SSL costs.
how can you bind a specific cert to SMTP in E2013?
i’ve tried it via GUI and use Enable-ExchangeCertificate but did not succeed?
i agree TLS is rarely used internally if you dont have a lot of User with IMAP clients.
Hi Paul,
another great article, thanks for this!
Just a quiclk question if you don;t mind. I have two multirole exchange server and I’ve configured them in round robin for HA, as discussed in another article.
I have both internal and external users, and I’ve configured the same name for both ExternalHostname and InternalHostname? The name I’ve used is the name space configured in RR on the DNS.
Are you aware if this is against the best practice or simply irreleavant? I’m aware EX2013 has a different behaviour in autodiscovery from 2010, and I run into an issue when I moved mailboxes from 2010 to 2013.
I’ve descrived in this post of mine: http://social.technet.microsoft.com/Forums/exchange/en-US/f19376ca-9a67-4d0e-a5c4-cec54e36027d/sslmsstd-settings-outlook-anywhere?forum=exchangesvrclients
I’d appreciate if you could take a look, an advice of yours would be more than welcome!
Thanks!
The Real Person!
The Real Person!
Using the same namespace for internal and external Outlook connections in Exchange 2013 is fine, and I believe Microsoft even encourage it as a best practice.
Hi Paul,
Just to clarify something. In your example you mention simplifying the cert to use ONE namespace for all of the services. All of them being https://mail.exchange2013demo.com/…
Even the autodiscover virtual directory is https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml.
And in your example of the Exchange Management Shell command for Autodiscover, you list the command, changing the URL to “mail.exchange2013demo.com”.
However at the end you say you always include the “autodiscover.exchange2013demo.com” fqdn in your SSL certs? Why would you do this if you configured everything for “mail”?
Couldn’t you just have one standard cert for “mail.exchange2013demo.com” for everything and be set?
Just setting up my first Exchange 2013 server so just want to make sure I’m on the correct track. Otherwise, thanks for the detailed article.
jonathan
Thank you for the nice report!
Im also confused, about the autodiscover*… why you are using *.de/autodiscover.
The Real Person!
The Real Person!
The “autodiscover” name is a well-known CNAME used for AutoDiscover in some scenarios, such as mobile devices setting up their email account. As such I always recommend including it on your certificate, even when you’re using a different AutoDiscover namespace internally.
Sorry Paul… Hope this helps a bit. We have split DNS like many other organizations. So, I went through each of the steps you recommended in the article above. Such as get-owavirtualdirectory, get-oabvirtualdirectory, etc. Essentially, the only directory that returns results that are NOT set to our public domain name is the OAB Virtual Directory, which returns a path for the internal server name(s).
If we set the virtual directory path for the OAB to the public domain address, like the other resources, does that in itself resolve the issue? I wasn’t involved in the original establishing of the URLs for these Exchange resources so I don’t want to break something else that isn’t broken by fixing that. We just want to remove the local host names from the SSL certificate.
As far as I understand it, the SSL cert with local host names is being used to secure the OAB directory and Outlook client to server communications as it now stands. Obviously is is securing SMTP, IIS, etc. as well but that’s not the concern here. Would we then need to generate a certificate internally (we have an MS cert server) to secure the OAB directory and Outlook to Exchange communication without errors?
The Real Person!
The Real Person!
All those virtual directories are part of the default website in IIS on the server. There is one certificate bound to IIS (which you can see in Get-ExchangeCertificate).
So I’m not sure if you’re thinking that the OAB virtual directory needs its own separate cert… it doesn’t. So if you’re switching the URLs for the OAB virtual directory to a name that is already on your IIS SSL cert, then that should work.
If you then want to provision a new cert to enable for IIS, that has the same names except for the server FQDN, then that would likely work fine. I can’t see your servers and config though so no guarantees 🙂
The Real Person!
The Real Person!
“…when I check the hostnames for the Offline Address Book, both the internal and external URLs are null. Both lines returned are also the primary mailbox server in our production DAG of two servers.”
I don’t understand your scenario.
Great article Paul! I certainly appreciate the time you take to share your experiences with us and the knowledge you impart.
In our envirnoment (mixed Exchange 2010/2007 – 2007 only around as a mailbox host for our voicemail services, no outside traffic to or from that one), when I check the hostnames for the Offline Address Book, both the internal and external URLs are null. Both lines returned are also the primary mailbox server in our production DAG of two servers.
We’ve been including the local machine name in our SSL certificates for our HUB/CAS combined role servers but I’m not even entirely sure why. When I check the URLs for the other virtual directories, they are all pointing to our external domain URLs.
Can we really just set the url to match our external domain URL? Is there any negative effect on clients that we should watch out for?
Thanks!
Absolut great article! I have lot of small business customers who just love to use only a certificate with a single name. So I create an interenal shadow domain (same as the external name) and create there a SRV Record and an A-Record who points to the same name as external. e.g. “mail.test.com” but with the internal IP Adress.
Just one question, what is wrong with the following command?: Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –InternalUrl
The Real Person!
The Real Person!
The Autodiscover virtual directories have internal/external URL attributes but they are ignored by Exchange. Setting them has no impact.
Hi Paul, the active sync and oab urls are pointing to an internal server URL. Wouldn’t you get an error if they are not names on the SAN certificate?
Also as the other internal URL s are pointing to a server name I take it the external URL is queried first? Thanks again. Martin
Hi Paul,
Thanks for the article.
Just wondering what’s involve when changing the external URL name once it’s been setup.
One of our customer is currently using an address: remote.domain.com which is also being used for pretty much everything else published on the Internet (RD gateway, Extranet…).
We’d like to update that name to mail.domain.local getting a new SAN cert only for exchange that includes auto discover.
Are the outlook clients going to detect the new url automatically and update their outlook anywhere settings?
If not is there a way to get around this so we don’t have to update it manually for each outlook client.
Thanks,
Florian
Hi Paul
Thanks for article
one question:
cant we avoid the autodiscover.domain.com name on cert?
(this way we only need one name and no SAN/UC)
I mean internally its no brainer and external client will use:
domain.com/bum bam bam/autodiscver….
and only then autodiscover.domain.com/bumbam/autodiscover….
?
The Real Person!
The Real Person!
If domain.com resolves elsewhere (eg to the web server that hosts the public website) then autodiscover.domain.com will be needed.
I always include it.
you are correct
most of them do.
another option is to use srv records
(im just trying to think lower costs for small business:)))
What about the Autodiscover process in an AD site? There the Outlook Client looks up the AD for an Connectionpoint first before doing lookups on (eg) autodiscover.domain.com and mail.domain.com/autodiscover.
The value can be found with help of ADSI within Configuration Partition > Services > Microsoft Exchange > %ORG% > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers > %NAME% > Protocols > Autodiscover | Here you can find the an ServiceConnectionPoint with the Key serviceBindingInformation. Is there a need to change it’s value as well?
Oh my… seems that i’m still not wide awake. The SCP is already explained (didn’t see).
– Sorry for asking stupid questions –
Keep up this awesome Blog! You are doing really great work here!
use site affinity
-AutodiscoverSiteScope
Hi Paul,
I can’t use the “Internalhostname” Paramter of Set-OutlookAnywhere Cmdlet. It seems it doesnt exist
(Exch2010SP3UR2)
I figured it out on myself.
Exch2010 doesn’t have this options =(
Pingback: SSL Certificates for Exchange Server 2013