Latest Contributions by JonathanQuinn

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

You aren't wrong; you can't restore a single component using the DR tool. If you need to restore a single component, then you can extract the backup using 7zip or another compression utility and use the APIs as noted by @Scott_Tansley. Note that for the Server restore, there are two "branches" of the restore; one for the DR tool that honors target properties/configurations, and one that called by just running importSite, which uses the properties/configurations in the incoming backup. The difference is why you see your target environment use the source environment directories. Two approaches: 1. Restore using importSite and then update directories and re-register additional machines (if applicable), as the restore using just the importSite branch will remove all but one machine. 2. Restore programmatically and pass in the "mode":"dr" property into the importSite operation. This is what the DR tool does to achieve a "data only" restore, vs "data and settings". I'm curious though, can you describe how long each component takes to restore, and how much data you have in each? ... 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

Yikes, definitely a bug, thanks for the update. If you can, get in touch with Support Services to log a bug. ... View more

I wouldn't expect a certificate problem to impact specifically Manager access; are you able to publish hosted services? If you look at the web traffic when accessing Server Manager, do you see an error similar to "Cannot generate a token for this server"? ... View more