Frequently asked questions about distributed collaboration—ArcGIS Enterprise on Kubernetes

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.

ArcGIS Enterprise and ArcGIS Enterprise collaborations

I have an ArcGIS Enterprise on Kubernetes deployment. I would like to set up a collaboration with another ArcGIS Enterprise organization, which is a Windows deployment. Is that possible?

Yes. At 10.9.1, ArcGIS Enterprise on Kubernetes can act as either the collaboration host or guest for an ArcGIS Enterprise deployment on either Windows, Linux, or another Kubernetes deployment. An ArcGIS Enterprise on Kubernetes deployment can also act as a guest for an ArcGIS Online hosted collaboration. For more information, see About distributed collaboration and Key concepts for collaboration.

I would like to share feature layers as copies in my collaboration. Is this option available?

Yes. Distributed collaboration supports sharing feature layers as copies when both host and guest portals are ArcGIS Enterprise.

How do I update the web-tier authentication credential or PKI certificate used for a collaboration with another ArcGIS Enterprise participant?

ArcGIS Enterprise supports changing the web-tier authentication credential and PKI certificate used to communicate with another ArcGIS Enterprise participant. These changes can only be done through the Portal Services REST API. See the Distributed Collaboration Update Web-tier Authentication Configuration REST API topic for more information. You can add, update, and delete web-tier or PKI certificate authentication for a collaboration's ArcGIS Enterprise participants. To learn more, see Manage collaborations and Manage collaborations as a guest

Will nondefault SSL protocols and/or cipher suites on one site impact distributed collaboration with another site?

Nondefault configurations for the SSL protocol or cipher suites used on one site should not impact a distributed collaboration with another site, even if the protocols or ciphers do not match or overlap.

ArcGIS Online and ArcGIS Enterprise collaborations

I have a hosted feature layer view published to my ArcGIS Online organization and I want to share it with my ArcGIS Enterprise organization. Can I share a view to a collaboration?

Yes, you can share hosted feature layer views to a collaboration.Hosted feature layer views can be shared as copies if the feature layer has been configured to be sent as a copy.

I use both ArcGIS Enterprise and ArcGIS Online. Can I set up distributed collaboration between the two?

ArcGIS Enterprise 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. An ArcGIS Enterprise organization can only collaborate with one ArcGIS Online organization at a time. For more information, see Set up an ArcGIS Enterprise and ArcGIS Online collaboration.

Can ArcGIS Online organizations using a developer subscription participate in a distributed collaboration with an ArcGIS Enterprise organization?

No. An ArcGIS Online trial, personal use, or developer subscription organization is not able to participate in distributed collaborations.

My ArcGIS Online organization changed its URL key. How can I reestablish my organization as a collaboration participant?

You can accomplish this in one of two ways:

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 reinvited by the host using the new URL.

Why do I receive an SSL certificate error while attempting to accept a collaboration invitation for an ArcGIS Online organization?

If your organization is using a forward proxy, you will need to import the certificate used by the forward proxy into the ArcGIS Enterprise on Kubernetes portal as a root/intermediate certificate and then proceed to accept the invitation.

I've disabled the option to allow access to the portal through HTTPS only. In ArcGIS Online, when I try to view feature layers shared by reference in a map viewer, I am prompted with Error: The layer, [layername], cannot be added to the map. What's happening?

In Map Viewer Classic or Map Viewer in ArcGIS Online , this error is used to inform the user that the requested content may not be added to the map. By default, ArcGIS Online is configured to only allow access through HTTPS. Verify that the ArcGIS Enterprise feature layer service URL is using HTTPS. If it is not, update the service URL to use HTTPS. To see how, follow the steps in the FAQ: Is it possible to update a service URL in an existing ArcGIS Online web map? support article.

Can I copy data from ArcGIS Online into my enterprise geodatabase?

No. Destination layers within a collaboration must be hosted layers from ArcGIS Online or ArcGIS Enterprise.

Can I copy data from an enterprise geodatabase to ArcGIS Online?

Yes. If the enterprise database is registered to a federated server in ArcGIS Enterprise, its data can be used as a source layer in collaboration between ArcGIS Enterprise and ArcGIS Online.

When collaborating between ArcGIS Enterprise and ArcGIS Online, what changes are required to my network's firewall?

In this configuration, all communication is initiated by the ArcGIS Enterprise portal. As such, network firewall rules must support outbound communication over port 443.

Sharing web apps

Can I share web apps in distributed collaboration?

Yes. ArcGIS Enterprise collaboration participants can share web apps to other ArcGIS Enterprise participants that are at a version equal to, or greater than, their own as well as ArcGIS Online. Supported web apps are those created from configurable web app templates and Web AppBuilder. Group-based web applications are also supported.

ArcGIS Online participants cannot share web apps to ArcGIS Enterprise participants at any version.

Can a collaboration participant edit a web app they've received?

Once shared, most web apps may be edited by other collaboration participants. These edits will be overwritten once the original owner updates the web app. Edits made by a receiving participant will not be sent back to the original owner. However, web mapping applications cannot be edited by the recipient.

I have created custom widgets in ArcGIS Web AppBuilder. Can these be shared to collaboration participants?

No. Custom widgets, including those that have been registered and have the item type AppBuilder Extension, cannot be shared through distributed collaboration.

Can I share a web app item that references a custom web app that I've deployed to my web server?

Yes. Web app items that reference application URLs outside of your portal may be shared, as long as collaboration recipients have been granted permissions to access the externally hosted application.

Can I share ArcGIS Living Atlas of the World web apps to a collaboration?

No. ArcGIS Living Atlas web apps cannot be shared through distributed collaboration.

What happens if a collaboration participant shares a configurable app template that has been retired in my version of ArcGIS Enterprise?

Retired ArcGIS Configurable Apps templates are still available and accessible in portal. If a recipient who is using an earlier version of ArcGIS Enterprise shares a template with you, and that template has been retired in your current release, you will still be able to access and view the shared application.

Can I share configurable app templates that require a group (Minimal Gallery, Layer Showcase, and so on)?

Distributed collaboration does not support the sharing of ArcGIS Configurable Apps templates that require a group.

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.

Why do I get a time-out error after enabling sync on a feature layer in my ArcGIS Online organization?

The item page may time out 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." Why?

This error is encountered when a web map 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 web maps containing feature services 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.

Why can't my receiving participants synchronize their edits to a feature service I've shared as a copy?

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.

If you want to save your edits to a received item, export the feature service and publish the exported data as a new hosted feature layer. This new hosted feature service will not receive synchronized edits from the source feature service, but you will be able to make edits to the service.

You can also allow two-way sharing of edits to feature layers between recipients. For more information, see Share content with collaboration groups.

When attempting to share a feature layer as a copy to a collaboration workspace configured to allow two-way sharing of feature layer edits, edits made by the receiving participant are not synchronized to the original feature layer owned by the source participant. What is happening?

The receiving participant may not be using a version of ArcGIS Enterprise that is at 10.9 or later. Sharing edits two-way is only possible starting at 10.9.
The receiving portal may not have Send and Receive access to the workspace. The host organization will need to update the guest's access to Send and Receive.
The shared feature layer may not have sync enabled or have supportsBiDirectionalSyncForServer set to true. For more information on enabling feature layers to support two-way sharing of edits, see Shared hosted feature layers or Share feature layers from an enterprise geodatabase.
The feature layer may have been shared before the collaboration workspace was configured to support two-way edit sharing. To troubleshoot, unshare the original feature layer item from the group joined to the collaboration workspace and then reshare to create a new copy of the item.
The collaboration workspace will need to be created at a version of ArcGIS Enterprise that is at 10.9 or later.

Caution:

When editing feature layers that support two-way sharing of edits, it's important to note that no checks occur to detect and prevent concurrent edits. When edits are submitted, the last change submitted takes precedent, overwriting preexisting edits to the feature layer. To avoid data conflicts, the archived version of the feature service should be consulted before making additional edits.

I have a feature layer shared with a group linked to a collaboration workspace where the option to copy data is selected. How can I change the workspace setting to share as references?

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.

When attempting to share a feature layer as a copy, the item was instead copied as a reference because it had not been sync enabled. After enabling sync on the feature layer, it continues to share by reference. What is happening?

When shared initially, the item was copied as a reference because sync was not enabled on the layer. Subsequent synchronization attempts will continue to share as references even if sync has been enabled. To share the feature layer data as copies, unshare the item from the collaboration. This will remove the item from the receiving participants. Then, reshare the item to the collaboration. Since the feature layer now has sync enabled, it will be shared as a copy.

Can I share a feature layer with branch versioning to a collaboration as a copy?

Yes, feature layers with branch versioning can be shared from ArcGIS Enterprise to ArcGIS Enterprise and from ArcGIS Enterprise to ArcGIS Online. Support for this capability was added at and ArcGIS Pro 2.3

When attempting to share a feature layer as a copy to a workspace configured to allow two-way sharing of edits, the item is shared as a copy. Edits made by the source are shared with the receiving participant, but edits made by the receiving participants are not received by the source. What is happening?

Your feature layer has sync enabled, but may not support replica tracking or bidirectional sync. To troubleshoot, access the feature layer using the ArcGIS REST API and confirm the layers have the following:

Has sync enabled—The feature service property capabilities should appear as follows:
```
"capabilities": "Query,Create,Update,Delete,Editing,Sync"
```
Supports replica tracking—The feature service layer property isDataReplicaTracked should be true:
```
"isDataReplicaTracked": true
```
Supports bidirectional sync—The feature service property syncCapability should have the secondary property supportsBiDirectionalSyncForServer set as true:
```
{
  "syncCapabilities": {
    "supportsBiDirectionalSyncForServer": true
  }
}
```

If the feature layer does not support all the required capabilities listed above, unshare the item from the group joined to the collaboration workspace, update the service to enable the capabilities and then reshare to the group. For more information on enabling feature layers to support two-way sharing of edits, see Share hosted feature layers or Share feature layers from an enterprise geodatabase.

Can a receiving participant edit the schema of a shared feature layer and share those edits back to the source?

No, two-way editing of a feature layer's schema is not supported. Both the source and receiving participant can edit the schema of a feature service, but the workspace sync operation only includes edits (insert, update, and delete operations) that were available at the time the view was shared to the collaboration.

Sharing hosted feature layer views

Do I need to share both the hosted feature layer and the feature layer view with a collaboration workspace group?

Users have the option to either share both items or just share the feature layer view. If you decide to share both items with the collaboration group, participants will receive the data to create the hosted feature layer as well as the view data to create a second hosted feature layer. The relationship between the hosted feature layer and the feature layer view is not maintained. If only the hosted feature layer view is shared, the view definition will determine the data collaboration participants receive, while the hosted feature layer the view is associated with will not be shared. Instead, the view data will be used to create a hosted feature layer on the recipient's portal.

I have multiple views created from a single hosted feature layer. Can I share more than one view with a collaboration at a time?

Yes, multiple views from the same layer can be shared with a collaboration. Each shared view will be received by collaboration participants as a hosted feature layer that will be named based on the title of the shared view.

Do I need to have sync enabled if I want to share my view as a copy with a collaboration?

Yes, sync must be enabled on each view shared as a copy. However, sync can only be enabled for a view if it is already enabled on the view's associated feature layer.

Can hosted feature layer views be shared as references?

Yes, all hosted feature layer views can be shared as references. Each view that is shared as a reference causes a new item to be created in participating portals, with the new item referring to the original view service. Be sure to configure your collaboration workspace to share feature layers and views as references.

Are view schema changes applied to shared items?

No, view schema changes are not applied when an item is synced. The workspace sync operation only includes edits (insert, update, and delete operations) that were available at the time the view was shared to the collaboration.

When I share a hosted feature layer view that has multiple layers, each with a different area of interest defined, the item is shared as a reference rather than a copy. Why is this happening?

A hosted feature layer view with multiple layers can only be shared as a copy if each layer has the same area of interest defined.

When I share a hosted feature layer view with editor tracking enabled and a field definition, the item is shared as a reference rather than a copy. Why is this happening?

A hosted feature layer view with editor tracking enabled can only be shared as a copy if each of the editor tracking fields is included in the view field definition. Editor tracking fields include created_user, created_date, last_edited_user, and last_edited_date.

Synchronizing workspaces on-demand

I am the administrator and host of an ArcGIS Enterprise collaboration. Can I synchronize a collaboration workspace on-demand?

No. Only guest participants using ArcGIS Enterprise can synchronize on-demand.

Which portal members have the ability to synchronize a collaboration workspace on-demand?

ArcGIS Enterprise members with the administrative role have the ability to synchronize a collaboration workspace on-demand.

How often can I synchronize a collaboration workspace on-demand?

Once an on-demand workspace synchronization has started, you will not be able to start another job until the current job completes. If a scheduled synchronization job is already running, you will not be able to start another on-demand synchronization until the current job completes.

Why is the Sync Workspace option in my portal disabled?

When a synchronization job is already running, the Sync Workspace option is disabled in the portal. Once the job completes, the Sync Workspace option is enabled and you may use it to start another synchronization job. To determine the latest status for scheduled synchronization jobs, view the Sync Status report for its respective workspace.

Once on-demand synchronization has started, what items will be synchronized?

The behavior of on-demand synchronization is the same as scheduled synchronization. All items shared to a group will be synchronized. Updates for shared feature layers (including feature edits) in the group will also be synchronized.

Synchronizing workspaces using a scheduled interval

My portal is running on a server located in the Eastern time zone. I am an admin and am located in the Pacific time zone, and as such will be configuring my collaboration to run at a scheduled interval using Pacific time. If I choose to set a scheduled time for 8 p.m. my time, when will the scheduled synchronization job actually run on the portal's server, given the difference in time?

To avoid time zone discrepancies, scheduled times are displayed in the client's local time but are stored in the system as their equivalent coordinated universal time values. If you schedule the job to run at 8 p.m. Pacific time, after being converted to its equivalent UTC value, the sync will run on the portal machine at 11 p.m. Eastern time, as both times are equivalent to 3 a.m. UTC.

Troubleshoot

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 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. As configured by the administrator, collaborated content synchronizes on a scheduled interval. The default interval is 24 hours. The guest organization's distributed collaboration administrator can sync a workspace on demand using the Sync Workspace option. Alternatively, sync on demand can be called using the collaboration REST API. For more information, see the Sync REST API documentation for distributed collaboration.
The available disk space within receiving organizations may have reached 10 GB or less. When such a threshold is reached, no content is synchronized. A SEVERE level log message is recorded to indicate this. The collaboration administrator will also receive notification indicating the content store disk space usage threshold has been reached. Once the disk space is freed up, content synchronizes again. By default, the content store disk space threshold is 10 GB. This value can be modified through the Portal Administrator Directory.

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. In such cases, both the collaboration administrator and group owner will receive notification indicating that an item, intending to be shared as a copy, was actually shared as a reference. An entry will be written to the portal logs indicating that the item was shared as a reference because sync was not enabled.
The feature layer exceeds the maximum item size of 1 GB, which will cause the item to be shared as a reference. To verify, enable INFO level portal logs and look for the log entry that indicates the size of the shared feature layer data item.

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 the My Content tab of the content page 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.
  Note:
  Once you 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.

I received a feature layer by reference through collaboration. I added the feature layer in the map viewer, attempted to use the Print tool, and I received the following error: "An error occurred while creating the printed map." What could be causing this?

Any of the utility services will need to have access to, and be authorized to execute an operation on, the feature layer. When attempting to use the Print service on a feature layer shared by reference, your portal will make a request to the organization that shared the feature layer with you, and the organization will allow the operation to proceed. If you are receiving this error, you must confirm with the organization that its firewall and security allow for inbound requests.

Alternatively, a workaround would be to have them share the data to you as a copy, or to publish the data in your organization using the source data that has been shared.

Feedback on this topic?