Exchange Server migration problem

Question

Exchange Server migration problem

Tang, Ken 65

We are approaching for Exchange server migration from EX2016 to EX2019. Both environment applied for the latest CU. One question is when user are migrate from EX2016, once migration complete, their desktop will continuously prompt the login windows.

EX2016 user

Stay at Ex2016: no login windows prompt out

Migrate to Ex2019: continuously prompt out login window

New create user on Ex2019: no login windows prompt out.

I have also follow all the virtual directory settings from Ex2016, and have correctly place the cert .

Any suggestions?

2 answers

Your answer

Answer 1

Dear @Tang, Ken

Thank you for posting your question in the Microsoft Q&A forum.

According to your issue, I understand you're experiencing a frustrating situation with continuous login prompts for users after their mailboxes are moved from Exchange 2016 to Exchange 2019. Here are a few steps you can try to resolve this:

Check Autodiscover Settings: Ensure that the Autodiscover service is correctly configured and that the Service Connection Point (SCP) is pointing to the correct URL. You can verify this by running the Test Email AutoConfiguration tool in Outlook (hold down the CTRL key and right-click the Outlook icon).
Check Authentication Settings: Ensure that the authentication settings on your Exchange server are correctly configured. Sometimes, mismatched authentication settings can cause repeated credential prompts.
DNS Configuration: Verify that your DNS settings are correctly configured and that the Autodiscover DNS records are pointing to the correct IP address of your Exchange server.

To troubleshoot this more effectively, could you please provide details on the authentication methods enabled for the AutoDiscover Virtual Directory on both your Exchange 2016 and Exchange 2019 servers?

If you need further assistance, please let us know.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Tang, Ken 65

Hi Hin,

Thanks for you reply.

One update: I have test again.. The account created on Ex2019 are still face the same issue.

And we use the same URL for the both ex2016 and ex2019 env.

Here's the authentication for both Ex2016 and Ex2019 for your further investigation.

Ex2016

Name : Autodiscover (Default Web Site)

InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

Ex2019

Name : Autodiscover (Default Web Site)

InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

Hin-V 1,215 Reputation points Microsoft External Staff Moderator

2025-06-25T10:15:55.5166667+00:00

Hi @Tang, Ken,

Sorry for my delayed response.

As your provided information, I have found that the WindowsIntegrated could relevant to Kerberos Authentication (You can refer via: Integrated Windows Authentication | Microsoft Learn). In my perspective this authentication could lead to the login error and SPN might be duplicated in both Exchange 2016 and 2019.

You can refer via:

Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error - Windows Server | Microsoft Learn

Could you please check with your administration the SPN in the Exchange 2016

You can refer via: Configure Kerberos authentication for load-balanced Client Access services | Microsoft Learn

Warm thanks.
Tang, Ken 65 Reputation points

2025-06-26T02:04:08.53+00:00

Hi Hin,

That means I have to remove the WindowsIntegrated options on the Autodiscover authentication ?

Regards,

Ken
Hin-V 1,215 Reputation points Microsoft External Staff Moderator

2025-06-26T12:02:36.4033333+00:00

Hi @Tang, Ken

Thank you for your responding.

According to issue, I believe this could be cautioned by duplicated SPN in both sever Exchange sever 2016 and 2019. You could try to remove the autodiscover.XXXX.net and mail.XXXX.net from ASA computer account

I believe the issue I found may be closely related to your concern.

You can refer via: Exchange 2019 and Outlook 2016, 2019 and 2021 Autodiscover - Microsoft Q&A

Any update would be appreciated.

Warm thanks.
Tang, Ken 65 Reputation points

2025-06-27T08:09:38.8166667+00:00

Hi Hin,

I have no idea where to find the ASA computer account.

Can you explain ?
Hin-V 1,215 Reputation points Microsoft External Staff Moderator

2025-06-27T13:06:54.1833333+00:00

Hi @Tang, Ken

In my perspective, when you migrate the exchange sever 2016 to 2019, some SPNs might have been duplicated. As the article that I found:

"An SPN is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each service instance must have its own SPN" which means each Exchange sever must have their own SPN

Relevant article: How to use SPNs when you configure Web applications that are hosted on Internet Information Services | Microsoft Community Hub

Could you please ask your administrator to check the SPN configuration first in both Exchange sever 2016 and 2019, and then get back to me so we can proceed with troubleshooting.

Using this command:

setspn –L <hostname>

You can refer via this: How to configure SPN for Windows Server | Microsoft Learn

Any update would be appreciated.

Warm thanks.
Tang, Ken 65 Reputation points

2025-06-30T01:21:12.3533333+00:00

Hi hin,

When I run the command setspn -L "domain\hostname" . it return sort of list but did not list out the item related on autodiscover or mailxxxx/

Did i run the incorrect command ?
Tang, Ken 65 Reputation points

2025-06-30T06:10:59.06+00:00

Seems we do not set and ASA parameter, when i run Get-ClientAccessServer "servername" -IncludeAlternateServiceAccountCredentialStatus. No matter on Ex2016 or Ex2019, it returns "not set"
TiNo-T 2,785 Reputation points Microsoft External Staff Moderator

2025-07-01T14:46:59.4033333+00:00

Hi @Tang, Ken

Thank you for your responding.

You can use the command setspn -L "domain\hostname" to view the SPN (Service Principal Name) configuration on the Exchange server. This helps you check whether there are any duplicate SPNs. If duplicates are found, you could consider reconfiguring them to prevent authentication issues, which might cause continuous login prompts for migrated users. However, as the result "not set " from both exchanges sever, I think this could be caused by another misconfiguration not from the kerberos authentication (because it's not in use or required in your current sever setup). As a forum moderator, we don’t have access to the detailed system needed to troubleshoot this effectively due to privacy and security constraints. I would recommend you reach the tech community forums for a deeper technical dive or to connect with individuals who may have experience and expertise in this specific customization. There are many experienced developers and Microsoft specialists active there who can help troubleshoot and guide you through the process.

Apologies for redirecting you to the related development team support, as the moderators in this community have limited resources to check the backend information, and to get the fast and better assistance we requested for it.

We truly appreciate your patience and the time you've dedicated to addressing this issue. We hope you will solve this issue soon.

Share via

Exchange Server migration problem

2 answers

Your answer