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

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.

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

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. Please read the Distributed Collaboration Update Web-tier Authentication Configuration REST API topic for more information.

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

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

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. Starting at 10.6.1, hosted feature layer views can be shared as copies if its 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?

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.

Can ArcGIS Enterprise collaborate with more than one ArcGIS Online organization?

No. Currently, ArcGIS Enterprise supports the ability to collaborate with only one ArcGIS Online organization.

My ArcGIS Online organization changed its URL key. How can I re-establish 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 re-invited by the host using the new URL.

Why isn't my ArcGIS Online organization accepting invitations from an ArcGIS Enterprise 10.5 portal?

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

My collaboration includes guests using ArcGIS Enterprise 10.5 and 10.5.1. Will my content deletion policy apply to these organizations?

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.

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 Map Viewer, I am prompted with "Error: The layer, [layername], cannot be added to the map." What's happening?

In the ArcGIS Online Map Viewer, 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 steps in this 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.

Can I share web apps in distributed collaboration?

Yes. Collaboration participants using ArcGIS Enterprise 10.6.1 can share web apps to other ArcGIS Enterprise portals with an equal to or greater version to their own. For example, ArcGIS Enterprise 10.6.1 participants can share web apps with other participants using ArcGIS Enterprise 10.6.1 or to ArcGIS Online. Participants using ArcGIS Enterprise 10.6.1 will not be able to share web apps to participants using ArcGIS Enterprise 10.5.1 or 10.6. If a participant attempts to share web apps with recipients using a previous version, the web app will not be received. The recipient's administrator will receive an error message in the portal logs and via a notification.

ArcGIS Online participants cannot share web apps to ArcGIS Enterprise participants.

Can a collaboration participant edit a web app they've received, or its underlying data? Will its original owner be notified of the edits?

Yes. Once shared, web apps may be edited by other collaboration participants. However, such 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.

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

If the custom widget has been registered as a portal item, the widget may be shared in a collaboration. The deployed widget code is not shared however, rather the item details will reference the widget's manifest URL. This means that the receiving participants must be granted access to the manifest URL in order to access the custom widget.

Can I share a web app item which 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 Living Atlas web apps to a collaboration?

No. 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 configurable app templates are still available and accessible in portal. If a recipient who is using an older 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.

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 timeout error after enabling sync on a feature layer in my ArcGIS Enterprise 10.5 portal?

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.

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

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." 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 would like 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 the service.

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.

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.

My Insights Model includes a tool that requires the GeoEnrichment Utility Service. What if the recipient does not have this service configured?

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

My Insights Workbook contains data from my RDBMS, which I have connected to through a database connection item. Will this database connection be shared with the recipient? Is the relational database connection item shared to the collaboration?

The database connection item will never be shared through collaboration. Any data set contained within your Workbook or Page, including those that are stored in your RDBMS, will only be accessible to the recipient by providing them with an authenticated user in your organization.

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.

My Portal is running on a server located in the Easter 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 pm my time, when will the scheduled synchronization job actually run on the Portal's server given the difference in time?

In order to avoid time zone discrepancies, scheduled times are displayed in the client's local time but are stored in the system as their equivalent Coordinate Universal Time values. If you schedule the job to run at 8 pm Pacific time, after being converted to its equivalent UTC value, the sync will run on the Portal at 11 pm Eastern time as both times are equivalent to 3 am UTC.

I want to protect received items in my collaboration from being deleted. Where can I specify this for my items?

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

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, which is the default configuration.

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.

Why do I see a status of "Not Supported" in the workspace for one of my collaboration participants?

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.

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 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 data size is more than the limit imposed by the administrator of the collaboration host; for example 1GB. In such cases, an entry will be written to the portal logs indicating the size of the shared feature layer data. If the size exceeds 1 GB, the item will be shared as a reference.
• The receiving participant is at version 10.5 or 10.5.1 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:

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 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 which shared the feature layer with you, and the organization will allow the operation to proceed. If you are receiving this error, you will need to confirm with the organization that their firewall and security allows 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.