Gravatar for

Question by Ben, Nov 10, 2015 8:06 AM

Syntax Error 0x80040203 - First Time Setup

After Upgrade

Windows 8.1

CES 7.0 7914

Search API 8.0.772

Coveo for Sitecore 72 3.0 1123

I am receiving the following error:

    A syntax error occurred trying to evaluate a query string (Exception from HRESULT: 0x80040203)

This occurs when trying to view indexes through the Sitecore interface, when loading a page with a Coveo control, or when trying to navigate to the /coveo/rest endpoint.

I found this question, but it was of no help.

I am able to pull up the Admin Tool, but it is expecting me to create an index (which of course can't be done here with Coveo for Sitecore). I receive the proper XML from http://localhost/AdminService?wsdl I am running the services with an account which is a local administrator. All my certificate paths are verified. The CesConfigurationPath is correct. There are no system logs to check .

Any ideas on where to go with this?


I disabled coveo.searchprovider.config and the, then enabled the .example configs. This seemed to allow for the first time configuration to proceed. I restarted the security provider, then reversed the process on the config files. Now our indexes show available and we can re-index. Now we are stuck with the following error when trying to reach /coveo/rest:

    {"statusCode":500,"message":"Server is unavailable: (General SSLEngine problem to https://localhost:52810/7.0/CoveoSearchService, General SSLEngine problem to https://localhost:52810/7.0/CoveoSearchService)","type":"ServerUnavailableException","executionReport":{"type":"RootReport","description":"","childs":[{"type":"QueryPipelineReport","description":"Resolve pipeline","duration":0,"result":"None","childs":[]},{"type":"QueryPipelineReport","description":"Resolve identities","duration":0,"result":"ArrayBuffer(UserId(extranet\Anonymous,Sitecore Security Provider for xyz,User,None,None))","childs":[]}]},"results":[]}

I can hit the address directly and see the message that the server is listening. Any thoughts?

Gravatar for

Comment by sholmesby, Nov 10, 2015 9:48 AM

You mention in your update:- "I disabled coveo.searchprovider.config and the, then enabled the .example configs."

For the default installation, you need all of the configs enabled. The default ones, AND the .example ones. The package installation wizard will have updated all of these with your correct settings.

If the files are correct, you should be able to just rebuild an index in Sitecore for the Admin tool to work. We have found that on occasion, we needed to create that blank index in CES though (on the InitialSetup page). After that it worked….. but I'm not really sure why.

Gravatar for

Comment by Ben, Nov 10, 2015 10:21 AM

I had Coveo for Sitecore 1081 installed, and ran through the upgrade process to 1123. I added .disabled to my existing config files while doing the upgrade. After the upgrade, and merging any necessary changes into my configs i removed the .disabled. That is when I ran into the initial issue where Coveo was trying to (unsuccessfully) perform a first time setup, even though this was an upgrade. That's when I switched over to use the example configs, managed to get through the first time setup, then switched back to my pre-existing configs. I'm still stuck with this next issue though.

1 Reply
Gravatar for

Answer by Jean-François L'Heureux, Nov 10, 2015 11:26 AM

With the history of events you describe, can it be possible that the Coveo Search API config.yml file references the old CES index certificates instead of the newly created index certificates?

I would check and update the config.yml certificates paths. If they are already ok, it is possible that the service was started before the creation of the new CES index. Thus, the Coveo Search API is still using the old certificates instead of the new ones. Try to restart the Coveo Search API service to see if it helps.

Gravatar for

Comment by Ben, Nov 10, 2015 12:06 PM

All of the paths were correct, and restarting the service didn't matter, but I'm assuming this answer is along the right path, and what eventually worked was the almighty restart.

Ask a question