Why are my hosted feature layers failing to copy in my distributed collaboration?

[KevinChristy1]

This is my current distributed collaboration setup:

AGOL - Host, uses standard logins

Enterprise Portal 10.6.1 - Guest, uses IWA

• Did not set up web-tier authentication
• created groups during the collaboration process
• The guest Portal is set up to only receive data from the AGOL host.
• The workspace is set up to copy data.

So I have a survey created in Survey123 that feeds a hosted feature layer in AGOL. I ensured that sync was enabled on that hosted feature layer. I shared said hosted feature layer with the workspace group. The first sync takes place and the hosted feature layer is copied over to the guest Portal like a dream. I can fully access and interact with the layer. The layer is still set to allow sync.

Everything is wonderful, then I run a test.

On the guest Portal side, I add the copied layer to a web map and enable the refresh interval. I then go back to my host AGOL environment and fill out another survey to add a record. The hosted feature layer on the AGOL side is immediately updated without issue. I then go back into the guest Portal side, and schedule the sync for the workspaces to occur within the next two mins or so. I am simply testing to see if the feature layer updates properly at sync...

It does not.

I get the following screen message:

Clicking it reveals...

And to top it all off I get a notification on my AGOL site that "The hosted feature layer could not be sent as a copy, so it was sent as a reference instead."

Now, my nice original hosted feature layer copy seems to have lost some of its functionality and has not updated.

It is my understanding from everything I could find and read that when performing a collaboration between AGOL and Enterprise 10.6.1 that hosted feature layers can be copied.

Can anybody tell me why this could be occurring?

[Anonymous User]

Hi Kevin, copying feature layers is fully supported at the version you are using. The first thing I'd recommend checking is your portal logs. Also, the URL of the copied item in ArcGIS Enterprise, does it refer to your Enterprise environment or back to ArcGIS Online? 

[KevinChristy1]

Hilary,

Thanks for the response! My portal logs didn't seem to show anything out of the ordinary...would it be something other than a SEVERE level log?I looked at my server logs and found that there was an error occurring. It was generating a file "System_SyncToolsEx_GPServer_abunchofnumbers.dmp" which sounds like it could be part of the issue. 

To answer the second part of your question, the copied item in my portal does reference my portal, not AGOL.

[Anonymous User]

Hi Kevin, sure thing - it does appear that your layer was copied if it's referencing your Enterprise URL, so that's a good sign. There might be a syncing issue though, as indicated by your server logs. 

Portal logs may give us more details. You can access those through https://webadaptorhost.domain.com/webadaptorname/portaladmin > logs > query. Do you see anything specific to collaboration there (maybe around the time of a sync)?

Hilary

[KevinChristy1]

Hilary,

So I am working with Esri technical support on this matter as well and after reading that dump file, so far the solution is to recreate the SyncToolsEX service. However, as it is a required service, we cannot just copy the JSON, delete and recreate it. So I am currently still waiting to hear back. I will keep anybody reading this thread posted.

[ThomasJones1]

Hi Kevin, 

Just to follow up on Hilary's post, I would recommend temporarily changing the portal logs to 'DEBUG' level. Then start a manual 'sync' from the guest Portal. This should give you the best chance of capturing additional logs.You'll want to change the logs back after the test. As 'DEBUG' level logs can create large log files.

• Portal Admin Directory > Home > Logs > Settings > Edit > Log Level: DEBUG

The first collaboration log messages will likely be something like 'A scheduled collaboration configuration synchronization job has started for collaboration with id:XXXXXXXXXXX'. I would also recommend searching for the item id of the item that fails to 'share a copy'. This should help you find any relevant error messages.

It's also possible to view the sync job status from portal sharing REST endpoint. This may also help provide more information on the 'share as copy' failure.

• Example URL: https://webadaptorhost.domain.com/webadaptorname/sharing/rest
  • Home > Portals > Self > Scroll to the bottom on the page > Collaboration.
  • Click on the relevant collaboration id > Collaboration Workspaces >
  • Click on the relevant collaboration workspace id > Sync Status 

Hope this helps!

Thanks,

Thomas.

[LarryJahn]

Did you ever find a resolution to this?  I am running into the same issue.  Have it set to copy, but it fails and then just references the synced AGO files.  Sync is enabled on all of the layer files I am trying to sync through collaboration.  

Is there a file size limitation on files synced through a distributed collaboration?

[KevinChristy1 · Accepted solution]

Larry,

I was able to fix the issue by ensuring my server certificates were properly updated. I guess our root and associated certificates were not aligning. We also upgraded from 10.6.1 to 10.7.1 and that rectified our issues.

Hope this helps!

Kevin

[LarryJahn]

Kevin,

Thanks for the info. and quick reply!  We'll give that a shot to see if it resolves our issue.

[IngridMans]

Where can I find details about how to check / verify my root certificates? 

I'm having the same issue as well for the 'feature' version of layers (published as a reference from sde enterprise database, 'sync' is enabled) getting shared as copies. The sync appears to have started failing some months ago, and older versions of the data are shown instead. 

Under the Portal Admin directory logs, I'm seeing errors about 'No replica info received from peer portal or this portal does not have any replicas associated with the peer portal....' and I'm not certain where to look or what to try next.