I recently updated Portal for ArcGIS to Version 10.6.1. Since then, I can no longer connect to my portal (over HTTPS) from ArcGIS Pro (Version 2.2.4), even though the portal is shown as "Available". The portal seems to be working as expected and, using the same account, I can connect from other Esri applications over HTTPS (e.g., ArcGIS Server 10.6.1, Survey123, Workforce).
Any help would be greatly appreciated.
Can either of you share your Enterprise configuration and or Authentications (Built-In, IWA, SAML)?
Also the error that you are both encountering? I suspect it would be different depending on the types authentication you are using. Is License Manager involved here? if so, what version and does this work out of your current machine you are attempting to log into?
1. Delete the Enterprise Portal connection and Re-create it again, just like in ArcMap.
2. Use Portal Initial Admin account and create a connection using the port instead of the DNS or NLB (network load ballancer, if any) example: https://FQDN:7443/arcgis
3. Use a free tool like Fiddler is a free tool that is good for capturing inbound and outbound web traffic to see what kind of error codes might be returned when the client is making the request to the server. This would at least help you narrow down what might be causing the issue.
Also reach out to Technical Support for additional assistance.
Hi Harrold Sompotan
Thanks for you getting back.
I have a ticket open with support and we've been working on this.
Regarding your queries:
I've use Fiddler to troubleshoot and and what pop's out is that it looks that, for some reason ArcGIS Pro is trying to connect to the Portal using the https://<mymachine>.<mydomain>:7443 instead of using https://<mymachine>.<mydomain>/portal, and by using this it cannot log in.
I believe that in this case, the main question is why is ArcGIS Pro having that behaviour? Is it a network issue? A certificates issue? And that's what we've been trying to understand.
Thank you for your time and...
… HAPPY NEW YEAR!
Was digging around internally and found one other rare case where they had multiple domains involved.
But if you are accessing Pro from the same Enterprise based deployment (Enterprise portal) then this shouldn't be the issue. I believe we might have a Web Adaptor or Portal configuration issue here just because of the redirect issue you mentioned previously.
1. On the same machine as the Enterprise portal and ArcGIS Pro, can you go to your Internet Explorer, open the portal home page ie https://domain.com/portal and this should automatically log you in, as your AD (active directory account) since you have IWA configured, once logged in, Open ArcGIS Pro and see if you are still presented the same issue (assuming that the "Active Portal connection" is still set to https://domain.com/portal, or are you prompted for a login?
2. On your Web Adaptor IIS, can you temporarily set the Anonymous Authentication to enabled while having Windows Authentication enabled as well. (again I know this not standard practice, just wanted to rule out something here) if this does nothing, then set it back accordingly.
-Do you have a Web Context URL set for portal? if so, is it the DNS name?
-Do you have ArcGIS Solution Deployment add-in installed?
-Any Proxy involved here?
Setting the Web Context Url cured the issue for me when trying to sign into a Portal 10.7.1 instance on an Azure VM. ArcGIS Pro would sign in from the installation on the server through an RDP session. And sign in to Portal was successful externally through the web browser.
It was only ArcGIS Pro externally that would attempt to sign in to Portal using the internal server name (which could not be resolved on internet obviously). Fiddler showed this.
There was no reverse proxy or network load balancer in play, but all the DNS translation seems to have made the WebContextUrl setting necessary for Pro.
Sorry for the long silence.
Setting the WebContextUrl solved the problem.
Still quite difficult for me to understand where the real problem was, I have some clues but I cannot be 100% sure.
Thanks for all the suggestions.
Not a problem. Glad that worked for you.
If you or Jim Somerville dont mind answering back here. I'm curious to know, was the Web Content URL ever set prior to upgrading to this version? Thanks again.
This was also a new installation. The only thing is that we did some tests with a reverse proxy that where rolled back. Probably there was still some "ghosts" from this tests that were not properly cleared by IT.