Latest Contributions by ChristopherPawlyszyn

‎07-12-2021

Is the behavior present when initiating sign-in from the identity provider (button in AzureAD enterprise applications) or service provider (accessing sign-on page from Portal and being redirected to the IDP)? I haven't seen this particular behavior previously, but do remember there was some inconsistent information on an Azure tutorial for ArcGIS Online/Enterprise logins and the IDP-initiated sign-on endpoint.

‎06-30-2021

As @RyanUthoff suggested, the usual culprit for the disparity in behavior from Portal Home versus Portal Admin in terms of designating the hosting server is due to SSL certificate trust (or the lack thereof) on the Admin URL used to federate the site. This includes the circumstance where a wildcard certificate is to secure the Admin URL, in which case the root and intermediate certificates in the chain should be imported for each machine in the Portal site from Portal Admin. Federate an ArcGIS Server site with your portal—ArcGIS Server | Documentation for ArcGIS Enterprise https://enterprise.arcgis.com/en/server/10.8/deploy/windows/federate-an-arcgis-server-site-with-your-portal.htm Similar thread here: Hosting server grayed out unable to select Hosting... - Esri Community https://community.esri.com/t5/arcgis-enterprise-questions/hosting-server-grayed-out-unable-to-select-hosting-server/td-p/576673

‎06-30-2021

For a federated ArcGIS Server site, you should first generate a token for the associated Portal for ArcGIS user, then use that generated token to create a server token from the same endpoint (see reference below). I think @DavidPike is correct that you're trying to generate a token from Server using a GET request judging by the error, but taking into account the federation aspect means you shouldn't be using a token generated from the ArcGIS Server endpoint at all. /generateToken: Generate Token—ArcGIS REST API | ArcGIS Developers https://developers.arcgis.com/rest/users-groups-and-items/generate-token.htm

‎06-29-2021

The way I look at it is that the WebContextURL entry is the ultimate way of defining the public DNS alias and context for a site. It would override whatever URL was used during the web adaptor configuration. When you register a web adaptor, the URL you use to access the configuration page (for Portal for ArcGIS specifically) is inherited as the Portal's URL. This is great for internal environments when using an FQDN or A/CNAME record to access the machine hosting the web adaptor, but when you throw a reverse proxy in front of that machine then you are no longer able to use the correct URL to access the web adaptor configuration page (it'll warn the user to access the page from the machine hosting the web adaptor). This is where the WebContextURL comes in handy and should be set prior to the creation of any content or the federation of any sites. Setting the WebContextURL won't have any adverse effects on a site using a web adaptor, and is required when implementing multiple web adaptors since the same registration URL wouldn't be possible from two machines to keep the consistency of a single DNS for the site. If deciding to not utilize the web adaptors, it's important to keep the additional headers and rewrites in mind as well. See step 2: "Open the configuration page in a web browser using an HTTPS URL such as https://webadaptorhost.domain.com/webadaptorname/webadaptor. If a DNS alias will be used with the portal, the Web Adaptor should be configured over the DNS alias instead, using a URL such as https://<dnsalias.domain.com>/<webadaptorname>/webadaptor." From: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/configure-arcgis-web-adaptor-portal.htm

‎06-17-2021

First I would start by identifying whether those layers are hosted or the datasets were copied to the server during the publishing process. That will add some direction to where to look next. If hosted content is having an issue, try validating the relational data store from Server Manager and see if it's healthy; if the data was copied to the file system, making sure permissions are in-tact for the ArcGIS Server service account would be a useful approach. You also may be able to look at the service workspace for the affected services (if non-hosted) to determine where the data lives. Try clicking the database icon next to one of the affected services in Server Manager.

‎06-17-2021

When using named-user licensing, the Portal will redirect the client (ArcGIS Pro or Drone2Map in this case) to the license manager host defined in Portal Admin. From there, the normal licensing process kicks-in and you'll need to be able to connect to both the license manager daemon as well as the vendor daemon described in this doc. Configure ArcGIS License Manager to work through a firewall—License Manager Guide | Documentation https://desktop.arcgis.com/en/license-manager/latest/configure-the-arcgis-license-manager-to-work-through-a-firewall.htm

‎06-17-2021

The version of OpenJDK in the Linux release is the same as Windows, for version 10.9 this is 11.0.9.1.

‎06-14-2021

The log location(s) on a Linux machine will vary based on your installation location. If I remember correctly the Ubuntu AMIs place the installs on /arcgis and create a separate directory for the site configuration files. If you can access Server Admin using the credentials you specified in the stack formation, then you can find the current logging location for ArcGIS Server. In terms of the correct URL to access the Server Manager page, are you using the site domain that was defined in the stack parameters?

‎06-14-2021

That error message is usually due to an *.rlock or *.wlock imposed on the config-store and those files can become orphaned in certain scenarios. Through a support case an analyst should be able to work with you through safely removing the lock files after confirming the account permissions are correct on the share.

‎06-14-2021

In line with @JayantaPoddar's comment, for a federated ArcGIS Server site you'll need to access the Server Manager page using the Administrative URL defined during federation. This is due to how the OAuth2.0 authentication mechanism keeps tabs on the approved redirect URIs. Reference: "If you are connecting directly to ArcGIS Server, the URL is formatted https://gisserver.domain.com:6443/arcgis/manager. If the site includes multiple GIS servers, this will be the URL of the machine you specified for the Administration URL when federating your site. If you are connecting through ArcGIS Web Adaptor, you'll need to ensure administrative access is enabled on ArcGIS Web Adaptor. The URL you'll use to connect is formatted https://webadaptorhost.domain.com/webadaptorname/manager." From https://enterprise.arcgis.com/en/portal/latest/administer/linux/administer-a-federated-server.htm

‎06-11-2021

Another possibility may be that you haven't selected the option to include the access token in the header of the authentication request. I had the same issue on an ADFS 4.0 OpenID Connect configuration I was working on earlier in the week.

‎06-10-2021

That error message typically means that the scopes are not being released to the service provider. Depending on whether you've specified those scopes in the OIDC configuration for ArcGIS Online/Portal for ArcGIS, you may need to remove them and potentially add other scopes if your provider is not set to allow the listed scopes to the service provider for the registered application.

‎05-10-2021

The total connections are a limitation of the relational data store by default, without any regards to how many clients are connecting to the database. If you have a large number of hosted services with a high number of concurrent requests then this maximum can certainly be playing a role in the behavior and I think the error message you listed seems to be in-line with that theory.

‎05-10-2021

It may be useful to capture the API requests during the site configuration using a tool like Fiddler, this will pinpoint where the failure is occurring in the configuration steps and also get the full message from the 400 response. Let me know if you need more explicit instructions on how to do so.

‎05-07-2021

Have you checked the number of active connections to the relational datastore during these times? The Linux AMIs I use on Linux typically don't have any swap space defined within the OS and the error message seems to imply that you're hitting the 150 maximum connection threshold for the data store as opposed to an underlying memory/swap limitation. May be off the mark but certainly worth looking into; unless you are running out of available RAM on the instance during increased demand I wouldn't expect a swap partition to make that much of a difference. changedbproperties | ArcGIS Data Store command line utility reference

Online Status	Offline
Date Last Visited	‎12-20-2023 11:01 PM

My Ideas

Latest Contributions by ChristopherPawlyszyn

Re: SAML reply-url error after 10.9 upgrade

Re: Configure hosting server role on ArcGIS Enterprise Portal

Re: Token generation Error

Re: WebContextURL or Web Adapter

Re: Not Referenced Data on Portal Suddenly Not Loading

Re: ArcGIS Pro is not licensed from the Portal

Re: ArcGIS Enterprise 10.9 Which JDK and JRE Versions on Linux?

Re: Arcgis Server Unauthorized Access with valid credentials

Re: Error while migrating directories to shared folders NFS

Re: Arcgis Server Unauthorized Access with valid credentials

Re: Configure OpenID Connect logins

Re: Configure OpenID Connect logins

Re: DataStore Running out of SWAP in AWS

Re: Cloud Builder Error

Re: DataStore Running out of SWAP in AWS

Re: Verify machine registration observer: Unable t...

Re: TileCache datastore very slow to restore

Re: Programmatically Verify that Enterprise Portal...

Re: Unable to Generate Tokens using SAML enterpris...

Re: SAML Certificates Installation