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?
I hadn't tried that - I honestly hadn't realized it was possible. I'm fairly new to the GIS field, and have been focusing my training on Pro in anticipation of ArcMap eventually being deprecated. To be perfectly honest, I find ArcMap's fields of tiny buttons and menus within menus within menus to be pretty hard to decipher. I think I tracked down how to do it in ArcMap - File->Share As->Service->Overwrite an Existing Service.
Unfortunately, that solution doesn't seem to work, either. When I get to the list of services that could potentially be overwritten, the vast majority of the services in the account do not appear. Only one item out of about 50 in one of our larger folders is on the list, for example. The services that do appear (mostly in other folders) are all displayed with underscores instead of spaces, regardless of how their names were actually typed. Removing all whitespace from the non-displaying services doesn't make them start appearing on the list, either. Once again, the behavior appears to be confined to the account that hosts most of our organization's data - overwriting from ArcMap works fine, as far as I can tell, for datasets that have been in my user account since before the issue arose.
Thanks for the feedback! Do you (or anyone else) have other ideas?
You may want to get a case created with support to look into the specific issue. First, I would suggest verifying the owner of the layer , navigate to the item details page and check the owners name and verify who you are logged in as. As some different services appeared in ArcMap and you are receiving and error message indicating that ownership is an issue, I'd suggest double/triple checking that you are the owner. The overwrite function can only be performed on items that you own.
Does the SD file that you originally published exist in your ArcGIS Online organization? If it does, download the SD file, extract it into a folder using something like 7zip and open the serviceconfiguration.json folder in notepad. You will be able to verify the folder in which it was originally published.
If this seems confusing or you do this and still don't find the answer, call tech support. They can help you with these steps or look into why you are getting an error message that says there is an issue with the owner and folder when you have the proof that this is not the case.
As a workaround you can look into using the python API or rest api to overwrite the service. It can be a little more flexible depending on the cause of the issue. I'd suggest trying the other two options first, but let me know if you want some links to the Python API and REST API doc.
Double-checking ownership and currently logged-in accounts, everything still matches up. I don't think I'd even be able to see the services in question through the Catalog pane in Pro if I weren't logged into the correct account.
The datasets in question were originally uploaded as zipped file geodatabases, which doesn't seem to create a service definition file on AGO. Some of them still have the original .gdb, some don't, which doesn't seem to affect whether they can be overwritten. Is there a serviceconfiguration.json file in a .gdb? I don't see anything like it, but I'm not sure if there's a way to view the entire contents to check.
My manager is probably going to put in a tech support request soon. I originally posted here in case it was a common problem that I could get a quick answer to, but that doesn't seem to be the case. Thank you for your help!
That is correct. In Pro, I can see all the hosted feature layers, but most of them error out when I try to overwrite. In ArcMap, I see a much shorter list, consisting mainly of recently-uploaded datasets that don't need to be updated as of yet.
And yes, I've been double-checking to be sure that I'm logged into the correct account in AGO, Pro, and ArcMap at every step of this process, and I have double-checked that the services in question do indeed belong to that account as Kelly Gerrow suggested.
Were any of the hosted feature layers originally published up to AGO using Pro software? Or are you trying to overwrite hosted feature layers originally created from ArcMap in Pro?
I'm pretty much the new guy in the department here, and I'm the only person trying to use Pro for routine tasks so far, because I don't want to spend the time to learn two interfaces at once when one of them is, at least in theory, going to be obsolete in a few years. It's safe to say that the file geodatabases that were originally uploaded to AGO were made in ArcMap.
As an experiment, I tracked down the original file geodatabase used to upload one of the services, and tried uploading it to my own user account through the AGO->Contents->Add Item interface, the same workflow used to upload the services I am now trying to overwrite. I then tried overwriting it through Pro, and I got a completely different error: "Service cannot be overwritten if Sync is enabled and replicas exist." After double-checking the settings in AGO, I can confirm that Sync is, in fact, disabled, and was disabled when I tried the overwrite. So now I'm very confused, and wondering if something is wrong with the original file geodatabases, even though the services they produced work fine in webmaps.
How about trying the entire workflow in Pro including the creation of a brand new file gdb? If this works, then that is a workflow that you can use going forward, but it means recreating your file gdbs for AGO.
It might just be that the file gdbs have some corruption (but only enough to crash the overwrite operation), so you could try creating a brand new file gdb in ArcMap and publishing that up to AGO and then try overwriting the hosted feature layer from Pro.
Since you are a new guy you might not know this, but have the file gdbs been around for multiple ArcGIS versions? Mxds and file gdbs do occassionally get corrupted over time, especially if used between versions of ArcGIS. I know at my org, ArcGIS Server mapservices were created from scratch in 10.5.1 when we migrated from 10.3.1 to reduce the risk of problems with the services in the 10.5.1 environment. Different scenario but just making the point of cleaning up GIS objects over time.