Why is the Overwrite Web Layer operation failing?

[BillSchlatter]

My organization is currently getting ready to update a large portion of our data on ArcGIS Online, and in order to minimize the updates necessary to our various webmaps, we're trying to use the ArcGIS Pro feature Overwrite Web Layer.  However, the user account that hosts the vast majority of this data can't seem to make it work.  It doesn't seem to be user error - an identical workflow produces the expected results when done using my own user account. 

Whenever we try overwriting to our main hosting account, however, we get this error message (Screenshotted in the attachment):

"Cannot overwrite <layer name>.  Please configure that you are signed in as the web layer owner and the location of the item has not changed." 

(The odd word choice is accurate, as you can see in the screenshot)

We are logged into the correct account in both ArcGIS Pro and ArcGIS Online.  The location of the item has indeed not changed since being uploaded.  We've tried a variety of fixes, many based on other questions from people having trouble with the Overwrite Web Layer feature.  These include: Renaming layers and/or folders to remove all spaces, moving the layer to the account's root directory in AGO before trying to overwrite, and changing ownership of the layer in AGO to my user account.  None of theses options have worked, and in the last case, only layers moved from our main hosting account threw the error message - datasets uploaded directly to my account can be overwritten without issue. 

We know that we can always upload the datasets anew, but since many of them are referenced in active webmaps, that creates a lot of extra work tracking down and updating all the webmaps as necessary.  Also, the Overwrite workflow is one we expect to be using repeatedly in the future if we can get the issues worked out, so we'd like to know how to make it work reliably. 

Does anyone have any experience with this problem?  Or suggestions for workarounds?

[BillSchlatter]

I have tested the procedure with new gdbs made and uploaded through Pro, and that works fine.  That's our long-term plan for maintaining these datasets, actually.  We are mainly hoping to avoid the headache of checking all of our webmaps to be sure we don't break anything when we upload new versions from scratch at this point. 

I asked my managed about the gdbs, and was told that they are actually relatively recent, created using ArcMap 10.5, which is the version our office is still using.  The data was pulled from our ArcGIS Server instance, though, and it's possible there was some weirdness introduced there. 

At this point, we've just decided to submit a tech support request, and assume there's a reasonable chance we'll have to do the upload-and-replace workflow we've been trying to avoid after all. 

[KoryKramer]

Thanks, Bill.  Please circle back here with what you find from technical support.

[ELIZABETHF_T_]

Was this issue ever resolved?, I have the same problem.

[BillSchlatter]

We didn't get anywhere with technical support, either.  They suggested attempting the updates using one of the Python libraries for interacting with AGO, which we didn't try because, at the time, none of our developers had any experience with those tools.  We wound up doing it the hard way, re-making and re-uploading all of the error-throwing geodatabases to get versions onto AGO that we could update. 

We now have someone refining a Python-based backup script that lets us maintain offline backups of our AGO content, so we'd probably give the Python approach a try if the problem somehow recurred.  Which it hopefully won't. 

[Arne_Gelfert]

Kelly,

Should my takeaway from your comment here be that overwriting a map service on a federated ArcGIS Server through Pro assumes that it was originally published with Pro?

As part of the migration to Enterprise/Portal, I published a bunch of maps using the Python API (not the old arcpy) to a federated AGS. As an preparatory step I had imported old MXD's into APRX projects and then scripted the publication to web from there. Now, I'm in Pro tweaking some of these maps and want to republish them as map services but I get this context rich error message...

Failed to publish web layer‍

I'm assuming that Pro is expecting to find an SD file somewhere other than the path I had referenced in my Python code, correct? If that's in fact so, how can I create a SD file through Python going forward that Pro can later read? I'm not familiar with the internals of the SD file. I've looked at the draft files, and they contain references to staging directories or the publishing machine, etc.

Long story short, what's a safe practice for mixing publishing through the Application and through Python API?

[GaryChristensen1]

Arne,

     Where you able to establish a workflow for overwriting your map services?  I'm trying something similar -  to overwrite a hosted feature service on an enterprise portal.  The service was published through Pro.  My script fails at Staging the service with an ERROR 999999: Something unexpected caused the tool to fail.  

[Arne_Gelfert]

No never have... plus it gets worse when you're running into the issue with wanting to republish a service that someone else has created or wanting to script out publishing of a bunch of maps others have been tweaking. Here ESRI's logic really defies how the world works. 

[ELIZABETHF_T_]

In my case, I had to change the Feature Layer(hosted) Editing settings, I had to uncheck Enable Sync.  Then, I was able to update layer.  If the Overwrite Entire Layer option isn't available, your hosted layer cannot be overwritten due to one of the following conditions: 

• Sync functionality is enabled on the hosted feature layer.

[rebeccanewell]

Has anyone encountered this recently? I'm using ArcPro 3.1.1 to overwrite a web layer already published in my orgs AGOL and it worked yesterday just fine. Today I have failed twice, and it seems to lose the feature layer completely from my AGOL account and the only the service definition remains?