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, which points to your Load Balancer’s IP address.

Set Outlook Anywhere Internal and External URLs to


Use the following:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname -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 is resolved – you can either use nslookup or this neat Powershell command:


Star Thanks Paul Cunningham for these, I discovered “Resolve-DnsName” cmdlet Smile


- 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



Comments (1)

Skip to main content