GeoEvent error writing to feature service

[GillPaterson]

We have another log error that I am not sure whether it is related to SSL certs, keystores and config-stores.

A bit of background, we moved our config-store, Portal and Server came back up fine. GeoEvent did not, the browser changing from a secure connection to unsecure and having to add a security exception to view the manager. We weren't able to fix the issue (see this question), so we re-installed, and despite the browser now saying the connection is secure again, we are still seeing in the karaf logs, entries such as "no valid keystore" and "Failed to read certificate file... signed fields invalid". I tried to send through a test message and a log entry was added to say that the user didn't have permissions

"2019-08-05T16:35:02,510 | ERROR | FeatureJsonOutboundAdapter-FlushingThread-com.esri.ges.adapter.outbound/JSON/10.6.1 | FeatureServiceOutboundTransport  | 78 - com.esri.ges.framework.transport.featureservice-transport - 10.6.1 | {"error":{"code":400,"message":"User does not have privileges to perform this operation.","details":[]}}
2019-08-05T16:35:02,511 | ERROR | FeatureJsonOutboundAdapter-FlushingThread-com.esri.ges.adapter.outbound/JSON/10.6.1 | FeatureServiceOutboundTransport  | 78 - com.esri.ges.framework.transport.featureservice-transport - 10.6.1 | Error while writing to feature service VRN-Device-Locations. Error: {"error":{"code":400,"message":"User does not have privileges to perform this operation.","details":[]}}."

I have a feeling that the certs and this user permission error may be linked, but I am not sure how. I wasn't able to see any owners of the output connectors in GeoEvent (the config xml has owners for the definitions), and the owner of the item in Portal is a valid user.

How can I tell/change which user GeoEvent is using to write to the feature service? Is this the service account? (I am assuming so??)

Does the feature service need to have the same owner as the GeoEvent user? (they would have been when first published, but would just like to double check since the config-store and directories move)

I also have another feature service where GeoEvent can't see the layer within. This layer does exist in the AGS services directory. At this stage the only solution I have for this problem is to re-publish the service, however given the other issues, I am wondering whether it is all linked.

[Anonymous User]

Hi Gill,

Recently, I am working on a project with GeoEvent, though I didn't encounter exactly the same issue with yours, but did get output to FS ones. In my case, I found ArcGIS for Server logs would give much more details than GeoEvent gives. You probably could have a look AGS server log as well for futher troublshooting. 

As the account, could you please have a look at the Data Stores in GeoEvent manager to check what account used to register ArcGIS Server into GeoEvent?

Hopefully, you would find above a bit helpful.

[GillPaterson]

Thanks for the reply. There is no account registered for either Portal or Server to connect as Data Stores. Prior to this move it seemed to be ok without any credentials.

There are no logs in ArcGIS Server as the message never makes it to the rest endpoint. Despite being able to select the service in the manager for the output connector, GeoEvent can no longer delete or write features.

[GillPaterson]

This is no longer an issue. We ended up re-installing GeoEvent after removing all ESRI artifacts including registry files (risky, but for us it was worth it). One thing we noticed that on the previous install only the service account name had been entered during the installation process of ArcGIS Server and GeoEvent. This created a different Windows User folder, and even though it was accepted by Windows authentication with the same credentials, there was obviously something "different" about it. On re-installing we entered the service account as domain\account-name. So two things that I think contributed to fixing this issue:

1. entering the service account as domain\account-name

2. After federating, I made sure that I reset the configuration (there was some ambiguity as to whether this step was done on the previous failed install).

This install meant that the default Portal connection was valid from the start with no editing required from us. It also seemed to fix the issue where a feature service layer couldn't be access by the output connector.

Unfortunately it didn't fix our "signed field invalid" issues blogged here. (I have create an ESRI support case as to whether we need to pursue fixing these)

Hopefully this helps someone else.