Latest Contributions by JonathanQuinn

I can repro this behavior; I suggest you reach out to Support to get this tested and logged. Server should only need to depend on the X-Forwarded-Host header, as documented in the help. ... View more

There are a variety of different deployment scenarios for an HA portal. The WebContextURL will always be set to 443, but the privatePortalURL can be set to either 443 or 7443, or any other port, in reality. All that matters is that it can send traffic to the backend portal machines, and check the health of those machines. Our cloudformation templates set the WebContextURL and the privatePortalURL to the same URLs. On the other hand, if you configure your environment with Windows Authentication, that would be set at the web adaptor tier. In this case, the privatePortalURL can't be set to a URL that hits the web adaptors, because it can't authentication against the 401 challenge. Deployment scenarios for a highly available ArcGIS Enterprise—Portal for ArcGIS (10.8) | Documentation for ArcGIS Ente… Ultimately, your decision to use  the same URL or different URL can come down to: 1) Security - do you need to bypass the 401 challenge at the web tier 2) Network traffic - do you mind if internal traffic between Server and Portal goes through the same endpoint as client side traffic? There is no right answer. Your requirements will dictate what your topology looks like. ... View more

In that example, client side traffic (blue lines) goes from the LB to the web adaptors and then to the portals. You'd want a health check from the LB to the web adaptors as well because that checks two things: 1) whether the web server is up and running 2) whether the web adaptor can communicate with the portal. For the internal traffic, (yellow lines), you'd also want a health check to make sure that the backend portal machines are healthy for the communication between federated servers and portal. ... View more

If you get around to setting up a new machine and it happens again, feel free to reply back with a screenshot or example of the hostname of the machine, the URL you used to register the WA, and network traffic using the dev tools or Fiddler showing the redirect. Are you using the default hostname of the AMI, or assigning the AMI a new hostname? ... View more

I think you need to determine definitely what happens to the postgres processes during a restore. At a very high level, it's: 1) Stop the database 2) Backup the content and database to a temporary location 3) Import the content 4) Restore the database 3 and 4 may be out of order, but that's the general idea. If the database fails to stop on step 1, then nothing else will work. What I suggest is ensure that the standby portal is in a working state, take a backup of Portal directly in Portaladmin, and try to restore it. The DR tool isn't doing anything different than that, so it should help to isolate your testing. Once you restore, watch the processes on the portal machine, and you should see the postgres.exe processes go away. You may also want to run ProcMon with a filter on the C:\arcgisportal directory so you can see what is going on on the file system when restoring. You can set a filter for "path starts with C:\arcgisportal\db" which should capture anythiing within C:\arcgisportal\db as well as the backup folder, ex. C:\arcgisportal\dbXXXX. ProcMon will help log what the issue was when Portal tried to rename C:\arcgisportal\db to C:\arcgisportal\dbXXXX. You may see access denied or some other error, which will help you identify what the problem was. ... View more

Can you describe what you mean by "doesn't work"? You mentioned that you couldn't reach the portal; is it a connection refused type error, indicating that the URL has no path to resolve to? Can you provide and example of the web context URL you're using, and a description of your network architecture, (for example, reverse proxy -> web adaptors > portal, or something similar). ... View more

If you go to https://portal.domain.com:7443/arcgis/portaladmin/system/webadaptors, click on the web adaptor that's listed there, and then look at the URL property, are you using that URL to access Portal? Portal only knows about that URL. If you access Portal via a CNAME that is different than the URL listed there, then it will redirect. You'll need to either set the Web Context URL to your alias or access the web adaptor registration page over the URL you want to access portal with. ... View more

I'm glad the hostname theory has some substance to it. I'd suggest making sure the analyst tests it and logs a bug if they can reproduce it. The "failed to delete the db directory" error is a bit misleading. When we restore portal, we want to backup your data so we can roll back if there was an issue. The db folder will be renamed to dbXXXX and the db folder in the backup put in the same folder. We can only rename the db directory if the database is shut down. I'm not sure what you've done since the error was thrown, (restarted the portal, etc), but the next time it happens, check to see if there are any postgres.exe processes running, and the see when the PID associated with those PG processes was created under framework\etc\pids. If the time modified value of the PID file associated with the PG process is before the time you attempted to restore, then the database wasn't shut down correctly. If the database is still running, then you can't rename the db folder. It appears this type of failure causes the rollback logic to fail, potentially because the database is still running. To get the site back to a working state, you can copy the .config-store-connection.json file from the db directory into framework\etc without the leading period. Portal should start working after that. Check the log files for a message indicating that the database was found to be stopped, and portal is restarting it. That'd be an indication that portal did stop the database, but a timing issue with our internal process checks re-started the database during the restore. ... View more

If processes don't start, it could either be a problem with that process, or something with the processes that starts those processes. When the Portal Windows service starts, the ArcGISPortal.exe process starts first. There is logic within that process to check whether the java.exe, postgres.exe, and javaw.exe processes are started. If they're not, it'll start them. Does the RAM usage of the ArcGISPortal.exe climb to more than 100 MB? If not, then that's a problem. You can look at the service logs under framework\etc\service to see if errors are written to the logs there. ... View more

Portal rarely does much work, it usually passes off that responsibility to the hosting server or other federated servers. Any of those long-running processes are typically GP tool, so they're running on the Server. ... View more

Collector is probably looking at the body of the request, and the body contains the URL to download whatever it needs. If specific workflows are the only ones causing a problem and the rest of the workflows work as expected, then it looks like it could be a bug with those tools and utilities. I'd suggest reaching out to Support and have them test to see if they can repro. ... View more

Can you describe what you mean by "installing the web adaptor without using the installer"? The supported way of installing the Web Adaptor is documented in the install guide for the Web Adaptor. Any other way is not tested and unsupported. ... View more

It's slow packaging to any share. I think it's due to the underlying mechanism we use to zip files and we're investigating other ways of zipping. ... View more

Did you import your own certificate to use for port 6443? If so, can you describe how the certificate was created, (CN, who it's signed by, etc). ... View more

Is that the equivalent of standard or premium shares? Planning for an Azure Files deployment | Microsoft Docs  Packaging a backup over a share is definitely an issue right now. You can package locally and then copy to wherever it needs to be stored and see if that's faster. ... View more