nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any Workarounds for WebGISDR Failure due to BUG-000160000

ryanuthoff

I am attempting to move our production environment to a new set of servers using WebGISDR. After two attempts, it fails for the same reason when restoring Portal: {"error":{"code":500,"details":null,"message":"This connection has been closed."}}

After some research, I found this bug: https://support.esri.com/en-us/bug/when-attempting-to-restore-a-portal-for-arcgis-backup-t-bug-000160000

While it's referencing the Portal importSite operation, I imagine that WebGISDR is probably performing the same operation where I'd encounter the same bug/error.

The bug says it was fixed in 11.1, but I was wondering if there are any workarounds for this? Are there any workarounds to fix this bug in 10.9.1?

Encuentra más publicaciones etiquetadas con

Accepted answers

JonathanQuinn

This will be addressed in the next 10.9.1 Security patch. I'm not sure when it will be released though.

All comments

Scott_Tansley

Can I ask if your new servers are totally isolated from the old servers? The new environment needs to exist in a totally partitioned/firewalled environment so there is no overlap between old and new. I've seen several people on the forums who hadn't realised that and were, in effect, restoring back to the old servers.

ryanuthoff

I'm following this guide: https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two/

They are brand new servers, but added an entry to the hosts file so our DNS alias resolves to the new machine with the web adaptors are installed. Also, I can confirm that the WebGISDR restores files from the backup on the new Data Store and Server machines (by looking at the files and config-store) and it started to restore it on the Portal machine, it just didn't finish.

Scott_Tansley

Yeah - that's not an approach that I'm familiar with. Under the Pros/Cons sections, it uses the word "isolate". I've always taken that as to perform a 'restore' within a VLAN or (otherwise) firewalled off environment. There used to be 'hooks' to server names as well as Alias names in there, that may no longer be the case, but for 'assurance' I'd be isolating the machines. This would remove my concern that the new machines are trying to communicate with the legacy machines.

I think my advice at this point would be to reach out to Esri support or professional services.

HenryLindemann

Hi @RyanUthoff, just make sure that your host file entries are on all your nodes, you can also export each component individually by using the API and datastore backup utility, this will give you more flexibility.

Your host file entries should also be first in the file e.g. IP old_site_dns_1 any_new_dns_2

Here is some links on the subject

Portal and Server
Export Site—ArcGIS REST APIs | ArcGIS Developers

ArcGIS Datastore

How To: Restore ArcGIS Data Store (esri.com)

Hope it helps

Regards
Henry

JonathanQuinn

This will be addressed in the next 10.9.1 Security patch. I'm not sure when it will be released though.

JonathanQuinn

Understanding how the DR tool is communicating with the deployment is important, and we can improve our documentation to highlight that. However, in this case, while there is a chance that requests may make it from the target site to the source site, there's no chance that the restore will be able to run. Once the new environment is set up, a unique key is generated to decrypt and encrypt tokens. Site A will use key 1 and site B will use key 2. A token created in site B will have been encrypted using key 2, and if that token is used in site A, it can't be decrypted using key 1. The first restore will always fail if requests were making their way to site A.

Aside from that, there's no real requirement that the target machines are in their own virtual network; typically that'll happen if you use the DR tool to support geographic redundancy, but in the case of migrating between newer hardware or operating system, that won't be the case or necessary.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.