nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

ThomasColson

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

Najděte více příspěvků označených jako

Accepted answers

DanielSieger1

Swizzling is the process where ArcGIS Server renames the paths for layers and other data within the MXD so that the MXD can be used by ArcGIS Server after publishing.

At publishing, the current MXD is put into a service definition file (SD File). This SD file is copied to the ArcGIS Server machine and un-packaged for use in the service.

If you are copying data to the ArcGIS Server, the paths need to be changed to point to the ArcGIS Server's directories where the copied MXD and data reside. These paths will be Swizzled.

If you are using a registered data store with the workflow where your server and publishing locations do not match, you will see the ArcGIS Server swizzle the paths.

You can see this workflow in the following document under this sub section title.

The publisher's machine and the server are working with different databases. Source: About registering your data with ArcGIS Server—Documentation | ArcGIS for Server

Fo shizzle?

All comments

DanielSieger1

Swizzling is the process where ArcGIS Server renames the paths for layers and other data within the MXD so that the MXD can be used by ArcGIS Server after publishing.

At publishing, the current MXD is put into a service definition file (SD File). This SD file is copied to the ArcGIS Server machine and un-packaged for use in the service.

If you are copying data to the ArcGIS Server, the paths need to be changed to point to the ArcGIS Server's directories where the copied MXD and data reside. These paths will be Swizzled.

If you are using a registered data store with the workflow where your server and publishing locations do not match, you will see the ArcGIS Server swizzle the paths.

You can see this workflow in the following document under this sub section title.

The publisher's machine and the server are working with different databases. Source: About registering your data with ArcGIS Server—Documentation | ArcGIS for Server

Fo shizzle?

ThomasColson

Love the last line! I'm getting this on a SQL View, which publishes fine on 10.3.1, but fails to drizzle the swizzle on 10.4.

DanielSieger1

You aren't using SQL Server 2008 are you?

ArcGIS Server 10.4 does not support SQL Server 2008.

http://downloads2.esri.com/support/TechArticles/W34229_DEPRECATION_PLAN_FOR_ARCGIS_10_4_and_10_3_1__082015.pdf

Is this a non-geodatabase? By this, I mean a SQL Server database that has not been enabled as an SDE geodatabase? You can right click on the database connection file in ArcMap to check this.

Can you publish anything from this same database to the 10.4 ArcGIS Server?

Can you try to publish a query layer of a single table? In ArcMap, File > Add Data > Add Query Layer > in the query box, enter select * from tablename.

Do you get swizzling errors on all publishing attempts? Or, just on publishing this view? Or all views?

How complex is the SQL view?

Can you test a another view with some simplified SQL instead of the full view?

-Daniel

ThomasColson

In Dekstop 10.3.1 File->Add Data->Add Query layer:

Use this query:

SELECT dbo.RARE_VIEW_LOCATIONS.LOC_NAME, dbo.RARE_VIEW_LOCATIONS.LOC_NOTES, dbo.RARE_VIEW_LOCATIONS.WATERSHED, dbo.RARE_VIEW_LOCATIONS.COUNTY, dbo.RARE_VIEW_LOCATIONS.STATE, dbo.RARE_VIEW_LOCATIONS.LOCATIONDESCRIPTION, dbo.RARE_VIEW_LOCATIONS.LOCATIONNOTES, dbo.RARE_VIEW_LOCATIONS.FCSubtype, dbo.RARE_VIEW_LOCATIONS.SPECCOM, dbo.RARE_VIEW_LOCATIONS.Location_Type, dbo.RARE_tbl_Events.Start_Date, dbo.RARE_tbl_Events.Observation_NOTES, dbo.RARE_tbl_Events.EditDate, dbo.RARE_tbl_Events.Event_ID, dbo.RARE_tlu_Species.taxaGroup, dbo.RARE_tlu_Species.Genus, dbo.RARE_tlu_Species.Species, dbo.RARE_tlu_Species.Species_GUID, dbo.RARE_VIEW_LOCATIONS.LOCATION_ID, dbo.RAREPOINT.SHAPE, dbo.RAREPOINT.GIS_LOCATION_ID FROM dbo.RARE_tlu_Species INNER JOIN dbo.RARE_tbl_Events ON dbo.RARE_tlu_Species.Species_ID = dbo.RARE_tbl_Events.Species_ID INNER JOIN dbo.RARE_VIEW_LOCATIONS ON dbo.RARE_tbl_Events.Location_ID = dbo.RARE_VIEW_LOCATIONS.LOCATION_ID INNER JOIN dbo.RAREPOINT ON dbo.RARE_VIEW_LOCATIONS.OBJECTID = dbo.RAREPOINT.OBJECTID WHERE (dbo.RARE_tlu_Species.Species_GUID = 'abcd1234')

Publish to SVR 10.3.1 as a map service with dynamic workspace enabled.

Works.

Publish to SVR 10.4

as a map service with dynamic workspace enabled.

Works.

In ArcMap, instead of a query layer, make a view in SQL and add the view to TOC.

Publish to SVR 10.3.1 as a map service with dynamic workspace enabled.

Works.

Publish to SVR 10.4

as a map service with dynamic workspace enabled.

Fails

Failed to create the service.: Updating the server connection string for layer RARE.dbo.Spatial_View_Hellbender failed. Attempted connection string was SERVER=AASABBBB;INSTANCE="DSID=4ad33bec-ac5e-43b6-984a-ddfc1f78df98";DBCLIENT=sqlserver;DB_CONNECTION_PROPERTIES=AASABBBB;DATABASE=RARE;VERSION=dbo.DEFAULT;AUTHENTICATION_MODE=OSA. Table name is RARE.DBO.%Spatial_View_Hellbender. Please verify the data exists on the server..

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

In all cases:

SQL is 2014 Enterprise, feature class is Geography Storage type non-versioned, SDE 10.3.1, Windows Auth ONLY, service acccount(s) have correct permission to the tables and views.

Since publishing a SQL view works in SVR 10.3.1, and doesn't work in 10.4, I'm leaning towards there's nothing wrong with my data and something wrong with 10.4.

Publishing a "regular" table (feature class) works in 10.4 as a map/feature service.

ThomasColson

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.

JasonHarris2

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

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.

DanielSieger1

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

Hi Daniel,

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

ChrisBeaudette

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

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

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.