By default, connections from Outlook to Exchange 2013 are authenticated with NTLM. However, in environments with several CAS servers and many clients, NTLM generates unnecessary load on the DCs, precisely because load balancers no longer have to worry about persistence. It is better to use Kerberos authentication here so that not every CAS server has to re-authenticate the connection. In this howto, authentication is switched to Kerberos with fallback to NTLM. My test environment currently only contains one Exchange 2013 server in the standard configuration.
In the first screenshot you can see that connections are authenticated via NTLM and Outlook currently uses the FQDN (ex1.frankysweb.local) as a proxy server:
First of all, a general access point for Outlook should be defined. To do this, I create the Host-A record "outlook.frankysweb.local" and enter the IP address of my Exchange server as the IP address. If several CAS servers are used, this entry can either be created multiple times with the respective IPs of the Exchange CAS servers (DNS Round Robin), or if a load balancer is used, the IP of the load balancer can be entered
As soon as the DNS entry has been created and can be resolved by the clients, the Exchange web services can be configured to the new name:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalUrl "https://outlook.frankysweb.local/owa"
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl "https://outlook.frankysweb.local/ecp"
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl "https://outlook.frankysweb.local/EWS/exchange.asmx"
Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl "https://outlook.frankysweb.local/OAB"
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl "https://outlook.frankysweb.local/Microsoft-Server-ActiveSync"
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname outlook.frankysweb.local -InternalClientsRequireSsl:$true
Autodiscover automatically distributes the new settings to the clients after some time (see below, event 3025), so that Outlook now accesses Exchange via "outlook.frankysweb.local". This DNS name must of course also be present on the certificate to avoid warnings.
To be able to use Keberos as an authentication method, a computer account is required. I therefore create a new computer account in the Active Directory with the name "CASASA" in the "Microsoft Exchange Security Groups" OU. It does not matter what name or OU the account is created with, as long as it is not deleted or changed.
In order to use the new computer account, the account needs a password. The account does not currently have a password, as no computer with the name CASASA has joined the Active Directory. To assign a password for the computer account, the "DistinguishedName" of the account is required:
The following lines of VBS code can be used to assign the password, simply replace the DN and select an appropriate password. The text can then be inserted into a .VBS file.
Set objComputer = GetObject _
("LDAP://CN=CASASA,OU=Microsoft Exchange Security Groups,DC=frankysweb,DC=local")
objComputer.SetPassword "MyPassword"
Now execute the VBS script:
cscript .\computerpassword.vbs
A Service Principal Name (SPN) is now registered for the computer account in the Active Directory with the following command:
setspn -a HTTP/outlook.frankysweb.local FrankysWeb\CASASA$
Now the Alternate Service Account (ASA or our new computer account) can be bound to the Client Access Server using the following commands:
$creds = Get-Credential -Credential "FrankysWeb\CASASA$"
Set-ClientAccessServer EX1 -AlternateServiceAccountCredential $creds
The following command can be used to check whether the account has been successfully bound to the Client Access Server:
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialPassword | fl
Now it is time to change the authentication method. The authentication is set to "Negotiate", since we now have an SPN and an Alternate Service Account (ASA), Exchange is able to negotiate Kerberos. If the Kerberos negotiation fails, NTLM is selected as a fallback. To change the authentication, the following command is entered:
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,NTLM
Autodiscover will automatically change the Outlook profiles, but it will take some time for Autodiscover to notice the changes. Event 3025 should appear in the event log after 15 minutes at the latest. The configuration has now been updated:
However, it can take up to 2 hours until the Outlook profiles are changed. Patience is a virtue here, or you can click on "Repair" in the Outlook profile... (but please only after event 3025)
(In my test environment, I had to switch Outlook back to online mode after clicking on "Repair")
Once the account is up to date, you can check whether authentication is actually carried out with Kerberos by deleting all Keberos tickets so that you have to re-authenticate:
klist purge
Outlook now shows "Nego" as authentication, which is fine so far:
With the command "klist" we can display the Keberos tickets
klist
If everything has worked, a ticket is displayed that points to the previously configured SPN:
If the ticket is not yet displayed... Patience is a virtue 
