Latest Contributions by JonathanQuinn

I was able to reproduce significant slow-down in the backup of the object store: Created 20GB of data in the tile cache data store at 11.3 Created a backup, which took 22 minutes or so Upgraded to 11.4 Migrating the data to the object store Created a backup and it took 3.5 hours I did notice that Windows anti-virus was certainly busy; there are many more individual files that are copied, but I created an internal issue to investigate. If you want something to track, reach out to Support to log a bug. ... View more

Once migrated, can you check the size of the object store folder (for example C:\arcgisdatastore\ozonedata); is it also 29GB? When you are waiting for the backup to be created, can you check whether the size of the temporary folder for the object store backup is growing in size, and how fast? It'll be a path under your SHARED_LOCATION path, with a guid. You'll need to look in each folder with the guid to see if its the relational or object store backup. ... View more

You may be running into BUG-000150335 The restore of federated servers with additional server functions may fail while the hosting server is being restored, which is fixed at 11.0. The restore of all federated servers, including the hosting server, start at the same time. However, there are internal operations that are called during restores, and those operations depend on the hosting server, (i.e. adding to trusted server lists, managing relational drivers, etc). If the hosting server is being restored and is unavailable, those internal operations may fail resulting in obscure errors. You may be running into that.   As for the hostname thing, the external/public URLs do have to be the same. If you take a backup from https://enterprise.domain.com/portal you have to restore to https://enterprise.domain.com/portal, but the internal machine names can be different. This has been the case since 10.5.1. https://enterprise.arcgis.com/en/portal/latest/administer/linux/overview-disaster-recovery-replication.htm#:~:text=Must%20this%20item%20or%20setting%20be%20identical%20across%20deployments%20when%20running%20the%20WebGISDR%20utility%3F   ... View more

This has come up every so often and it isn't as straightforward as: Create an environment using credentials A Create a backup Re-create the environment using credentials B Restore the backup We've tested that many times internally without a problem. Ultimately, the database credentials, which initially match the initial administrator account used to create the site, in the backup doesn't need to be the same as the database credentials in the target site. There does seem to be steps that would cause a problem if they're not the same, which is a bug that needs to be identified. However, the credentials used in the DR tool should be the same, which is what Account credentials for the ...webgisdr.properties file refers to. At the end of the restore, the DR tool will generate a new token to validate federated servers. The only credentials the DR tool knows about are the ones in the properties file. If you have credentials A in the backup but used credentials B in the target site, the restore should succeed without running into a problem with the database credentials, but a token can't be generated because credentials B (as a portal user) don't exist anymore. Creating the token will fail and validating federated servers will fail, but the rest of the restore will have completed. If there are steps you recall related to updating the database credentials using the Portal Administrator Directory, that'd be helpful to know why the restore is failing for you. ... View more

Esri Support is correct; the problem is that each site has a unique key which is used to decrypt tokens. A token generated and encrypted on site a can't be decrypted by site b. Sticky sessions can work at the LB, although you won't get the benefit of round-robin requests to each machine for redundancy/horizontal scaling. A multi-machine server site will also work, but you need a shared location for the config-store and directories. This introduces a single point of failure but eliminates some hurdles regarding publishig and synchronizing services between the sites, because both machines are part of the same site. We have documentation on active/active siloed environments, and describe what to do for tokens here which you can follow if you still want an active/active configuration. Note that this can't be federated to Portal for ArcGIS. ... View more

The cleanup should be automated by ArcGIS Server; if any of the internal processes create files/data in the TEMP directory, that process should be responsible for cleaning it up. If you find that files are accumulating, I'd suggest using ProcMon to filter for "process name is ArcSoc" or "process name is javaw.exe" and "path contains TEMP", which will record who creates files in that directory and when. Then, contact Support to ask them to investigate.  ... View more

Connection refused means the web server is not started. You can check the Task Manager to see whether the javaw.exe process is started. If you have multiple components on that machine, you may need to enable the Command Line column so you can see the path to the process to make sure it points to the Portal install directory. If the web server is not starting, you'll need to look at the web server logs under framework\runtime\tomcat\logs. You may also need to look at the service logs under framework\service\logs, as there's some initialization logic where if step 3 out of step 1-10 fails, and step 10 is starting the web server, it'll never make it there. ... View more

<Msg time="2024-04-10T08:06:25,166" type="WARNING" code="216028" source="Portal" process="4127" thread="1" methodName="" machine="EIP-ESRI" user="" elapsed="" requestID="">HA_MASTER_NODE_DOWN eip-esrieip-esri-ha</Msg> This message means that the standby has started up, but the primary machine is not accessible. Since the standby can't get the most up to date data from the primary, it won't promote itself to primary. You'll need to stop the standby, start primary, and troubleshoot why it's not healthy before starting standby. ... View more

This is also described in the Ports required by Portal for ArcGIS section of the help: https://enterprise.arcgis.com/en/portal/latest/install/windows/ports-used-by-portal-for-arcgis.htm#:~:text=customize%20these%20ranges.-,Highly%20available%20portals,-If%20you%20have ... View more

There is no requirement that the credentials for each component are different. In fact, we don't store the credentials used in federation in Portal, otherwise organizations wouldn't be able to take advantage of best practices for security and either disable the account or update the credentials at a regular cadence. If your security posture is that Server and Portal either don't use the same credentials, or you'd need to update them, and are finding that it breaks other workflows, then Support Services should take a look. ... View more

This is achieved using the DR tool and geographic redundancy: https://enterprise.arcgis.com/en/portal/latest/administer/windows/overview-disaster-recovery-replication.htm The blog below covers some additional information related to hostname resolution when setting up a new, replicated environment in the context of migrating, not geographic redundancy, but the concepts still apply: https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two/ ... View more

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. ... View more

This is likely an issue with the properties.json file under content\items\portal\properties.json. Can you check if that's blank? If it is and you have a WebGIS DR tool backup, you can extra the webgissite file, then the portalsite file, and copy the properties.json file from the backup into the path above. ... View more