Hello ladies and gentlemen,
I have been supporting one of our clients who we migrated onto Windows Server 2012 with Exchange 2016 (from SBS 2011) and they have had a recurring problem since we set this up for them; when inside of the local network Outlook constantly warns users that the server name is invalid for it's security certificate.
This does not happen outside of their network as the server has a wildcard certificate for their domain (let's call it "company.co.uk") which matches their site name.
However, inside the local network the server still hands over this certificate to Outlook, but now it is incorrect since the server is on "company.local". Seemingly there is no way to work around this using group policy or DNS.
Further to this, I am aware that you can name a domain "internal.company.co.uk", which would have avoided this problem, however since this domain is a migration from SBS 2011 which we inherited we can't do anything about that.
My question is, have any of you encountered this problem before, and if so how did you fix it?
.local! I feel rage!
I don't understand how the host resolution is working for your network, but if you make your 'outsidename.company.co.uk' work inside your network too, then all should be well.
I'm not sure why SBS pushed admins towards a .local domain on creation, but it's definitely caused us problems here.
Might you have any idea how to get the server to present as "server.company.co.uk" or something similar?
Thanks.
Me either, Microsoft really went nuts with SBS creating the worst defacto standards so that everyone working for small business customers learn nothing real.
Maybe this will help:
Thanks for this guide. Although it didn't let me directly, it did lead me to several other guides, finally finding this one:
http://www.mustbegeek.com/configure-autodiscover-in-exchange-2016/
I finally did manage to fix the problem (I think) and I will outline what I did below for anyone unfortunate enough to be stuck in the same situation:
Typing in "Get-ClientAccessService" returmed "Get-ClinetAccessService is not recognized as the name of a cmdlet"
Instead the cmdlet I needed was "Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri", which returned "https://server/Autodiscover/Autodiscover.xml"
So I ran the following:
Set-ClientAccessServer -Identity server -AutoDiscoverServiceInternalUri https://autodiscover.domain.co.uk/Autodiscover/Autodiscover.xml
Following this the internal certificate error stopped. Yay!
However, internal audiscover failed to work...
To fix this I had to add a forward DNS record to the internal DNS server with the following settings:
CNAME - autodiscover.domain.co.uk
Destination - server.domain.local
After al this nonsense it appears that the issue is fixed and clients can connect externally and internally with no certificate errors.
Thanks again for your help, hopefully people who need this can find it :)
1 Like