Migrating ArcGIS Enterprise to new machines

Owned by Josh Hevenor (Unlicensed)
Last updated: Nov 25, 2019
2 min read

There are few methods to migrate an instance of ArcGIS Enterprise to new machines. Our specific goal will be to migrate to a new instance of eGIS hosted in a difference cloud subscription, resource group, and VNET .

Join Site

If you want or need to replace a machine in your deployment without losing content or interrupting service, you can use the Join Site operation to migrate machines running ArcGIS Server and Portal for ArcGIS, and a similar workflow can be used for machines running ArcGIS Data Store.

https://enterprise.arcgis.com/en/portal/latest/administer/windows/migrate-to-new-machines.htm

 

This would be an appropriate way to replace single components of an ArcGIS Enterprise instance. For example, updating a VM from window server 2018 to windows server 2012. The process is to add a second machine in the same role as if configuring a multi-machine deployment, waiting for the content to be cloned to the new second machine, then removing this first.

In our context, we’ll need to join a site in a different VNET, so no internal URLs will work. While we can reference Azure Files for shared directories, both the portal and data store instructions reference using the internal admin URLs.

Feasibility: unlikely

WebGIS DR tool

There are two methods references which make use of the WebGIS DR tool, but both are essentially a backup and restore.

A safer, yet slightly more involved workflow to migrate to new machines is to use the WebGIS DR Utility, which is included with the install of Portal. The utility serves two main purposes:

- create backups of your deployment and restore them in the event of a failure

- maintain a replicated standby environment for disaster recovery

https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two/

This process involves creating a second empty site which is identical to the first. It uses HOSTS files (or DNS split horizons) to ensure that both instances assume that they are target.domain.com. Once the second site is created, a backup from the original instance is restored to the new destination. If the restore was successfull, then the public DNS can be updated to point to the new instance. The internal DNS solution (hosts files, etc), and already used in our deployment and so can stay.

This process can be used to maintain a hot spare DR instance by scheduling frequent backup tasks on the main instance, and restore tasks on the DR instance (although how changes are propagates back to the main instance is unclear).

Feasibility: likely

Migrating GeoEvent Server

todo

Changing URL

We’ll need to update from egis-sige.tcgis.ca to egis-sige.tc.gc.ca at some point.

Find ESRI documentation for changing the DNS/URL

Some basic attempts to change the webcontexturl were insufficient.

Related ESRI GeoNet post: https://community.esri.com/message/789278-re-changing-arcgis-portal-dns-alias-post-installation-?commentID=789278#comment-789278

A new post was made to GeoNet for advice: