|
POST
|
Using this code I successfully generated a token on 10.8.1, 10.9, and 10.9.1 Portal sites. The big difference I see is that you're using 'requestip' for the client as opposed to 'referer'. import requests
baseURL = 'https://<FQDN>:7443/arcgis'
tokenURL = "{}/sharing/rest/generateToken".format(baseURL)
username = <IAA_account>
password = <IAA_password>
expiration = 60
params = {'username': username, 'password': password, 'client': 'referer', 'referer': baseURL, 'expiration': expiration, 'f': 'json'}
response = requests.post(tokenURL, data=params, verify=False)
token = response.json()['token']
print(token)
... View more
06-06-2022
07:36 AM
|
0
|
1
|
3575
|
|
POST
|
Your shell didn't switch to the 😧 volume before executing the command, typically you'd do this by entering 'D:' in the prompt, then run the 'cd' and 'webgisdr' commands you have listed.
... View more
06-06-2022
06:26 AM
|
1
|
0
|
1703
|
|
POST
|
Can you try without encoding the parameters? Since the values are sent in the body of the request there shouldn't be a need to encode the referer URL. That's the only difference I can see between my working version and yours. I also leave off the headers for the token request but I don't expect that to make a difference.
... View more
06-03-2022
11:05 AM
|
0
|
3
|
3583
|
|
POST
|
Connection timeouts are typical of packets being dropped at the firewall or edge network appliance, so I'd lean on your IT department for additional information there. It may be a security software installed on the machine or a network-based ruleset (that can also be based on AD user membership). If there were a forward proxy decrypting and re-encrypting the traffic you'd see entries detailing an untrusted certificate chain in the Portal logs.
... View more
06-03-2022
10:50 AM
|
1
|
2
|
3033
|
|
POST
|
Another angle of approach would be to try entering https://www.arcgis.com in the checkUrl endpoint, then reviewing the Portal for ArcGIS logs for any SSL certificate verification issues. The reverse proxy action (web adaptors) would be different than outgoing traffic that may be affected by a forward proxy. Example URL: https://portal.domain.com:7443/arcgis/sharing/rest/portals/checkUrl
... View more
06-03-2022
08:37 AM
|
0
|
0
|
3038
|
|
POST
|
If you login to the AWS Console and go to CloudFormation, you should be able to see a distinct stack created for each site. Clicking a stack and going to the Resources tab should allow you to see what resources were created as part of that stack, and which would be destroyed if you delete the entire stack. Hopefully that helps you identify a path forward since the Cloud Builder application pulls information from the CloudFormation APIs. If the VPC, ELB, and other resources were provisioned outside of the stack you are looking to delete, it should be safe to delete that stack. One thing to keep in mind is that the associated DynamoDB table(s) and S3 buckets won't be removed when you delete the stack and will require manual cleanup for those resources. They should be named appropriately to include each stack name so you can identify those resources.
... View more
06-03-2022
06:18 AM
|
1
|
0
|
1630
|
|
POST
|
Two things I would consider here are whether the new Portal for ArcGIS service account can access the internet (on the Portal for ArcGIS machine) and whether there is a forward proxy in the network path. When saving credentials, Portal for ArcGIS acts as a proxy to attach the credentials in-transit so needs to both trust the certificate of the target resource and be able to reach it. This technical article may prove helpful as well: https://support.esri.com/en/technical-article/000015387
... View more
06-03-2022
05:50 AM
|
0
|
0
|
3049
|
|
POST
|
Have you confirmed the reverse proxy is setting the X-Forwarded-Host header (if layer 7) before passing the request to the Web Adaptor target? Are you using a non-default port in the WebContextURL portal system property? Reference Doc: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm
... View more
05-24-2022
06:49 AM
|
0
|
1
|
2432
|
|
POST
|
The two values should match between the Portal's System Properties and the federated ArcGIS Server site's Security Configuration. The most common cause that I've seen is not using the proper casing when setting the privatePortalURL in Portal's System Properties. If you can confirm that key is set exactly as I've written it, a support case may be helpful to dive in further on your particular configuration.
... View more
04-25-2022
06:24 AM
|
1
|
0
|
2909
|
|
POST
|
Security patches for different products are released at different frequencies, so you shouldn't have any problem with installing the Portal for ArcGIS security patch following the installation of the ArcGIS Server security patch.
... View more
02-23-2022
05:45 AM
|
0
|
0
|
1382
|
|
POST
|
We've seen a few issues when using bash emulators as opposed to a native bash shell, so using a native bash shell on Linux is recommended for the deployment scripts. Since it seems to be having issues with the certificate portion in particular, you may be able to get around it by creating a TLS secret in the namespace yourself and specifying it in the deployment script (option 1 in the SSL settings prompt). https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
... View more
02-22-2022
05:40 AM
|
2
|
1
|
3215
|
|
POST
|
The addition of an additional load balancer in the web-tier certainly adds a bit of complication, but since NLBs perform their proxy action transparently (from a layer 7/application perspective) the architecture you're proposing should not introduce any issues for ArcGIS Enterprise. The DNS record would be updated to point to the NLB as opposed to the ALB, but as long as the Portal and federated server URLs stay consistent no other changes need to be made.
... View more
02-14-2022
08:52 AM
|
2
|
0
|
2148
|
|
POST
|
Glad to hear! Thanks for following up with the fix details as well.
... View more
01-27-2022
06:00 AM
|
0
|
0
|
2830
|
|
POST
|
My deployment was internet-facing with a public DNS record, but as long as the DNS resolves from the client machines that are running the orchestration pieces I think either would be fine. If the clients weren't able to resolve the DNS alias, the federation step would fail long before the deployment completed successfully.
... View more
01-25-2022
10:54 AM
|
0
|
2
|
2839
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 12-28-2020 09:14 AM | |
| 1 | 09-16-2022 05:19 AM | |
| 1 | 05-01-2023 05:23 AM | |
| 1 | 05-07-2021 06:21 AM | |
| 1 | 09-13-2021 05:44 AM |
| Online Status |
Offline
|
| Date Last Visited |
12-20-2023
11:01 PM
|