none
Exchange 2019 - OWA Search Directory RRS feed

  • Question

  • When you run the Search Directory in OWA to Exchange 2019 it displays: "Can not connect. Please try again later."

    Using Chrome DevTools it displays the following message:
    Request URL: /owa/service.svc?action=FindPeople&ID=-47&AC=1
    Response: {"Header": {"ServerVersionInfo": {"MajorVersion": 15, "MinorVersion": 2, "MajorBuildNumber": 330, "MinorBuildNumber": 5, "Version": "V2017_07_11"}} "ResponseCode": "ErrorInternalServerError", "ResponseClass": "Error", "FirstLoadedRowIndex": 0, "MessageText": "Internal error on the server. AQS parser has been removed from Windows 2016 Server Core. "FirstMatchingRowIndex": 0, "ResultSet": null, "TotalNumberOfFavoritesInView": 0, "TotalNumberOfPeopleInView": 0}}

    Exchange was installed on a Windows Server 2019 Core server, as recommended by Microsoft, below the Windows and Exchange versions:

    OS Name: Microsoft Windows Server 2019 Standard
    OS Version: 10.0.17763 N / A Build 17763

    Edition: Enterprise
    AdminDisplayVersion: Version 15.2 (Build 330.5)
    Tuesday, March 12, 2019 10:26 PM

Answers

  • Hi Rodrigo, 

    As far as I concerned this issue regards the Windows Server 2019 Server Core. Looks like that the AQS Parser is not working on Windows Server 2019 Server Core. 

    If you take a look at this article, they said: "AQS Parser may fail if the default language and locale are changed to something other than US English." 

    But I've been facing this issue since the Exchange 2019 preview, tested with RTM and CU1, default language and locale in US English but the issue persist. In my lab the Windows Server 2019 Server Core is up-to-date.

    So I suggest you to open a case with Microsoft. Not sure if this issue is already on they road map to be fixed. 


    MCSE: Messaging | MCSA: Windows Server 2012 | MS: Virtualization | VCP-DCV 6 | ITIL v3 | Blog: https://www.signorellidenis.com | Portal MCP: www.mycertprofile.com/Profile/996021735

    Thursday, March 14, 2019 11:02 AM

All replies

  • Hi,

    How many mailboxes have this issue?

    I would suggest you open EMS(LaunchEMS) and use command below to check index for this mailbox and database:

    Test-ExchangeSearch administrator@domain.com
    Test-ExchangeSearch

    If the result could be found successfully, it mean there doesn't exist issue for this mailbox or database.

    This phenomenon may be cause by firewall or other intermediate equipment, I would suggest you try to disable those equipment temporarily, then check whether this phenomenon gone.

    I also would suggest you use command below to check whether Exchange server needed services are running:

    Test-ServiceHealth

    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, March 13, 2019 7:40 AM
    Moderator
  • Hi, Kyle.

    Thank you for your help.
    The problem occurs with all users who are in Exchange 2019. The Windows firewall is disabled.
    I have done all the above commands and all finished successfully, but the problem persists.

    It may not have been clear in the description of the problem. Link the image of the problem.

    www.dropbox.com/s/w8x6bbmneg6nqkv/Problem_EXCH2K19.png?dl=0

    Note. I can not load image

    Wednesday, March 13, 2019 4:29 PM
  • Hi Rodrigo, 

    As far as I concerned this issue regards the Windows Server 2019 Server Core. Looks like that the AQS Parser is not working on Windows Server 2019 Server Core. 

    If you take a look at this article, they said: "AQS Parser may fail if the default language and locale are changed to something other than US English." 

    But I've been facing this issue since the Exchange 2019 preview, tested with RTM and CU1, default language and locale in US English but the issue persist. In my lab the Windows Server 2019 Server Core is up-to-date.

    So I suggest you to open a case with Microsoft. Not sure if this issue is already on they road map to be fixed. 


    MCSE: Messaging | MCSA: Windows Server 2012 | MS: Virtualization | VCP-DCV 6 | ITIL v3 | Blog: https://www.signorellidenis.com | Portal MCP: www.mycertprofile.com/Profile/996021735

    Thursday, March 14, 2019 11:02 AM
  • I'm experiencing the exact same issue on a two node Exchange 2019 setup on Windows Server Core 2019. If I install a third node with Windows Server 2019 Desktop Experience and use this for client access, the problem persists. So I'm not sure that it is specific for Server Core.

    I can't reproduce the issue in an Exchange 2019 lab environment, so I have ended up opening a case with Microsoft.

    Wednesday, October 2, 2019 1:18 PM
  • I'm experiencing the exact same issue on a two node Exchange 2019 setup on Windows Server Core 2019. If I install a third node with Windows Server 2019 Desktop Experience and use this for client access, the problem persists. So I'm not sure that it is specific for Server Core.

    I can't reproduce the issue in an Exchange 2019 lab environment, so I have ended up opening a case with Microsoft.

    Did you solve this with their help ? Having the same error with build 17763. Tried to ser System Locale and Culture but to no avail....
    Sunday, October 6, 2019 5:03 PM
  • If anyone else run's into this issue i installed a new server and copied & replaced the ClientAccess & FrondEnd Folder on the old one and it started working.

    BR,

    Fetak.

    Monday, October 7, 2019 10:13 PM
  • Hi All,

    I have the same behavior with EX2019CU3 on W2019 Core.

    All my 20'000 users are impacted.

    Did you find a solution ?


    Monday, November 4, 2019 2:00 PM
  • Exchange Server 2019 CU3 is with problem on the search after aaply CU3: "Time out for test thread".

    This troubleshooting is not working.: http://clintboessen.blogspot.com/2014/12/

    An operation attempted against a FAST endpoint exprienced an exception. This operation may be retried. Error details: Microsoft.Exchange.Search.Fast.PerformingFastOperationException: An Exception was received during a FAST operation. ---> System.ServiceModel.FaultException: error CS1548: Cryptographic failure while signing assembly 'c:\Windows\Temp\q2bwseec.fst\Microsoft.Exchange.BigFunnelFlow.28.dll' -- 'Error signing assembly -- Unknown error (8013141c)'


    Server stack trace: 
       at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.Ceres.ContentEngine.Admin.FlowService.IFlowServiceManagementAgent.PutFlow(String name, String serializedFlow)
       at Microsoft.Exchange.Search.Fast.FastManagementClient.AgentHandle`1.<>c__DisplayClass6_0.<PerformOperation>b__0(TManagementAgent agent)
       at Microsoft.Exchange.Search.Fast.FastManagementClient.PerformFastOperation[TManagementAgent,TResult](AgentHandle`1 agentHandle, Func`2 function, String eventLogKey)
       --- End of inner exception stack trace ---

    Tuesday, November 12, 2019 7:17 PM