Unable to publish map service with data in enterprise database using Server 10.4

[ThomasPuthusserry]

I have upgraded ArcGIS Server 10.3.1 to 10.4 and facing issues with publishing map services with data stored in enterprise databases.

The server is hosted in Amazon AWS with following infrastructure and works fine:

Windows 2012 R2

Server 10.3.1

PostgreSQL 9.3 (in the same server - localhost) with SDE enabled

PostgreSQL as AWS RDS with SDE enabled

However, when the server upgraded to 10.4, the service with data in enterprise databases (both localhost and AWS RDS) which used to publish are no longer working. The error is

The ArcServer log file shows the following details

Error executing tool. PublishServiceDefinition Job ID: j5a9a52478ffc49d19328e5ceefbb609f : 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).                System/PublishingTools.GPServer

Failed to create the service.: Updating the server connection string for layer sdedb1.web.%gwstatmaster_staging Events failed. Attempted connection string was ENCRYPTED_PASSWORD=00022e68334e624d44786b57627653553542393435702b3845413d3d2a00;SERVER=xxxxxxx.c11tt3rfoa7s.eu-west-1.rds.amazonaws.com;INSTANCE="DSID=a8960749-e49c-41db-a095-a8a257a693b4";DBCLIENT=postgresql;DB_CONNECTION_PROPERTIES=xxxxxx.c11tt3rfoa7s.eu-west-1.rds.amazonaws.com;DATABASE=sdedb1;USER=web;VERSION=sde.DEFAULT;AUTHENTICATION_MODE=DBMS. Table name is sdedb1.web.%gwstatmaster_staging. Please verify the data exists on the server.                System/PublishingTools.GPServer

If I uninstall 10.4 and reinstall 10.3.1 on the same server, everything back to normal and working fine.

Has anyone else experienced the same issue?

Thanks and any suggestions much appreciated

Thomas

[MercedesChinchilla]

Hi

You can review the privileges for the "arcgisserver" user if can edit the data that you can trying to publish. If you give the grant privilege you resolve this error.

[SarahNoakes1]

We have had a similar issue recently.  Some of the data we were trying to publish is in an Oracle ArcSDE database.  The user account accessing this data has some strange permissions set up.  Creating a new user account with minimal privileges set up resolved the issue.

[SrinivasanGanesh1]

Hey I found an easier solution. 

Popped up services.msc and restarted the ArcServer 10.5.1

While publishing from mxd, I used the (admin) connection (created as site mgr) instead of the (publisher) connection and I was able to overwrite existing service!! Mine was a 10.5.1 mxd with a query layer to Teradata 16.1

I was able to register my Teradata database via ArcCatalog but the browser based Server Manager kept spinning on any register attempts.

[MichaelVolz]

Srinivasan:

Are you using a query layer as a datasource where a table in Teradata 16.1 is spatially enabled with something like ST_Geometry libraries, but the Teradata 16.1 database in not a full-blown SDE database?

[SrinivasanGanesh1]

Yes a query layer. No need for SDE or libraries installed on Teradata side. We just added a column 'SHAPE' of datatype ST_GEOMETRY (this is Teradata - NOT the same datatype as ESRI's ST_GEOMETRY)

[EdgarIparraguirre]

We have had many ocasions where the issue has happened, specially when there is ArcGIS Data Store configured. The root of the issue is mostly related at the dsconnection.lst files with content not identifiable by the GPPublishingToolEX. The solution which has helped us (most of the times), is to remove all registered databases (will not affect any already published object), then to create new sde-connections (at the same version as AGS), and register the databases with the new connection.

Essentially what happens is that GPPublishingEx fails in process of (re)creating the  service's json under config-store, while parsing dsconnections.lst. My guess that the way de connection strings (lines in dsconnection.lst) has changed a lot through AGS versions, and that the parsing procedure inside GPPublishingEx  is not that smart at detecting those changes.