Suppose many companies are using Exchange 2010 for email hosting, and each company has a different TLD / Domain. The email hoster does not want to add Subject Alternative Names and opts for the SRV configuration of Autodiscover.
How important is it that they correctly configure the SRV record with the name _autodiscover.clientPrimarySMTP.com and have it point to serversubjectname.hoster.com?
What would break if the SRV is missing or misconfigured?
I suspect that 2007 and newer clients who are having issues with Out of Office rules is likely related to this.
Autodiscover will configure the following services within outlook:
The issue was reproduced with the following settings:
Configuration
School1 has a domain name of school1.edu. They host email at hoster1.com. School1 uses the "srv" method of locating the autodiscover record for autodiscover.hoster1.com.
What was broken
There are 200 different schools who are using the above mentioned configuration. We discovered a trend with customers having errors with OOO, OAB, and FreeBusy. This occurred for Outlook 2007 SP2 and newer clients who were previously on Exchange 2003, and migrated to 2010. All the profiles were set up manually.
Outlook 2003 was unaffected, since it uses Public Folders.
How we fixed it
The guidance was for the helpdesk to check the SRV record and correct it as necessary. In a majority of the cases, the SRV record was invalid or missing. The trick was to ensure that both external and internal DNS was updated with the correct SRV record (in the event school1.edu also had an internal DNS)
Lastly, due to how outlook first checks for an A record at autodiscover.school1.com, some DNS servers returned the results of a wildcard entry. Removing the wildcard fixed the issue. For people who want to keep the wildcard DNS entry, they may want to try creating the autodiscover.school1.com record as a CNAME or an A instead of an SRV (though I haven't tested it)
If an autodiscover record doesn't exist, then clients will need to manually configure their Outlook and mobile devices. If it's incorrectly configured then you run the chance of clients getting the wrong settings applied to their Outlook or Mobile devices which can cause all sorts of issues.
To answer your direct question: Nothing would break if you don't configure SRV record on public domain. In fact, I don't even do it because even though the docs claim Outlook 2007 supports this, in my experience it plain doesn't. Only Outlook 2010 does. It's just Yet another strategy to get users to pay for the latest product.
What I do, is this:
If yes: {
If yes: You should now either disable port 443 on your public web server, or change the A record for "domain.com" to your Exchange box public IP.
If no: You should now ensure the same certificate is used on your IIS box and covers autodiscover.domain.com without error.
}
Now:
Add an A record for "autodiscover.domain.com" to your Exchange box public IP.
Obtain and install an SSL certifcate for CN=autodiscover.domain.com. This could be a free SSL certificate as we only require one host name to be secured here. If you want to be fancy and allow for "mail.contoso.com" to work, then be prepared to pay £60/year to GoDaddy for a UC/SAN SSL certificate.
Ensure https://autodiscover.domain.com/autodiscover/autodiscover.xml shows some xml after logging in, and pressing F5 shows a new time stamp each time you refresh the page. Ensure http://autodiscover.domain.com/owa loads as https. Both should have no certificate warnings.
Check the URLs for autodiscover using these Exchange Shall commandlets:- Get-OABVirtualDirectory Get-ClientAccessServer Get-WebServicesVirtualDirectory Get-PowerShellVirtualDirectory Get-ECPVirtualDirectory Get-OWAVirtualDirectory Get-ActiveSyncVirtualDirectory Get-AutodiscoverVirtualDirectory