Issue restoring Enterprise backup using webgisdr tool

1290
6
02-13-2018 01:42 PM
City_ofJohns_Creek_GIS
New Contributor II

I'm trying to migrate my existing single-machine, Enterprise 10.5 stack from one physical machine to a new virtual machine.  In order to accomplish this, I built out a duplicate of my existing Enterprise software stack on the new, virtual machine and am trying to use the webgisdr utility to backup the existing system and restore it to the new one.  I can back up the system perfectly fine... but when it comes to restoring it to the new system, I get an error and the process fails.

The error I'm getting is that the process failed when requesting https://machine-name.domain.gov/arcgis/rest/info?&f=json

This failure makes sense because the Server component of the import isn't using the standard "arcgis" web adaptor and is instead using a custom one that we specified long ago.  Portal is using the arcgis web adaptor.

Question:  Is there a way to specify in the "toimport.properties" file what web adaptor to use for Server vs. Portal?  Is this really where my error is occurring or am I just not seeing the bigger picture?

0 Kudos
6 Replies
JonathanQuinn
Esri Frequent Contributor

The front-end URL's for your Portal and the services URL for the federated/hosting server has to match between where you took the backup and where you apply the backup. Do they match or are they different between the deployments? The DR tool isn't necessarily for migration, but it will work as long as the URLs mentioned above are the same.

0 Kudos
City_ofJohns_Creek_GIS
New Contributor II

Hi Jonathan,

The URLs are the same between both systems... the ArcGIS server has "jcgis" as the web adaptor name and Portal has "arcgis".  The only things that are different are the machine name between the two and that the current production system is accessed by users through a subdomain that we set in DNS (the new system will replace the old in DNS).

Is there a better way to migrate the system than the webgisdr tool?

Thanks,

Nick

0 Kudos
JonathanQuinn
Esri Frequent Contributor

Can you post a screenshot of the error you get? If you were to run webgisdr.bat -c -f webgisdr.properties to get the configuration of the deployment, does everything look correct?

The DR tool will simply check the federated servers of the site associated with the PORTAL_ADMIN_URL value via Portaladmin, so I can't see how it's picking up an incorrect URL for the services URL.

The DR tool can be used for this "full" migration workflow, but another approach is to create multi-machine sites/HA sites out of all of the components, and then remove the old machines. For example:

1) Move the config-store and directories for the Server to a shared location

2) Join the new machine

3) Remove the old machine from the site

4) Update the paths to the config-store and directories if necessary

5) Update the admin URL for the federated Server within the Sharing API

You can do the same thing for the Portal and Data Store.  Create an HA Portal and HA Data Store and remove the old machines.

This is more of a "piecemeal" approach.

0 Kudos
City_ofJohns_Creek_GIS
New Contributor II

When I run the command you suggested against the input properties file that I used to create the backup, all of the URLs are correct.

The error message I get when I try to restore the backup says:

Failed for the request https://machine.domain.gov/arcgis/rest/info?&f=json

Stopping the webgisdr utility.

*Note: I'm keeping the machine name details out of this so that our IT guys don't strangle me...

If I take that same URL that it's referencing and drop our Server web adaptor name in it in place of "arcgis", the URL resolves.  Maybe the original configuration of the Enterprise was messed up and I just never knew it?

Very odd situation... 

0 Kudos
City_ofJohns_Creek_GIS
New Contributor II

Posting this in case someone else has the idea to do this too:

After some discussion with Support (which echoed Jonathan's idea), I came to the conclusion that it's probably best to just create a new Enterprise from scratch and manually republish services.  This is the least risky path forward for us.

0 Kudos
Luiz_AmadeuCoutinho
Occasional Contributor III

We had a similar problem here. On 10.4.1 version.

The solution was the same . A new machine and install 10.6 and publish again the services :(

0 Kudos