The operation couldn't be completed. Error in obtaining version for Sync

[BrianHiller]

From portal 10.3.1 I've published a simple point feature class as a feature service with the sync function enabled, the feature class is registered as versioned from an enterprise GDB. The feature class has attachments and a related non-spatial table also has attachments.

The service publishes successfully and I can make edits to both the point feature class and the related non-spatial table when connected, but when I try to download the map to my device to work offline (iPad running ArcGIS Collector for iOS), I get the following error: The operation couldn't be completed. Error in obtaining version for Sync. I get this error regardless of whether i publish from the default version or a child version off of the default version.

When I publish I've tried both the Create a version for each "Downloaded Map" and "User" both return the same error.

Has anyone run into this issue before? If so, any ideas what I may be doing wrong?

[MiaogengZhang]

Could you set server logging level to debug and see if you can spot any errors reported when you download?

http://server.arcgis.com/en/server/latest/administer/windows/about-server-logs.htm

[BrianHiller]

Thank you for reminding me to check the server logs. Yes there was a severe error occurring when trying to download the replica. I got an error using the system/syncTools.GPServer, there was an error creating the version, the error stated it was an invalid version name.

As I understand it the version name is created based on the user logged into the collector app. In my case we are using SAML 2.0 and connecting to ADFS. The username which comes through based on our configuration is behiller@burnsmcd.com.

When I login to collector with a built in Portal account (that does not have the @ symbol) the creation of the version and the download of the replica worked fine.

It appears to me that ArcGIS Server does not want to create a version that has an @ symbol in the name. Can someone confirm whether they have seen this behavior before? If so is there a work around, a majority of our users will be logging in with enterprise logins (which will have the @ symbol in the name).