We recently undertook a 10.7.1 -> 10.8.1 Enterprise upgrade and as part of that we attempted to upgrade Spatiotemporal DS and GeoEvent.
When we were upgrading Spatiotemporal, we ran into an error stating:
"Attempt to configure data store failed. Caused by: Spatiotemporal big data store upgrade has completed but there were some problems while migrating metadata. Please run the repair tool to fix it."
We then searched for what the "repair tool" might be and ended up running:
"configuredatastore.bat https://url:6443 admin password D:\arcgisdatastore --stores spatiotemporal --operation repair"
Which failed with an error: "Error encountered: Failed to repair data store."
At this point, we were a bit stuck as we were attempting to perform this upgrade during a pre-defined outage window. First question, was this the correct tool to try and run? Or, was there something else we could have tried to fix the spatiotemporal DS?
In the end, the only way we could get around this within our outage window was to uninstall/re-install a new Spatiotemporal DS. Obviously this was not ideal as we lost the data we had stored in there.
We then upgraded GeoEvent to 10.8.1, which looked to have upgrade fine, however, after I applied the first GeoEvent 10.8.1 patch, GeoEvent would no longer start up. Again, due to time constraints, I ended up doing a administrative reset (as described for older versions 10.6.1 etc.) and then re-applied the backed up config.xml and managed to get GeoEvent back to where it was (with the new Spatiotemporal DS registered).
Since the upgrade, I've had to rebuild a number of the Spatiotemporal DS services, which appear in the GeoEvent Manager like so. In the older version at 10.7.1, for these equivalent services, after I created them I moved them to be owned by a different Portal administrator, instead of the Service Account (who is also an administrator of Portal) running GeoEvent. I did the same thing this time around at 10.8.1 and as soon as I re-assigned ownership, I noticed that these Spatiotemporal Services were now appearing as blank for the Map Service and Feature Service layer within GeoEvent. Is it expected that re-assigning ownership like this would break this relationship within GeoEvent? (It does still log data to the layers)
Also, if the above is true, would this have been the cause of our problems migrating metadata during our Spatiotemporal DS upgrade mentioned at the start of this post?