Change Hosted Feature Service URL on Portal

[JustinGreco]

I have published all my services prior to adding a load balancer and have noticed that the URL for the service on the Portal item still references the non-load balanced URL.  I though setting the WebContextURL on the Portal and the Server to the load balanced URL would resolve that.  I would like to avoid having to republish everything after setting up the load balancer, since the load balanced URL is already being used for our existing production.  I have attempted changing it using the Python API, but get an error saying the URL cannot be edited, only thing that works is changing it from http to https.  I was hoping that the URLs in the items would be relative, but it looks like they are not.

[JonathanQuinn]

Unfortunately there's no way to update the URL's within a deployment.  We expect to support that in later versions of the software, though.

[JamesOsundwa]

Hi Jonathan Quinn‌, is this still the case..? And is there any recommended workflow for migrating, say 1,000, hosted feature layers from one server to another..?

[JonathanQuinn]

Yes, this is still the case for now. You can use the Python API to download or extract the data/shapefile/zipped file geodatabase/SD file, (however you published it), from Portal and then upload it to your new server. The extract options would capture any new/updated/deleted data that has been created once the service is published, but the original item that created the service would contain the original data.

Can you describe your use case for migrating the services? Are you attempting to migrate machines, but retain the original URL of the services, or are you looking to clone an existing deployment into another where the URLs of everything will change?

[JamesOsundwa]

Thanks for the insights.

Use case:

• I have a clean install of STG portal running 10.6 and a fully operational PROD instance running 10.3
• I'm migrating items, users, groups from PROD to STG and then intend to switch the STG into PROD
• I'm using https://developers.arcgis.com/python/sample-notebooks/clone-portal-users-groups-and-content/ 
• I migrated users, groups, and items, but noticed that feature layers did not copy (and item URLs did not update) 
• I'm keener on migrating the actual feature layers into the new instance than updating the url's, because if updated, these URLs will have to be changed back when this instance goes into production

James.

[JonathanQuinn]

Thanks for the detailed information. We're working on capturing user requirements for migration/cloning workflows.

Have you looked into collaboration? That packages up the data and service as a by-value copy, so you can move it over to another system, such as ArcGIS Online, another production Enterprise deployment, or even down to a staging environment.

[JamesOsundwa]

Collaboration would have been a great option, but the source portal is on 10.3 therefore not supported. I'm looking into your initial suggestion of using the Python API and then figure out how to publish it into the target portal; will let you know how that goes.

[AhmadAwada1]

Hi jonathan,

u r saying there is no way to update the services url in a federated portal. Like if you relocate the web adaptor for the services to a new server, you will not be able to tell portal about that new location without unfederate and refederate, no? If that is the case what is the and best option to reflect a web adaptor change for arcgis server? Can’t this be edited from admin or portal directory and then use the python update service and webmap urls to reflect the new services url? Something else, can we change the url for the item using python update service url everytime we publish a service to portal? What is the effect of having items service urls updated while the services url for the portal to server federation is kept pointing to undesired location? Would that be considered a workaround? If yes, any impact other than repeating the update on every service published?

willing to hear from you for this critical situation.

thanks

[JonathanQuinn]

Yes, that's correct. The URL for hosted services can't be updated at this time.You can loop through all content and update the URL to non-hosted services, though. You can also loop through your content to find webmaps and update the operational/basemap layers to point to the new URL.You  can update the services URL of the federated Server through the Sharing API we well, but you'll likely need to republish hosted services.

[EricJackson1]

We actually went through this process and found that it can be done but I'm not sure I would recommend it.  Our Portal is in a "lite-production" phase so there isn't a lot of content but we had enough that I wanted to try this route.  We used scripts to update non-hosted service URLs and web map layer URLs, but for some reason we missed some content and I ended up using ago-assistant to fix those manually.  We also had a few hosted feature services that will need to be recreated and related/dependent content updated. 

The one unexpected issue was related to Insights.  Insights stores all its pages and workbooks in Hosted WorkSpaces.  Fortunately, all of our Insights work has been test related so it was acceptable to let those go.  I also found that I couldn't delete any orphaned Insights WorkSpaces in the Federated Server's Home > services > Hosted Admin page (I could do this for Hosted Feature Services).  I received a: 'Failed to create data source ''/enterpriseDatabases/AGSDataStore_ds_w7oh234m'''  message and the WorkSpace remains listed in the Hosted Folder.  This may be related to the fact that we also reinstalled DataStore (long story). However we were able to delete the broken Feature Services that had pointed to the prior instance of DataStore. For now I'll just ignore them. 

It was also necessary to update the serverURL in <configstore>\security\security-config.json.  That file retained the prior web adapter URL. Without this change Insights wouldn't work properly.  I'm hoping this change wont have repercussions.