Select to view content in your preferred language

Server 10.4 and Snoop Dog: Failed to Swizzle.....

18148
16
Jump to solution
03-08-2016 12:10 PM
ThomasColson
MVP Frequent Contributor

Not making this up, yo....

In 10.4 SVR, when publishing a service, among other errors related to failure, I'm now getting:

SEVERE

Failed swizzling the service.

2016-03-08T14:55:42

System/PublishingTools.GPServer

What is swizzling and why it its failure related to publishing failing?

I have never seen this before......

16 Replies
ThomasColson
MVP Frequent Contributor

Yeah...it  might be a while. This is in a dev environment, I'm actually gearing up for another TS case, and validating 10.4 to reproduce the "other" issue I'm having in 10.3.1.

0 Kudos
JasonHarris2
Regular Contributor

I know about the view issue described here, but I came across this post because of a similar swizzling issue.  Check out: https://community.esri.com/thread/177553#comment-614422 for a workaround. 

Daniel Sieger ...once the student, now the master.  Good job

ChrisAdams
Esri Contributor

I have come across this issue as well. I can replicate it when I use Windows Authentication to connect to my query layers at 10.4.1, logged in as my domain user who owns the tables. However, the ArcGIS Server service is running as a 'headless' domain user. This user does have access to the tables as these have been granted successfully. However, even if I register the database the tables are in as the user running the ArcGIS Server service, then log in to ArcMap as my domain account who owns the tables, the publishing will fail. If I log in as the ArcGIS Server service account, it will publish.

Question 1: Why is swizzling taking place when I have registered my database with ArcGIS Server

Question 2: Why do I have to be logged in as the ArcGIS Server service account? This does not seem intuitive?

Failed to create the service.: Updating the server connection string for layer Radios failed. Attempted connection string was SERVER=dev;INSTANCE="DSID=090096d7-3620-4a20-8cfe-55946263acf6";DBCLIENT=sqlserver;DB_CONNECTION_PROPERTIES=dev;DATABASE=archive;AUTHENTICATION_MODE=OSA. Table name is archive."domain\AD-User".%Radios. Please verify the data exists on the server.

Failed swizzling the service.

0 Kudos
DanielSieger
Esri Contributor

Firstly, have you installed the publishing patch found here? ArcGIS for Server Publishing Patch 

There were issues at 10.4 and 10.4.1 were similar errors were seen.

Question1: Why is swizzling taking place when I have registered my database with ArcGIS Server
Because of some changes that were introduced in 10.4 to how database registration worked. At 10.4 and later versions of ArcGIS Server, all of your data will be "swizzled", even if it is registered. These changes primarily allow you to update database passwords in a registered data store without having to republish all of your services. 

Question 2: Why do I have to be logged in as the ArcGIS Server service account? This does not seem intuitive?

You are correct, that should not be the case. I would recommend you open a case with Esri Support to investigate this further. There could be a permissions related issue, or a defect here specific to query layers. It is hard to tell without additional information.

ChrisAdams
Esri Contributor

Hi Daniel,

Thank you for your quick response. The patch has indeed fixed this issue!

0 Kudos
ChrisBeaudette
Frequent Contributor

I was having the same issue.  My scenario:

- ArcGIS Server 10.4.1 (without the noted patch applied), running as an arcgis user that is a domain account

- SQL Server 2014

- MXD with a single layer that references the geodatabase with a domain account

- The arcgis domain account was added to the geodatabase using ArcCatalog:  Administration > Add User

- Publishing a simple map service, i.e. no feature service, KML, etc.

I got the following error in ArcMap:

001487 : Failed to update the published service with the server-side data location. Please see the server's log for more details

and the following 3 errors in the AGS logs, all with a 'Source' of System/PublishingTools.GPServer:

1)  Failed swizzling the service

2)  Failed to create the service.: Updating the server connection string for layer DB_NAME.SCHEMA_NAME.LAYER_NAME failed. Attempted connection string was SERVER=SQL_SVR_HOST_NAME;INSTANCE="DSID=deba8037-3eb1-48c8-ae85-5af6cab4ac1b";DBCLIENT=sqlserver;DB_CONNECTION_PROPERTIES=SQL_SVR_INSTANCE_NAME;DATABASE=DB_NAME;VERSION=sde.DEFAULT;AUTHENTICATION_MODE=OSA. Table name is DB_NAME.SCHEMA_NAME.LAYER_NAME. Please verify the data exists on the server.

3)  Error executing tool. PublishServiceDefinition Job ID: j5fc1408de51349e3b665bab437ddd069 : ERROR 001487: Failed to update the published service with the server-side data location. Please see the server's log for more details. ERROR 001369: Failed to create the service. Failed to execute (Publish Service Definition).

I was able to publish to other geodatabases in the same instance.  I did a SQL Profiler trace on the failed publish and found the following error:

The EXECUTE permission was denied on the object 'SDE_get_primary_oid', database 'DB_NAME', schema 'sde'.

When I compared the SQL Server permissions on that stored procedure, I found that the 'public' db role had no permissions at all in the database where the publish was failing, and 'execute' permissions in the DB where it was succeeding.  

Perms on sde.SDE_get_primary_oid in database where publish was failing:

Perms on sde.SDE_get_primary_oid in database where publish was succeeding:

A cursory glance at other stored procedures in the sde schema showed that the SQL 'public' role had execute permissions on all of them, even in the database where the publish was failing.  For some reason, the required permissions were not granted to SDE_get_primary_oid only.  This was unexpected since in both databases I added the same domain user account using the Create Database User tool.

The solution was simply to add execute permissions for the SQL 'public' role on the sde.SDE_get_primary_oid stored procedure.  And, of course, to swizzle my bad self.

ANRGIS
by
Frequent Contributor

Validating our data stores in ArcGIS Server Manager resolved the issue for us.