none
Exchange 2019 - Issue with EAC (ECP) - error - your request couldn't be completed. Please try again in a few minutes RRS feed

  • Question

  • Hi,

    I am working on a freshly installed Microsoft Exchange 2019 server. I already have a Microsoft Exchange 2013 up to the latest CU in my environment. I have installed all the prerequisites as required by Microsoft. I have proceeded with the Microsoft Exchange 2019 installation and have included to "install additional features if necessary" in case the script Microsoft provided was missing something.

    When I head to the DATABASES in ECP section and "single-click" on the default Database that was created during the install, I get : "error - your request couldn't be completed. Please try again in a few minutes".

    If I select my 2013 production database, it shows the summary details in the right pane without any issues. If I create a new database on the 2019 server, I get the exact same error when I single click the database. I can still modify my 2019 databases without any issue and all properties show up correctly.

    I have tried connecting via Internet Explorer, Microsoft Edge and Google Chrome. I have tried 2 different users which are Domain Admins and Exchange Organization Administrators.

    Server was rebooted a few times to no avail.

    Has anyone encountered this issue on their Exchange 2019 server?

    Thanks,


    Thursday, January 3, 2019 6:51 PM

Answers

  • There is a bug in Exchange 2019. Whenever try to click on Exchange 2019 Database through Exchange 2019 ECP it generates error (In Co-existence with Exchange 2013). When I try to debug it, it shows Front end server (X-FEServer) as Exchange 2019 but Backend Server (X-CalculatedBETarget) as Exchange 2013 which is wrong (Doesn't matter where mailbox reside).

    So Exchange 20119 ECP taking Exchange 2013 as targeted Backend server.  It sends below error when we click on Exchange 2019 Database in Exchange 2019 ECP:-

    Message=failed to find locstring id=11. This string is used as LocDescription of 11 value in enum type Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType

    As Content indexing status is changed in Exchange 2019 so method used in Exchange 2013 doesn't recognise it (Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType). 

    Solution:-

    1. Use "https://<Exchange 2019 Server>/ecp/?ExchClientVer=15.2" to access Exchange 2019 ECP.

    2. I noticed that after pointing Exchange 2013 Autodiscover url to Exchange 2019, issue also gets resolve.

    3. Move all mailboxes to Exchange 2019 and decommission Exchange 2013. When we shutdown Exchange 2013 services this behaviour change and no issue occur.


    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.

    Saturday, March 16, 2019 7:08 PM

All replies

  • Hi,

    What about when you run get-mailboxdatabase on Exchange 2019.

    Did you tried to create new database using Powershell.


    Thanks, Ashish MCITP, MCT, MCSE

    Thursday, January 3, 2019 7:35 PM
  • What about when you run get-mailboxdatabase on Exchange 2019.

    -> Every setting in the database is similar to the one on the Exchange 2013 server. 

    Did you tried to create new database using Powershell.

    -> Yes, we have tried. However, we still face the same issue on the newly created database (yes, after restarting the Information Store)

    Thursday, January 3, 2019 7:40 PM
  • Can you please try to reset your IE setting and then try?

    Thanks, Ashish MCITP, MCT, MCSE

    Thursday, January 3, 2019 7:43 PM
  • I have already tried, and I have also tried 3 different browsers (IE, Edge and Chrome).
    Thursday, January 3, 2019 7:44 PM
  • Did you tried to see ecp logs for any error.
    default location for logs is C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy
     and
    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP


    Thanks, Ashish MCITP, MCT, MCSE

    Thursday, January 3, 2019 9:49 PM
  • Hello!

    Please, check this:

    https://social.technet.microsoft.com/Forums/lync/en-US/89a4c556-94a7-4ef2-9b52-1edfc110c113/eac-exchange-2013-gives-error-your-request-couldnt-be-completed-please-try-again-in-a-few-minutes?forum=exchangesvrgeneral

    https://social.technet.microsoft.com/Forums/en-US/89a4c556-94a7-4ef2-9b52-1edfc110c113/eac-exchange-2013-gives-error-your-request-couldnt-be-completed-please-try-again-in-a-few-minutes


    “Vote As Helpful” and/or “Mark As Answered” - Thiago Mendes da Silva - MCSE Communication - http://www.ucsteps.com/

    Thursday, January 3, 2019 11:39 PM
  • Hi,

    What is the version of your Exchange 2019? You can use command below to check it from EMS:

    Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

    Does the same error occurs when you click Exchange 2019’s database from Exchange 2013’s ECP, 

    If you create a new administrator account, I would suggest you add it to all those groups:

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, January 4, 2019 8:07 AM
    Moderator
  • Hi,

    I had reviewed these articles a bit earlier.

    I have checked that FORMSAUTHENTICATION is set to TRUE for the Virtual Directories.

    I have also eliminated the Browsers from the equation.

    Cara Chen mentionned that : "I recommend you set 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true to check the result."

    Do you know what she is referring to and how I can check that out? I followed the links she posted but didn't quite understand how to get to it.

    Thanks!!!!

    Friday, January 4, 2019 4:33 PM
  • Hi Kyle,

    Here is the output for the command :

    Name : EX2019
    Edition : Standard
    AdminDisplayVersion : 15.2 (Build 221.12)

    We have tried many different users and all of them get the same error message.

    The problem also appears if I single-click on the database from the 2013 ECP Portal.

    Friday, January 4, 2019 5:57 PM
  • Have you checked the event viewer? What error are there?or warnings?

    “Vote As Helpful” and/or “Mark As Answered” - Thiago Mendes da Silva - MCSE Communication - http://www.ucsteps.com/

    Friday, January 4, 2019 6:33 PM
  • Hi Thiago,

    I made the pop up appear a dozen times and then went in the event viewer. I could not find anything in the Application / System / All other Microsoft related logs which seemed to be related and timed with the error message. 

    Thanks,

    Friday, January 4, 2019 7:05 PM
  • All the activity in ECP should come in ECP logs.

    C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy
     and
    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP

    Also many people facing issue with Exchange 2019 and other exchange versions due to TLS.

    Please take note that Exchange 2019 only supports TLS 1.2 and you need other servers to enable TLS 1.2 so there will be no communication issue happen.


    Thanks, Ashish MCITP, MCT, MCSE

    Friday, January 4, 2019 7:19 PM
  • Thank you Ashish, my TLS 1.2 settings are enabled ( they were enabled by default already).

    I also have reviewed the HTTPProxy and ECP contents and could not find anything talking about errors, or access denied. 

    Would it help if I posted the contents of those log files up here (and changes my domain to "contoso.com" for security purposes).

    Friday, January 4, 2019 7:40 PM
  • You can share  here or can share through one drive as well.

    Thanks, Ashish MCITP, MCT, MCSE

    Friday, January 4, 2019 7:42 PM
  • Here are the requested log files : 

    https://1drv.ms/f/s!AkHRXICSoucWhgQ60xQTltVHV54U

    Friday, January 4, 2019 7:58 PM
  • Can you please check for event id 1310 under application in event viewer?

    or any other error or warning events related to asp.net


    Thanks, Ashish MCITP, MCT, MCSE

    Friday, January 4, 2019 9:26 PM
  • Hi andrewgarcalopes,

    Did you try to create a new database on a new disk, then remove this old one and try again?This issue may be caused by a broken disk. I would suggest you double check in Event Viewer, whether there exist any error about this issue.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, January 9, 2019 10:04 AM
    Moderator
  • Using incognito mode in the browser resolved this issue !
    Saturday, January 12, 2019 5:25 PM
  • Hi andrewgarcalopes,

    Did you try to create a new database on a new disk, then remove this old one and try again?This issue may be caused by a broken disk. I would suggest you double check in Event Viewer, whether there exist any error about this issue.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    This happens on two differents installs, and happens in any new database we create. It was tried with two different hardware. The new one is high performance SSDs.
    Monday, January 21, 2019 4:16 PM
  • Can you please check for event id 1310 under application in event viewer?

    or any other error or warning events related to asp.net


    Thanks, Ashish MCITP, MCT, MCSE


    As crazy as it sounds, this Event ID does not appear in our Event Viewer.
    Monday, January 21, 2019 4:16 PM
  • Hi andrewgarcalopes,

    Could provide a screenshot about the issue you encounter to us?

    If you run "Get-MailboxDatabase" command in EMS, does there has any error occur?

    I would suggest you try to recreate ECP virtual directory then try to check again.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, January 23, 2019 7:25 AM
    Moderator
  • We have the same issue.

    Everything seems to be working as it should in the background and within Powershell. Just can't click on the Exchange 2019 databases without getting the error in ECP.

    Clicking on the Exchange 2013 databases work as expected.

    Edit: As Raz_1234 mentions above, sometimes using Incognito mode in Chrome works without error. Although sometimes it doesn't.





    • Edited by BazRat24 Monday, February 11, 2019 9:02 AM
    Friday, February 1, 2019 5:05 PM
  • Any updates on this? I've the same issue with Exchange 2019 in a 2013 production environment..
    Wednesday, March 6, 2019 11:59 AM
  • Hi,

    I have the same issue with newly installed Exchange 2019 RTM in Exchange 2013 CU21 test environment. When I click on the default created Mailbox Database in EAC, a pop-up window said: "Your request couldn't be completed. Please try again in a few minutes."

    I've seen both log - C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy and C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP... nothing helped.

    I check the database status with Get-MailboxDatabase & Get-MailboxDatabaseCopyStatus. I got the results below:


    Then I opened EAC and click the database again with firefox and dev-tools . I saw a 500 response with exception message: "failed to find locstring id=11. This string is used as LocDescription of 11 value in enum type Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType"


    With 2 pics above, I think the problem is that the ContentIndexState=11 does not have correspond description. I couldn't find anything about this state, so I have no idea how to solve it. Does anyone know anything about this? Here is mine Exchange version:


    Btw, this might not be the root cause of all cases.

    Thanks,

    Update: After update to Exchange 2019 CU1, the issue is still there.

    • Edited by hyili Wednesday, March 13, 2019 12:58 AM update information
    Monday, March 11, 2019 12:42 AM
  • I'm getting the same issue as well with Exchange 2019 CU1 and have read every forum available but unable to find a solution.
    Tuesday, March 12, 2019 11:42 PM
  • I'm getting the same issue as well with Exchange 2019 CU1 and have read every forum available but unable to find a solution.

    I've just gotten off the call with Microsoft support and finally came to a resolution after 3 hours.  Here is the solution for the environment I was working in:

    http://terenceluk.blogspot.com/2019/03/attempting-to-click-on-exchange-2019.html

    Thursday, March 14, 2019 12:36 AM
  • I'm getting the same issue as well with Exchange 2019 CU1 and have read every forum available but unable to find a solution.

    I've just gotten off the call with Microsoft support and finally came to a resolution after 3 hours.  Here is the solution for the environment I was working in:

    http://terenceluk.blogspot.com/2019/03/attempting-to-click-on-exchange-2019.html

    Thanks for the info!

    Moving the admin mailbox to a database on the Exchange 2019 server was one of the first things I tried.  Unfortunately it didn't work for me.

    Thursday, March 14, 2019 6:01 AM
  • I just found the solution to solve my problem. That is because the wrong ExchClientVer is used by EAC. EAC used to have ExchClientVer=15 in Exchange 2013, but it is currently using ExchClientVer=15.2 in Exchange 2019.

    A quick solution is that we can just appending "ExchClientVer=15.2" directly to the EAC URL parameter. For example, the original url might be "https://<exchange_server_domain>/ecp/". After modification, new URL would be "https://<exchange_server_domain>/ecp/?ExchClientVer=15.2". In my case, everything looks FINE.

    According to some articles about ExchClientVer, seems like it is decided by the location server of the admin mailbox. If the admin mailbox is located on the server with Exchange 2013, EAC would use ExchClientVer=15. So everything we need is to move our admin mailbox to the server with Exchange 2019. Just like terenceluk0925 have tried.

    But unfortunately, moving the admin mailbox to the newer server did not work for me... I currently use the first tricky one.

    Reference here

    http://jetzemellema.blogspot.com/2015/07/how-to-access-exchange-2016-ecpeac-with.html

    https://www.msdigest.net/2016/08/how-to-access-the-exchange-20132016-admin-center-ecp-with-mailbox-still-on-older-exchange/



    Thursday, March 14, 2019 7:11 AM
  • There is a bug in Exchange 2019. Whenever try to click on Exchange 2019 Database through Exchange 2019 ECP it generates error (In Co-existence with Exchange 2013). When I try to debug it, it shows Front end server (X-FEServer) as Exchange 2019 but Backend Server (X-CalculatedBETarget) as Exchange 2013 which is wrong (Doesn't matter where mailbox reside).

    So Exchange 20119 ECP taking Exchange 2013 as targeted Backend server.  It sends below error when we click on Exchange 2019 Database in Exchange 2019 ECP:-

    Message=failed to find locstring id=11. This string is used as LocDescription of 11 value in enum type Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType

    As Content indexing status is changed in Exchange 2019 so method used in Exchange 2013 doesn't recognise it (Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType). 

    Solution:-

    1. Use "https://<Exchange 2019 Server>/ecp/?ExchClientVer=15.2" to access Exchange 2019 ECP.

    2. I noticed that after pointing Exchange 2013 Autodiscover url to Exchange 2019, issue also gets resolve.

    3. Move all mailboxes to Exchange 2019 and decommission Exchange 2013. When we shutdown Exchange 2013 services this behaviour change and no issue occur.


    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.

    Saturday, March 16, 2019 7:08 PM
  • There is a bug in Exchange 2019. Whenever try to click on Exchange 2019 Database through Exchange 2019 ECP it generates error (In Co-existence with Exchange 2013). When I try to debug it, it shows Front end server (X-FEServer) as Exchange 2019 but Backend Server (X-CalculatedBETarget) as Exchange 2013 which is wrong (Doesn't matter where mailbox reside).

    So Exchange 20119 ECP taking Exchange 2013 as targeted Backend server.  It sends below error when we click on Exchange 2019 Database in Exchange 2019 ECP:-

    Message=failed to find locstring id=11. This string is used as LocDescription of 11 value in enum type Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType

    As Content indexing status is changed in Exchange 2019 so method used in Exchange 2013 doesn't recognise it (Microsoft.Exchange.Rpc.Cluster.ContentIndexStatusType). 

    Solution:-

    1. Use "https://<Exchange 2019 Server>/ecp/?ExchClientVer=15.2" to access Exchange 2019 ECP.

    2. I noticed that after pointing Exchange 2013 Autodiscover url to Exchange 2019, issue also gets resolve.

    3. Move all mailboxes to Exchange 2019 and decommission Exchange 2013. When we shutdown Exchange 2013 services this behaviour change and no issue occur.


    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.

    Thank you Ashish, I appreciate you taking the time to test this 2013-2019 coexistence and confirming the issue for me as it was driving me nuts.
    Thursday, March 21, 2019 5:02 PM
  • This occured to me as well. Incognito works in the 1/3 DAG members that has this problem.  The other 2 members do not need to go incognito.


    Wednesday, November 13, 2019 2:46 AM