This topic lists questions or issues that you may encounter when working with distributed collaboration and suggests possible solutions. If you don't find the problem you're looking for, you can also search for articles on the Esri Support center website.
Frequently asked questions
ArcGIS Enterprise and ArcGIS Enterprise collaborations
In addition to sharing layers as live references, I would like to share feature layers as copies in my collaboration. Is this option available?
At this release, distributed collaboration does not support sharing feature layers as copies when both host and guest portals are ArcGIS Enterprise.
ArcGIS Online and ArcGIS Enterprise collaborations
I use both ArcGIS Enterprise and ArcGIS Online. Can I set up distributed collaboration between the two?
ArcGIS Enterprise 10.5.1 supports distributed collaborations with ArcGIS Online. Such collaborations must establish ArcGIS Online as the host and ArcGIS Enterprise as a guest.
Can ArcGIS Enterprise collaborate with more than one ArcGIS Online organization?
No. ArcGIS Enterprise 10.5.1 supports the ability to collaborate with only one ArcGIS Online organization.
My ArcGIS Online organization changed it's URL key. What steps can I take to re-establish my organization as a collaboration participant?
- The collaboration host can delete and re-create a collaboration with the new URL key.
- The collaboration guest may leave the collaboration and request to be re-invited by the host using the new URL.
My ArcGIS Online organization is not accepting invitations from an ArcGIS Enterprise 10.5 portal. What's happening?
ArcGIS Enterprise 10.5 portals are not supported for distributed collaboration with ArcGIS Online organizations.
Sharing feature layer data as copies and syncing edits
I have edited the symbology in a shared feature layer; however, the updated symbology is not replicated for receiving participants. Why?
When sharing a feature layer as copies, the original symbology is preserved. Subsequent symbology edits are not replicated. However, when sharing feature layers within a web map, the symbology is stored in the web map and updates to the symbology are preserved.
What happens when a hosted feature service is shared to multiple collaboration workspaces in the same collaboration or in multiple collaborations?
When shared initially, the hosted feature service item is replicated. If subsequently shared, the item is not replicated again, and instead, the existing item is shared.
I get a timeout error after enabling sync on a feature layer in my ArcGIS Enterprise 10.5 portal. What is happening?
The item page may timeout while configuring sync if the layer contains a lot of data. The server, however, will continue to configure the data. After some time, configuration will complete and the process to enable sync on the item page will succeed.
I get a timeout error after enabling sync on a feature layer in my ArcGIS Online organization. What's happening?
The item page may timeout while configuring sync if the layer contains a lot of data. To address this issue when it occurs, you can run the updateDefinition operation in async mode on the layer using the REST admin API. See example 3 in the Update Definition (Feature Service) REST API topic.
When attempting to share feature layer data as copies, I encounter the following error in the logs: "Failed to create replica. Multiple layers are referencing a dataset, which is not supported." What is causing the error?
This error is encountered when a map service contains multiple layers referencing a single dataset in the database (for example, a Roads feature class is referenced in the map as two separate layers: major highways and minor roads.) When publishing maps to be shared as copies in collaboration, ensure authored maps do not contain multiple references to a single dataset.
What happens when a user changes the owner of a hosted feature service that has been shared as a copy?
Content that is currently shared continues to be replicated and synchronized and continues to work.
What happens when a user unshares a hosted feature service that has been shared as a copy to a group?
The hosted service will be deleted or unshared at the next scheduled sync. If that service is then shared back to the group or shared to a different group, a new copy is made and shared with receiving participants.
I have successfully shared feature services as copies to a collaboration. A receiving participant has edited data in their hosted feature layer. They expected these edits to be synchronized back to my feature service but they are not. Why?
Edits made to a feature service by the source owner can be synchronized, one way, with receiving participants. However, the ability for receiving participants to edit their hosted feature services and synchronize the edits back to the source feature service, a two way sharing of edits, is not supported.
I have a feature layer that is shared with a group linked to a collaboration workspace where the option to copy data is selected. I want to change the workspace setting to share as references. How is this done?
Unshare the feature layer from the group. If you are using scheduled sync, wait for a sync to occur. The default sync interval is 24 hours. The system administrator must then edit the workspace and join a new group with sharing of feature layers as references. Share the feature layer with this new group.
My map and tile layer don't get copied even though I have shared with a group linked to a collaboration workspace where the option to copy data is selected. What is happening?
Only feature layers are replicated with data copy. Other layer types (such as map or tile) are shared as a reference. Refer to sharing content to a collaboration for details.
How are multipatch feature layers shared in collaboration?
If the multipatch feature layer is not sync enabled, it is shared as a reference. If the multipatch feature layer is sync enabled and the collaboration is set up to share as copies, it is shared as a copy. However, subsequent edits are not synchronized when shared as a copy.
I have a feature layer and an WFS layer published from it. Which of these items should I share with the group for collaboration?
You must share all the layers and their derived layers (like WFS or tiles) with the collaboration group explicitly. This ensures that your derived layers will not be broken links when they get replicated via collaboration. In general, you must explicitly share all the items that you want to contribute via collaboration.
My collaboration group has received items that are configured with an HTTP URL and fail to open.
When a portal is configured with HTTP and HTTPS, a service copied by reference is configured with an HTTP URL. Because portals block mixed-content, the item will fail to open. To resolve this, manually change the URL to be HTTPS. It is recommended to allow access to the portal through HTTPS only.
My portal is configured to allow access through HTTP and HTTPS. Can this portal participate in distributed collaboration?
To invite a guest to a collaboration, each guest portal's URL must be specified as HTTPS.
What happens when one item in a group containing multiple items fails to be shared?
If an item fails to be added to a group when sharing, and that item is part of a group of items, the process will proceed so the other items are moved successfully. An error is logged indicating that one item failed. Have your portal administrator inspect the portal logs for details.
I am not receiving any content from the sending organization via collaboration. What could be the cause of this?
- There are a few cases that could be contributing to content not being received in your group. They are as follows:
- Your group may not have been joined to a collaboration workspace. Contact your system administrator to check that the collaboration workspace has been correctly configured and that the group in question has been joined to the workspace.
- The scheduled sync may not have occurred yet. When configured by the system administrator, the collaborated content synchronizes on a scheduled interval. The default interval is 24 hours. The system administrator in the sending organization can force a sync using the collaboration REST API. See the collaboration REST API for more details.
- The disk space within receiving organizations may have reached 80% of their capacity. When such a threshold is reached, no content is synchronized. A WARNING level log message is recorded to indicate this. Once the disk space is freed up, content synchronizes again.
I have shared feature layers to a group that is joined to a collaboration workspace where the option to copy data is selected. However, the receiving organization in my collaboration is instead receiving the feature layers as references. What is happening?
- Feature layers are replicated by reference under the following conditions:
- The feature layer does not support the sync capability or sync is not enabled on the feature layer. To enable sync, refer to sharing feature layer data as copies.
- The feature layer data size is more than the limit imposed by the administrator of the collaboration host.
- The receiving participant is at version 10.5 of ArcGIS Enterprise.
My feature layers are not receiving edits. What is happening?
Feature layers that have been copied to a receiving organization may stop synchronizing edits if the collaboration is deleted (by the host), the collaboration workspace is deleted, your organization has been removed from collaboration (by the host), or if your organization administrator has left the collaboration. It is also possible that no edits have been made to the feature layer in the sending organization.
Another possible cause is that the edits you are attempting to synchronize are greater than the size limit imposed by the collaboration host administrator.
I am using ArcGIS Enterprise and my feature layers are not receiving edits from an ArcGIS Online organization. I see the following severe error in the server logs:
"Initialization of Layer: failed."
What can I do to address the error?
Check to see whether the associated layers have a renderer that is based on an expression. To do so, follow these steps:
- Open My Content and choose to View item details for the feature layer.
- Click the Visualization tab.
- For each layer listed, check the Change Style button to see whether the Attribute to show is set to an expression. If so, do one of the following:
- In ArcGIS Enterprise, change the Attribute to show to be a field rather than an expression and click Save Layer. Once you have made this change for all applicable layers, edits should be received in the next sync.
Once change the Attribute to show and save the layer in ArcGIS Enterprise, you do not need to make changes to the corresponding feature layers in the ArcGIS Online organization.
- In the ArcGIS Online organization, change the Attribute to show to be a field rather than an expression. Next, unshare the item from the collaboration group, sync, and reshare the layer with the option to recopy the data.
- Create a view in the ArcGIS Online organization, adjust the layers in the view to not use expressions, and share the view with the collaboration rather than the feature layer.
A portal in my collaboration is configured to use PKI authentication through IIS and we have received the following error message:
Response from 'https://sampleserver.domain.com/portal' was 413 Request Entity Too Large. 'https://sampleserver.domain.com/portal' must configure server to allow large request entities.
What can I do to address the error?
- An administrator for the IIS web server that is using PKI needs to increase the value of the uploadReadAheadSize property to 51,200,000 (50MB). For example, if the PKI portal's web adaptor is installed as 'portal' under the Default Web Site in IIS, the following command could be used to change the uploadReadAheadSize property:
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/portal" -section:system.webServer/serverRuntime /uploadReadAheadSize:"51200000" /commit:apphost
- Additional details on the uploadReadAheadSize property can be found here.