WARNING: The Set-ClientAccessServer cmdlet will be removed in a future version of Exchange. Use the Set-ClientAccessService cmdlet instead. If you have any scripts that use the Set-ClientAccessServer cmdlet, update them to use the Set-ClientAccessService cmdlet. For more information, see http://go.microsoft.com/fwlink/p/?LinkId=254711.

MS could have avoided this broken by design approach by making all new Exchange server installs put into a Deployed state, leaving them excluded from the AutoDiscover process until they’re properly configured, validated and put into a Production state. Scripting an AD Site /32 hack for the new server is the best workaround to avoid unnecessary helpdesk calls.

Just to add to and clarify this answer, you can add a forward lookup zone of external.com in your internal Windows DNS servers, and then add an A record for mail.external.com in the forward lookup zone, pointing at your internal server IP address. This way when clients locally lookup mail.external.com they are instead returned the INTERNAL IP of your mail server. Since they are requesting the DNS name mail.external.com, the certificate is valid. As long as your internal URL is the same as the external, the clients won’t be asking for the server.internal.local address, because the SCP specifies the external DNS name, and the Autodiscover will too.

The trick is to use the cert for your external namespace by using the external namespace internally, by adding that namespace as a new forward lookup zone in your on-premise DNS. Optionally if you use the router for DNS, add another conditional rule which points at the internal DNS server for your external domain name.

The problem you will have is when you change web server, you need to remember to update the www record in you internal DNS as well.

I re-used the wildcard cert from the previous server. all namespaces are correct, also all dns records are present and resolvable.

but still internal Outlook users gets the certificate warning from the internal servername. when you check the connectionsettings it points to the correct namespace. (mail.domein.nl)

could the warning be displayed because of the wildcard certificate?

Hi Phil,

From my understanding, you cannot include any “.local” domain names in SSL certs anymore. Folks used to include them in the SAN field of the certificate (a security risk).

You could use DNS to control the resolution I believe if you setup a DNS forwarding zone (and it’s corresponding reverse lookup zone). Basically, the additional DNS forward zone will route DNS lookups of “.local” to whatever you specify. Basically, the DNS lookup for “.local” will go out your firewall and then back in, where it will routed appropriately, just like all other external users.

Bingo. thanks!

Our internal Exchange server name is like this…
fbvexch.domain.local

Our external domain for OWA is like this…
remote.domain.co.uk
this resolves to the internet address of our SonicWALL firewall that routes the traffic through to the IP address of the Exchange server.

#desperatecryforhelp #willhavelotsofgrumpyusers

I think the most common mistake is that most of the people don’t change the Clietnaccess Server settings on the 2010 server to point to the New Exchange serverand that’s why they get the Certificate warning
i.e (As your settings)
set-clientaccessserver -identity EXHANGE2010 -AutoDiscoverServiceInternalUri https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml