Exchange server 2016 and 2019 coexistence

George Gaprindashvili 61

Hi,

We have 2016 and 2019 servers both on premises.
if we create and account which resides on database on 2019 authorization issues happen

like you open OWA properly login and no error message just login does not happen.

if you misspel password red message appears.

So far we see only when account resides on 2019 database.

total 3 servers, 1 CU 20 2016, 2 CU 23 2016 and 3 CU 14 2019

1 and 2 have DAG

3 has no DAG as it is not allowed to DAG 2016 and 2019

George Gaprindashvili 61 Reputation points

2024-10-09T20:51:19.0666667+00:00

If I use owa with explicit address of server 2019 - server 3 then it goes fine.
please advise

we are in process of migration from 2016 to 2019

1 answer

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-10-10T02:18:01.9766667+00:00
Hi @George Gaprindashvili ,

Welcome to the Microsoft Q&A platform!

Based on your description, it looks like you are experiencing OWA authentication issues when the user account is in the database of an Exchange 2019 server. Here are a few steps you can take to troubleshoot and potentially resolve this issue:

Look for any relevant errors in Event Viewer on the Exchange 2019 server. This can provide more insight into the issue that is occurring during the logon process.

Since you are using a hybrid of Exchange 2016 and 2019 servers, make sure that Kerberos authentication is configured correctly. Misconfiguration can cause authentication issues.

Verify that the OWA virtual directory URL on the Exchange 2019 server is configured correctly. Mismatched URLs can cause redirection issues.

Compare the authentication settings for the OWA virtual directory on the Exchange 2019 server with the authentication settings on the Exchange 2016 server. They should be consistent on all servers.

Make sure that the SCP for the Exchange 2019 server is configured correctly. The client uses the SCP to locate the Autodiscover service.

Make sure the DNS records for your Exchange environment are configured correctly. Incorrect DNS settings can cause clients to connect to the wrong server.

If you use a load balancer, check the configuration to make sure traffic is being directed correctly to the Exchange 2019 server.

Make sure the SSL certificate on the Exchange 2019 server is valid and matches the name the client is using to connect.

Make sure your Exchange 2019 server is updated with the latest cumulative updates and security patches.

Sometimes browser-specific issues can cause problems with OWA. Test the sign-in process with different browsers to rule this out.

Because this issue does not occur when explicitly using the address of the Exchange 2019 server, this indicates that the issue may be related to how the request is routed or authenticated when it passes through the Exchange 2016 server. By following the steps above, you should be able to narrow down the cause of the issue and find a solution.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang
Please sign in to rate this answer.
George Gaprindashvili 61 Reputation points

2024-10-10T16:25:53.7966667+00:00

Can you elaborate on how to do 2? Everything else is checked and good.

Basically that Exchange 2019 server has a one way trust. If we use it to connect to mailboxes on other servers, that works fine, but it wont allow other servers to connect to its mailboxes.

George Gaprindashvili 61 Reputation points

2024-10-10T16:28:08.6066667+00:00

Can you elaborate on how to do 2?

That 2019 server has one way trust. It will connect to mailboxes on other servers(that are exchange 2016) but it wont allow other servers to connect to its mailboxes.

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-10-11T02:31:49.4733333+00:00

Hi @George Gaprindashvili ,

Thanks for your response!

Configuring Kerberos authentication in an Exchange environment with a one-way trust can be a little tricky. Here is a detailed guide on how to set it up:

On a domain controller in the same forest as the Exchange server, create a computer account to use as the ASA credential. You can do this using the Active Directory Users and Computers snap-in or through PowerShell:

New-ADComputer -Name "ASA_Account" -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Enabled $true -SamAccountName "ASA_Account" Set-ADComputer "ASA_Account" -Add @{"msDS-SupportedEncryptionTypes"="28"}

On each Exchange 2019 Mailbox server, run the following PowerShell script to configure the ASA credentials:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers "Exchange2019Server" -GenerateNewPasswordFor "ASA_Account" -Verbose

Kerberos uses SPNs to associate service instances with service logon accounts. You need to associate the appropriate SPN with the ASA account. This can be done using the setspn command:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers "Exchange2019Server" -GenerateNewPasswordFor "ASA_Account" -Verbose

4.After the ASA credentials are configured and the SPN is associated, you need to enable Kerberos authentication for Outlook clients. This can be done using the Exchange Management Shell:

Set-OutlookAnywhere -Identity "Exchange2019Server\Rpc (Default Web Site)" -InternalClientAuthenticationMethod Negotiate

5.After Kerberos authentication is configured, verify that it is working properly. You can check the Kerberos tickets using the klist command on the client computer: klist

6.Ensure that DNS is configured correctly for the Exchange server. Both forward and reverse lookup zones should be set up correctly.

7.In the case of a one-way trust, ensure that the trust is configured correctly. The Exchange 2019 forest should trust the other forest where the user is authenticating.

Test the configuration by logging into OWA and Outlook with a user account that resides on the Exchange 2019 server. Ensure that authentication is successful and there are no issues accessing the mailbox.

By following these steps, you should be able to configure Kerberos authentication in your Exchange environment. If you encounter any issues, be sure to check the event log for any relevant errors and verify that the SPN is set correctly. Also, ensure that the time synchronization between the servers is correct, as Kerberos is time sensitive.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

George Gaprindashvili 61 Reputation points

2024-10-13T22:24:46.6266667+00:00

Dear Jake

apparently some security setting is tighter on 2019 server. One device that used to send email via mailserver with SSL on and was working great with 2016 servers does not work with 2019 (This is an old HP printer)

conseqeuently I think problem is limited to 2019 server
Active Directory environment is the same.
so 2019 does not trust some SSL calls even from fellow exchange servers.

I did workaround (like sending without ssl) but would like to figure out what happens very much.

we probably can remove older servers and go all 3 to be 2019 and that MUST solve issue but there is no way back so would like to solve this issue before we go.

What you suggest seems quite complex - reconfiguring AD settings.

is there a way to limit changes with server 2019?

because of issue we experiense we dont use that server as mailbox host yet so if something goes wrong we can easily deinstall and reinstall it.

While if we screw up Active directory or 2016 servers that will be very bad for us.

what protocol mailbox database access uses?

so

person goes and authenticates on 2016 server

fellow 2019 server does not trust and gives no access to mailbox database.

besides that - also that little error of printer ssl call

have you heard similar issue?

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-10-14T02:40:20.7533333+00:00

Hi @George Gaprindashvili ,

Thanks for your response!

Based on your description, it looks like the issue you're experiencing is related to stricter security settings on your Exchange 2019 server, specifically SSL/TLS configuration. Exchange 2019 enforces stricter security measures, which can cause the authentication issues you're seeing with OWA and older HP printers.

Here are some steps you can take to resolve these issues:

Make sure your printer's firmware is up to date. Older devices may not support the latest TLS versions, and firmware updates may add support for newer protocols.

Exchange 2019 supports TLS 1.2 by default, and it's recommended to disable older, less secure TLS versions. However, if your printer doesn't support TLS 1.2, you may need to temporarily enable TLS 1.0 or 1.1 to allow the printer to connect. This can be done by modifying the registry on the Exchange 2019 server:

Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.

Create the necessary keys for the TLS versions you need to enable.

Set the Enabled DWORD value under the Server key for the protocols you want to enable to 1.

Make sure the cipher suites used by the Exchange 2019 server are compatible with the printer. You can configure the cipher suite order through Group Policy:

Open the Group Policy Management Editor and navigate to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.

Enable the policy setting SSL Cipher Suite Order and configure the cipher suite list.

Exchange 2019 enables Extended Protection for Authentication by default. This may cause issues with older devices that do not support channel binding tokens. You can disable Extended Protection for the OWA and ECP virtual directories to see if that resolves the issue:

Use the Exchange Management Shell to run the following commands:

Set-OwaVirtualDirectory -Identity "Exchange2019\owa (Default Web Site)" -ExtendedProtectionTokenChecking None Set-EcpVirtualDirectory -Identity "Exchange2019\ecp (Default Web Site)" -ExtendedProtectionTokenChecking None

After making these changes, test the connection from the printer to the Exchange 2019 server. If it works, you can consider these settings as a temporary solution until you have fully migrated to Exchange 2019.

Notes:

Keep in mind that enabling older versions of TLS or modifying the cipher suite order can weaken the security of your server. It is important to weigh the risks and benefits and have a plan to re-protect your server after the migration is complete.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

George Gaprindashvili 61 Reputation points

2024-10-14T03:37:08.4033333+00:00

I am afraid you misread me. We don't care issue with printer. we did already a workaround- just dont use ssl and everything works.

tell us please how we fix 2016 and 2019 coexistence.

what we do so that 2019 trusts authentication on 2016 and makes mailbox accessible?

that is what we need.

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-10-16T09:53:08.71+00:00

Hi @George Gaprindashvili ,

Thanks for the clarification. To resolve the authentication issue in an Exchange 2016 and Exchange 2019 coexistence environment and ensure that Exchange 2019 trusts authentication from Exchange 2016, you can try the following steps:

1.Exchange 2016 and Exchange 2019 use OAuth for cross-site authentication. Make sure that OAuth is configured correctly between the servers:

Run the following command on the Exchange 2016 server:

Set-AuthServer -Identity "EvoSts" -IsDefaultAuthorizationEndpoint $true Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Run the following command on the Exchange 2019 server:

Set-AuthServer -Identity "EvoSts" -IsDefaultAuthorizationEndpoint $true Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Make sure that the virtual directory URLs are configured correctly on the Exchange 2016 and Exchange 2019 servers. They should point to the appropriate servers for each service.

Verify that SCP is configured correctly. The SCP should point to the correct Autodiscover service for your environment.

Ensure that the certificates used by Exchange 2016 and Exchange 2019 are trusted and contain the necessary names (for example, mail.contoso.com, autodiscover.contoso.com).

Ensure that the Autodiscover service is working properly. Clients use Autodiscover to find the appropriate mailbox server.

If you have a firewall or load balancer, ensure that it is configured to allow traffic between the Exchange 2016 and Exchange 2019 servers.

After configuring the above settings, test mailbox access by logging on to OWA and Outlook with a user account that resides on the Exchange 2019 server.

By following these steps, you should be able to resolve authentication issues between Exchange 2016 and Exchange 2019 and ensure that mailboxes on the Exchange 2019 server can be accessed. If the problem persists, you may need to check the event log for related errors and verify the authentication settings configuration on both servers. Also, consider running the Exchange Best Practices Analyzer to identify any potential configuration issues.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-10-21T05:38:26.2766667+00:00

Hi @George Gaprindashvili ,

Please kindly consider this comment as a warm follow up, I want to know if your problem has been solved. If you still have any other questions, please feel free to comment here and I'm glad to provide further support.If the above info is helpful to this question, you can click "Accept Answer". Have a nice day!

Best,

Jake Zhang

Jake Zhang-MSFT 6,465 Reputation points Microsoft Vendor

2024-11-06T01:51:56.9+00:00

Hi @George Gaprindashvili ,

Any updates so far? If you have solved your problem, could you share with us? Maybe it will help more people with similar problems. Don't forget to mark it as answer, this will be easy for other community members to find the useful one. Thanks for your understanding.

Best,

Jake Zhang
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Exchange server 2016 and 2019 coexistence

1 answer

Your answer