Latest Contributions by JonathanQuinn

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 <some Azure Blob connection string> 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 <some Azure Blob connection string>) 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. ... View more

@NicolasGIS Can you attach a screenshot of the C:\Program Files\ArcGIS\Portal\framework\runtime\jre\bin folder? Can you also attach the C:\Program Files\ArcGIS\Portal\framework\service\logs\commons-daemon.<date>.log? ... View more

The initial administrator account credentials are used in two places; they're set as the admin user for the internal database and also for a portal user with the Administrator role. The restriction is actually in the database; it only accepts certain characters for the password. Once that's created, you are able to change the password to whatever you need to for the portal user. That doesn't change the password for the database user. The documentation can be updated to expand on the difference and information on changing the portal user password after. ... View more

Is a forward proxy configured for the machine? That may make it seem like the host where the request is made doesn't match the host where the  web adaptor is running when its on the same machine: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/configure-arcgis-web-adaptor-server.htm#:~:text=If%20the%20web%20server%20where%20you%20installed%20ArcGIS%20Web%20Adaptor%20is%20configured%20to%20use%20a%20forward%20proxy%2C%20disable%20it%20while%20registering%20the%20Web%20Adaptor.%20Otherwise%2C%20you%20will%20be%20unable%20to%20access%20the%20Web%20Adaptor%20configuration%20page. You may want to look into running the ping and tracert commands to see if things align network wise with respect to IPs returned. ... View more

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