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.

Yes. In 10.5.1, the option to share feature layers as copies was only supported between an ArcGIS Online host and ArcGIS Enterprise guest portals. As of 10.6, distributed collaboration supports sharing feature layers as copies when both host and guest portals are ArcGIS Enterprise.

ArcGIS Enterprise 10.6 supports changing the web-tier authentication credential and PKI certificate used to communicate with another ArcGIS Enterprise participant. At this release, 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.

At ArcGIS Enterprise 10.8.1, 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.

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.

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

As of 10.5.1, ArcGIS Enterprise supports distributed collaborations with ArcGIS Online. Such collaborations must establish ArcGIS Online as the host and ArcGIS Enterprise as a guest.

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.

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

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.

ArcGIS Enterprise 10.5 portals are not supported for distributed collaboration with ArcGIS Online organizations.

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

ArcGIS Enterprise 10.5 and 10.5.1 portals do not support the content deletion policy. Content shared to these participants will not be deleted. You should unshare any items that were previously shared to the collaboration workspace.

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.

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

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.

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

To share a workbook created in an earlier version of Insights, you must open the item in ArcGIS Insights 3.2.1 and resave the item. To share a model or page created in an earlier version of Insights, you must reshare the workbook as an Insights page or model. See the support topic on sharing Insights items from earlier versions through distributed collaboration for more information.

Yes. Starting at ArcGIS Enterprise 10.6.1, 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 supported at 10.8 and up.

For example, an ArcGIS Enterprise 10.6.1 participant could share a web app to another organization using ArcGIS Enterprise 10.6.1 and to ArcGIS Online. They would not be able to share web apps with participants using ArcGIS Enterprise 10.5.1 or 10.6, but they would be able to share with 10.7 and up. If this participant attempted to share a web app with a recipient using a previous version of ArcGIS Enterprise, the web app would still be added to the collaboration group, but it would not be received by the participant, and the administrator would receive an error message in the portal logs and via a notification in the portal.

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

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.

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

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.

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

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 can still access and view the shared application.

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

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.

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.

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

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.

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.

Content that is currently shared continues to be replicated and synchronized and continues to work.

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.

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.

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

• 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.

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.

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 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.

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 ArcGIS Enterprise 10.7 and ArcGIS Pro 2.3.

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.

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.

No, distributed collaboration does not support services using SDO_Geometry that are not registered with the enterprise geodatabase. Distributed collaboration uses feature service replication to share service data between participants. Since replication needs the data to be registered with the enterprise geodatabase—as it provides a mechanism to keep track of changes through archiving, versioning, and branch models—registering data with the enterprise geodatabase is required.

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.

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.

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.

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.

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.

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.

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.

The tool will be disabled in the model if the recipient does not have the service configured. However, the recipient will be prompted to configure the GeoEnrichment Utility Service, after which the tool will be enabled for use.

The database connection item will never be shared through collaboration. Any dataset contained within your workbook or page, including those stored in your RDBMS, will only be accessible to the recipient by providing them with an authenticated user in your organization.

The sharing of workbooks created in Insights desktop is currently not available. However, you may share the pages, models, and themes created in Insights desktop with a group joined to a collaboration workspace. This will create the item in your organization and share it with the intended participants.

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

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

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

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.

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.

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.

For each received item, click the Settings tab and enable Delete Protection for the item.

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.

You must share all the layers and their derived layers (such as 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.

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 that you allow access to the portal through HTTPS only, which is the default configuration.

To invite a guest to a collaboration, each guest portal's URL must be specified as HTTPS.

Yes, with some limitations. Kerberos will prevent the other portal from directly communicating with your portal. This means the other portal will be unable to send content to your portal using immediate synchronization. The content can still be shared, but only through scheduled synchronization. Any content you have shared to your collaboration group can be synced immediately with other participants if you have set your collaboration sync settings to Sync immediately.

You cannot set up a functional collaboration between two or more portals that use Kerberos authentication only.

The Status field in a workspace provides details on the most recent jobs, whether they are real-time or synchronized on schedule. This feature was not supported for ArcGIS Enterprise portals prior to 10.6. The Not Supported status is displayed for any guest participants whose portals are at 10.5 or 10.5.1.

Yes, the system will validate the values are within the range of an IP address, for example https://123.255.78.1/.

Yes. Starting at 10.8, you can now elect to save credentials for all service items that are shared by reference in a collaboration. The credentials are entered on the sending portal and are applied to services that shared with collaborating portals. However, there are several limitations that are applied to this feature.

At 10.8, the ability to save credentials can only be done through the ArcGIS Portal Directory sharing API using the Update Service Proxy Config operation. At 10.8.1, this work can now be done from the portal home application. For more information, see Manage collaborations as a guest and Manage collaborations.

Credentials are associated with a collaboration workspace and must be for a built-in user with Viewer privileges; credentials for a user with higher privileges will be blocked. The option to save credentials will only work in an ArcGIS Enterprise-to-ArcGIS Enterprise collaboration, where both ArcGIS Enterprise participants are using version 10.8 or higher. Credentials cannot be sent to or received from ArcGIS Online. This feature will not work on ArcGIS Enterprise systems that use web-tier authentication, such as IWA or PKI.

Credentials must be entered and saved by an administrator on the sending portal. If the sending portal can reach the receiving portal, items on the receiving portal will be updated immediately with the stored credentials. If the sending portal cannot reach the receiving portal, the items will be updated during the next scheduled sync.

Starting at ArcGIS Enterprise 10.8.1, when creating a collaboration, you can select If unable to share as copies shares as references if you selected Copies when setting up the workspace sync settings. Enabling this option ensures that, if there were to be errors when sharing items as copies, those specific items will be shared as references instead. This option can be updated when editing a workspace. For more information, see Manage collaborations.

No. Distributed collaboration does not support sharing Esri-owned content, which includes content owned by:

• Esri_[lang]
• esri
• esri_apps
• esri_boundaries
• esri_demographics
• esri_livingatlas
• esri_nav
• esri_notebook

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.

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.

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.
• The receiving participant is at version 10.5 or 10.5.1 of ArcGIS Enterprise.

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.

Check to see whether the associated layers have a renderer that is based on an expression. To do so, follow these steps:

1. Open the My Content tab of the content page and choose to View item details for the feature layer.
2. Click the Visualization tab.
3. 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.

An administrator for the IIS web server that is using PKI must 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 in the Server Runtime documentation.

Any of the utility services must 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.