Migrating 12.0 local dirs to cloud native in Azure

Question

Hi there,

I have a multi site deployment of ArcGIS Enterprise 12.0 that was configured to use local directories. I was looking to migrate to a cloud native deployment. I had been under the impression that we could do this with webgisdr. I deployed a second environment with PSDSC using cloud native for the ArcGIS server sites (cosmos db, service bus and blob storage). I followed the discussion here https://enterprise.arcgis.com/en/portal/latest/administer/windows/overview-backup-restore-web-gis.htm with regards to what must be the same between environments. Once I had my vanilla cloud native deployment up I ran a webgisdr import with the latest backup from the old local directory deployment. The ArcGIS Server restores failed spectacularly - webgisdr overwrote the config-store and system directories settings and effectively disconnected the ArcGIS Server sites from comos db. It either inserted local paths from the old environment or paths pointing to the unzipped webgisdr backup with a new c:\cloudStores directory. This rendered the deployment inoperable. I have used webgisdr many times in the past and have not seen it try to update core settings like this. I'm assuming that it doesn't know how to restore a file based deployment to a cloud native one? Is there any other migration path?

Thanks

EDIT: I tested at 12.1 as well to see if the behaviour is different. It also completely fails on the restore of the arcgis server site.

For context if rewrites the directories to the location of the unzipped restore file like:

{
      "name": "arcgisinput",
      "physicalPath": "C:\Users\svc_arcgis\AppData\Local\Temp\tmp-ags-site-105536866145160388036857442017100\directories\\arcgissystem\arcgisinput",
      "directoryType": "INPUT",
      "cleanupMode": "NONE",
      "maxFileAge": 0,
      "description": "Stores source files (such as maps and data) for services that you publish.",
      "useLocalDir": "false",
      "localDirectoryPath": "",
      "virtualPath": "/rest/directories/services/arcgisinput"
    },

We then get 2 log entries

Incoming site configurations copied to location: 'AccountEndpoint=https://xyzxy.documents.azure.com:443/;databaseId=arcgis-data;AccountKey=xyzxy;DefaultEndpointsProtocol=https;NAMESPACE=xyzxy;cosmosDBConnectionMode=Gateway;'.

followed immediately by

Import operation failed and an attempt to rollback the site to its original state also failed. The site may be functional but it is recommended that you unregister all machines in the site and create a new site based off the configuration store that was backed up at 'C:\Users\svc_arcgis\AppData\Local\Temp	mp-ags-site-105536866145160388036857442017100\config-store' and the server directories backed up at 'C:\Users\svc_arcgis\AppData\Local\Temp	mp-ags-site-105536866145160388036857442017100\directories'.

so it looks like the webgisdr only supports like for like backup / restores?

Looking at https://doc.esri.com/en/arcgis-enterprise/latest/plan/overview-disaster-recovery-replication.html?pivots=os-windows#E2F

it does say

"To ensure effective disaster recovery for a replicated ArcGIS Enterprise, the standby environment must duplicate the range of system settings, security configurations, and storage locations found in the primary environment"

so I'm assuming I'm hitting the storage locations bit.

Note that in the Settings that must match between environments section it only says this:

* Version of Portal for ArcGIS and federated server sites
* Organization URL and federated server site service URLs
* Registered data stores
* The registered ArcGIS Data Store should match what is included in the backup. For example, if the relational and object stores are included, those should also be registered in the target environment.
* User managed data stores will be overwritten in the target environment from the backup, so they should be accessible from both deployments. See Data dependencies when restoring for more information.
* Administrator account credentials for the webgisdr.properties file
* Portal content directory location type (file system, Microsoft Azure Storage, Amazon S3)

nothing around ArcGIS Server config-store or directories needing to match (my portal content directory did but I never got as far as portal restoring fails well before that.)

I had been told that webgisdr would be the mechanism to do this sort of migration but it appears it may not be supported?

Thanks

FraserHand · Answer

Hi Jon,

Thanks for the reply and detailed workflow. I tried at 12.1 with a single machine base deployment with local dirs going to a single machine cloud native base deployment and had the same failure. The relational ds is successful, starts on the first server site, 1 and 2 execute then it gets stuck on 3 and we end up at 5 - 4 isn't successful either. I didn't see anything in the logs around importsite - just the errors I posted - I had logging on verbose as well. I've taken a different approach of exporting the portal site and importing, redoing the federation and re publishing services from sds exported from the publishing tools on the old site. Bit of a workflow but seems to have gotten me were I needed to be. I tried the webgisdr a couple of times with the same result (broken deployment).

JonathanQuinn · Answer

Migrating portal content from the file system to cloud storage isn't supported at 12.0, but is at 12.1, so I would focus on version 12.1. With respect to the Server failure, there is rollback logic when restoring, for example: - Site directories are \machine\share or * Import site starts * Server copies the config-store and directories to the local file system under TEMP * Server imports the config-store and directories from the backup * If there's a failure, attempt to rollback TEMP config-store and directories to their original location (\machine\share or ) * If that also fails, continue to use the config-store and directories under TEMP If step 5 fails, I believe the exception returned is the one you see, but the original exception (step 4), is lost in the API response. The importSite exception should be in the logs, though. Looking ahead, we'll be looking into retries on step 5 to see if we can revert to the original settings in the event that importSite fails.