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; } } }

Overwrite Map Service by Copy to Referenced Registered Folder

KrystalPhaneuf2

We have published a service mistakenly with the data copied to the server rather than by reference. We moved the data to a registered folder on the server and tried to overwrite. However, it continues to fail with an error 001369 Failed to Create the Service and Failed to execute (Publish Service Definition). We are able to publish a new service as registered to the referenced folder. Is there any reason why the overwrite should fail when going from non referenced/copied data to referenced data?

ArcGIS Enterprise 10.8.1

Publishing from Pro 2.6.2

MicrosoftTeams-image (7).png

Find more posts tagged with

Accepted answers

All comments

Anonymous User

Hi Krystal,

When you publish a service to ArcGIS server, its service workspace is defined somewhere in the configuration store. Once the service has been published, there is no way to change this either through the interface or programmatically. I would suspect that simply trying to overwrite the service definition to point to a new service workspace would fail, as not just the features but also the service definition and manifest would need to be changed.

As you have already discovered, I would encourage you to publish a new service using the desired service workspace, and then update your service URLs to reflect the new service.

-Calvin

DanielMcCullock2

Hi Krystal,

We have been having issues using the overwrite tool in general.

A method we have used to overcome this is the rename function via the server admin endpoint.

We re-publish the service using the same name with an "_new" at the end, such as "service_new". After testing the service to make sure it is functioning as we would like, we then rename the old service to have an "_old" and then remove the "_new" from the new service. After this we change the portal item IDs of the new service to match the old, remove the old service, then remove any new portal items that were generated in the process.

This means we only have a small outage on the service and are able to maintain the service name and portal item IDs.

Alternatively (I have not tried this for republishing but may be worth investigating), a service can be manipulated by retrieving the MSD file on the server, extracting (I use the 7zip software), manipulating the xml files which are extracted, then compressing again (using zip format and naming as a .MSD), replacing the .MSD on the server and restarting the service. We have managed to add in datum transformation information to the map.xml. There is xml files there specifically for the data.

Good luck and all the best

Danny

KrystalPhaneuf2

Thank you for the response Calvin. Is this error expected because it was originally published as a copy and not by reference? We are planning to test publishing from a referenced folder, then changing the source to SDE and overwriting. I am expecting this should work. Am I wrong?

JohnGalambos

Thanks Daniel, this approach is working well for us and this post helped me work up the courage to try it. I just wanted to add that this is working well for everything I've tried it on (map services and locators) with the exception of composite locators with copied data. There appears to be an issue when renaming composite locators such that the service won't start afterwards. There are some absolute paths in the underlying service's .loc file that don't get updated after the rename. I've filed an issue with ESRI Canada.

DanielMcCullock2

That is fantastic to hear John. I am yet to play with composite locators, I hope you can get a resolution. Please let us know the outcome.

DanMcCoy1

After this we change the portal item IDs of the new service to match the old, remove the old service, then remove any new portal items that were generated in the process.
This means we only have a small outage on the service and are able to maintain the service name and portal item IDs.

@DanielMcCullock2 , what method do you use for changing the Portal item ID? AGO Assistant?

Thanks,

Dan

DanielMcCullock2

Hi Dan,

We make the changes via the server admin endpoint.

If you click on the services you are working with and scroll down you will see the "Portal Properties" for the service.

If you scroll to the bottom of the page you will be able to select the "edit" operation which will allow you to modify the json for the service. Something I have discovered recently is that for non hosted MapServers/FeatureServers, if the portal items are set to "derived" then the derived attribute should be removed. This may also be true for hosted but I have not tested.

Let me know if you need any further clarification 🙂

Danny

DanMcCoy1

Ah, thanks. Didn't realize you could do that from that endpoint. I haven't found any documentation about it. I wonder to what degree changing an items ID this way is supported by ESRI....?

It actually changes the ID of the Map Image Layer item in Portal that's associated with the map service?

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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