Overwrite map service on Portal from Pro

[MarkCooper5]

We are trying to overwrite a map service that we have published from ArcGIS Pro (2.4) to our server (10.7.1) but the option to overwrite is not there. Having read the instructions at Overwrite a map service—ArcGIS Pro | ArcGIS Desktop , it specifically says:

"You can overwrite a map service that has been published to a stand-alone ArcGIS Server 10.6 or later." 

As this referes to a stand-alone server, and our server is feredated to our Portal, is this the reason the option does not appear?

If so does anyone know a way round this other than deleting and republishing the service? The two options I have thought are:

1. Publishing from ArcMap, which does allow the service to be overwritten - I would rather not go down this route as it will only push the problem down the line to when ArcMap is no longer an option!

2. Unfederating the server - I am aware this has implications and I may lose existing service (there are only 3 so its not an issue!). I have done this before and am thinking it may be the best option, unless anyone else can think of a better one.

Many thanks

[Arne_Gelfert]

Mark, what exactly do you mean by ...

"...he option to overwrite is not there..." ?

I'm assuming you're referring to 'OverWrite WebLayer" in the "Share As" pane? The only time I've seen it disabled or greyed out is when I'm not signed into Portal. But I've also run into issues with "OverWrite" not working when I'm trying to update (overwrite) a map services that was previously published through a script where I had specified a folder tor the Sd/Sddraft files, and then Pro has no idea where to find those. I don't know where Pro puts those files when publishing to AGS.

[DavidColey]

You definitely do not want to un-federate your site.  For us, pro puts everything in it's 'SharedProcesses' folder that is part of your desktop user profile, like:

C:\Users\username\AppData\Local\ESRI\ArcGISPro\Staging\SharingProcesses\0001

and in that directory you will see sdddraft, sharingInfo.json, etc etc.  All of that gets written to the

...\\directories\arcgissystem\arcgisinput\YourServerFolder\YourMapName.MapServer\extracted\p20

directory, for example

For me, I made sure I shared my profile path above with the arcgisserver domain account so that Pro would not have any issues writing from the SharingProcesses folder to the ...\arcgisinput\... folders.  Since I did that I haven't had any issues overwriting traditional map services to my federated site.

I don't know if named user vs concurent use licensing affects any of this. We use concurrent.

[Arne_Gelfert]

That's great info, David - thanks for sharing the path to "SharingProcesses" (no pun intended).

[DavidColey]

Yup thanks Arne, I mean I too needed to understand where everything was going to overcome exactly what Mark is going through now...

[MarkCooper5]

Hi

We did unfederate the server in the end (there was nothing in portal to be lost) as we needed to get stuff up and running quickly and the local distributor appeared to suggest that you could not overwrite map services in Pro!

Other than managing credentials (which with our AD was a real pain) and allowing analysis (which we dont need), I'm not sure what other benefits there are to federating. Am I missing something? We can always federate to our other server at some point if we need to.

[DavidColey]

Hi Mark, respectfully, the local distributor is wrong.  I overwrite them all the time.  For us, there are a lot of benefits.  For example, we use collaborations between agol and our enterprise and it just makes managing the sharing of image services and map services in those collaborations so much easier. 

We also get greater performance because we don't have a service authenticating in 2 places, once in server and then once again in portal, which is what happens if you then add a webserver url to your portal as an item from your stand-alone site. If the site is federated, then that's not an issue. 

As far as AD goes, I found it more difficult to register it Server than with Portal.  I think there are many more pluses than minuses on federated v stand-alone. . . .

[DanDeegan]

In the distributors defense, overwriting a map image service in Pro does not seem to be supported without a few workarounds.  

Is this thread different that what is mentioned here ? https://community.esri.com/ideas/13126 

[DavidColey]

Well, what I would say is that you do need to make sure your directory locations, shares and service accounts being used are registered correctly with the server. But I needed to do that with ArcMap too so I didn't really think of that as a workaround, per say.  Just that everything has the proper permissions set in portal, if federated.  That's one thing I think made it easier with the federation is that I no longer have to worry about - Server accounts and Server roles . . . 

I see on that thread others are having trouble, but we are not.  I've moved all of my dynamic and tile cache map services to pro, and can overwrite, both from SDE and from file gdb sources.

[DanDeegan]

We have a lot of map image services that draw dynamically from our sde or another gdb. Some published from Pro, the other from ArcMap. 

I went looking for something like irectories\arcgissystem\arcgisinput\YourServerFolder\YourMapName.MapServer\extracted\

And I can only find one folder at the \YourMapName level. 

We can't over write map image services in Pro.