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!!