I tried to open the arcgis portal page. it's a blank page nothing is shown on the page and i unable to login to the portal admin page . it is always showing unauthorized.
I recently upgraded to ArcGIS Enterprose 10.7 and it was working fine. suddenly stop working. Please help me
I expect that if you go to https://portal.domain.com:7443/arcgis/sharing/rest, the page is returning a 404. The only thing I can suggest is restart the Portal service and see if that fixes it. Is the environment in AWS using content in S3? Unfortunately, these types of problems are tricky to solve and it's best to contact Support Services.
Replying to this 2+ year old thread because we're seeing similar behavior in our current 10.8.1 Enterprise HA deployment. We're running Windows Server 2019 in Azure and are distributed across multiple VMs including 2 for Portal, 2 for Data Store, 2 for Hosting Server, etc. We shut down these VMs every evening and start them via script every morning. The issue we're seeing is that after everything boots up, we get a blank page for the the Portal Home, and get a "not authorized" message when we try to hit the Portal Admin page. At the same time, both of the Health Check URLs for the Portal (1 each on the 2 servers) report that the Portal is Ready. So our load balancer thinks nothing is wrong, but the Portal is completely inaccessible. We have found that we can restore full functionality by simply stopping the Portal for ArcGIS Service on the secondary Portal VM. As soon as all of the processes are spun down, the Portal starts working normally (both Home and Portal Admin). As expected, our load balancer then sees that the Secondary Portal VM is down and quits routing traffic to it. We can then start the Portal for ArcGIS service back up on the secondary Portal, and it comes up fine, and everything still works until the next morning when we find it in the same "state" after the VMs boot.
We currently have to do this "fix" every morning where we stop and start the Portal service on the secondary Portal to get Portal functional. This is obviously not sustainable, and we're hoping to get to the root of the problem.
We have tried staggering the automated boot time of the servers, but still see the issue. We're currently starting all of the Primaries at the same time (Portal, Data Store, Hosting Server), waiting 5 minutes, then start the standby Data Store and secondary Hosting Server, then finally starting the secondary Portal 5 minutes after that. Even with this sequence, we still get an inaccessible Portal that requires a manual stop / start of the Portal service on the secondary Portal to get everything working properly.
The logs have not been particularly helpful - we do see indications that the Portal is not able to generate tokens while in this state:
Primary Portal log message (WARNING) looks like this:
"Failed to generate a token for user 'xxxxxxx'. The server at 'https://xxxxxx:7443/arcgis/sharing/generateToken' returned an error. Internal Server Error"
Secondary Portal log message (WARNING) looks like this:
"Failed to generate a token for user 'xxxxxx'. java.lang.Exception: Server returned HTTP status code 404. Requested URL: https://xxxxxx:7443/arcgis/sharing/generateToken"
Again, while in this state, both the Primary and Secondary health check pages report that "the portal is ready", even though nothing comes up. So it feels like maybe this has something to do with the token generation (since the health check doesn't require a token?).
@JonathanQuinn - have you seen this behavior before? Any guidance would be greatly appreciated, and we'll be sure to post any resolution here.
It sounds like you're running into
BUG-000134458 - In some environments, the standby portal does not rejoin successfully after shutting down
We've addressed this in a patch:
I assume the patch is not installed because part of the changes in the patch improve how the healthCheck handles the Sharing API not initializing. If it's returning a 404, the healthCheck would return false instead of true.
I can confirm that the Patch referenced by @JonathanQuinn did indeed fix this problem. Out Portal machines have been booting into the expected (working!) state since applying the patch a week ago. Big thanks for the response and fix!