Exchange 2013 / Exchange 2016–a quick note about Server FQDN aka NLB fqdn
While planning or deploying Exchange 2013/2016, don’t forget these to have the correct Load Balancing on your Exchange 2013/2016 servers:
Assuming your Exchange 2013/2016 namespace is mail.contoso.com, which points to your Load Balancer’s IP address.
Set Outlook Anywhere Internal and External URLs to mail.contoso.com
https://practical365.com/exchange-server/exchange-2013-client-access-server-high-availability/
Use the following:
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname mail.contoso.com -InternalClientsRequireSsl $true
Note that Paul Cunningham gives an example using –InternalClientsRequireSsl $false, which is good as well since internally we usually use Kerberos which encrypts per-se critical authentication data flow within the http flow – but on my case, clients were on a different network zone, which had only port HTTPS (443) opened from clients to the E2013/2016 servers zone, hence the -InternalClientsRequireSsl $true on my case.
and of course, also ensure that mail.contoso.com is resolved – you can either use nslookup or this neat Powershell command:
Resolve-DnsName mail.contoso.com
Thanks Paul Cunningham for these, I discovered “Resolve-DnsName” cmdlet
- Note about the RPCClientAccessServer property
Althought present, that property is not used anymore in Exchange 2013/2016 database objects – in Exchange 2010 and back, it was used for autodiscover to give the RPC endpoint fqdn (NLB usually) to Outlook clients – remember Exchange 2013/2016 use HTTPS only now for Client <-> Server communications …
That’s just a quick note, thanks for forgiving me for the drafty formatting here
cheers
Sam
Comments
- Anonymous
September 15, 2017
Nice Post!!