During the migration from Exchange 2016 to Exchange 2019, I encountered the problem that Outlook constantly asks for username and password. A connection via Outlook to Exchange could no longer be established as soon as the DNS entry (or the load balancer) was switched to the new Exchange 2019 servers. However, OWA and ActiveSync worked without any problems.
In most cases, the problem with the Outlook password request is due to different authentication settings for the Outlook protocols OutlookAnywhere (the old RPCoverHTTP) and/or MAPIoverHTTP. As a rule, it is sufficient if the authentication settings for both protocols are set the same. Apparently, this has already been done for both protocols, as can be seen in the two screenshots (OAuth is not relevant in pure on-prem environments):
MAPIoverHTTP
Outlook Anywhere
Even on the Exchange Shell, there were no direct differences in the authentication settings, as the IIS settings are also the same on all servers.
In my case, it was also due to the authentication, because the Exchange 2016 servers were switched to Kerberos authentication. In order to be able to use Kerberos, a computer object is created in AD with the corresponding SPNs and assigned to the Exchange servers as AlternateSeriveAccountConfiguration. This dedicated computer account is then used for Kerberos authentication for Exchange. In my case, I had forgotten to configure the corresponding computer account on the Exchange 2019 servers when configuring the new Exchange 2019 servers.
The following command can be used to check whether Exchange has been configured for Kerberos and which computer account is used for authentication:
Get-ClientAccessService SERVERNAME -IncludeAlternateServiceAccountCredentialStatus | fl *alter*
Exchange 2016 and Exchange 2019 servers can use the same computer account, so you only need to transfer the configuration from an Exchange 2016 server to the new Exchange 2019. There is a PowerShell script in the Exchange Scripts folder for transferring the configuration. The script is used as follows:
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer EXCHANGE2019SERVER -CopyFrom EXCHANGE2016SERVER
After the Kerberos configuration was transferred to the Exchange 2019 servers, the password query in Outlook also disappeared.
Hier noch eine Ergänzung von mir da ich gerade unsere Umgebung von 2013 auf 2019 migriere:
Bei 2013 gab es das Command ‚Get-ClientAccessService‘ noch nicht, daher funktioniert das Skript dann nicht. Die Lösung ist das Skript von einer aktuellen Exchange 2013 CD/ISO zu nehmen und auf den 2019 Server zu kopieren und dort dann auszuführen.
Viele Grüße
Martin
Hallo zusammen,
bei uns hatten wir Probleme mit dem Exhnage 2016 Wildcard Zertifikat (Front END)
Wir hatten auf dem KEMP ein Wildcard Zertifikat und auf dem Mail Server ein UCC Zertifikat, nach dem wir auf Exchange und Kemp ein Multi Wildcard Zertifikat (test.de & test.eu) eingespielt haben geht jetzt alles.
Wenn nicht das Gleiche Zertifikat ist macht Outlook Probleme mit User & PWD
Ich weis es passt nicht zum umzug, aber wollte es euch mit teilen.
Ist Extended Protection aktiviert?
„you must use the same SSL certificate on Exchange and your Load Balancers. If not this will cause Extended Protection to fail.“
Danke für deine Infos.
Ich nehme an die Kerberos Authentifizierung ist sicherer, meine Frage nun verwendet Exchange sonst die Standard NTLM Authentifizierung?!?
Ja Kerberos ist sicherer als ntlm.
Hallo Andreas,
welches Protokoll zur Authentifizierung verwendend wird, hängt von deiner Umgebung ab. In der Standardeinstellung wird allerdings NTLM und sogar teilweise noch BASIC verwendet.
Morgen gibt es einen Artikel zu Kerberos und Exchange 2019, vielleicht hilft dir das weiter.
Beste Grüße,
Frank