search

Esri / arcgis-powershell-dsc

This repository contains scripts, code and samples for automating the install and configuration of ArcGIS (Enterprise and Desktop) using Microsoft Windows PowerShell DSC (Desired State Configuration).
Apache License 2.0
112 stars 61 forks source link

Getting a portal token error while federating a general purpose server #552

Closed minagim closed 1 month ago

minagim commented 2 months ago

Community Note

Module Version

Affected Resource(s)

Configuration Files

# Copy-paste your DSC JSON configurations here - for large configs,
# please use a service like Dropbox and share a link to the ZIP file.

Expected Behavior

It should federate a general purpose server to an existing multi-machine portal env.

Actual Behavior

It fails with the following error message.

Trace-DSCJob : 7/1/2024 3:32:17 PM: PowerShell DSC resource ArcGIS_Federation failed to execute Test-TargetResource functionality with error message: Unable to retrieve Portal Token for 'portaladmin' from Deployment 'portal fqdn' At C:\Program Files\WindowsPowerShell\Modules\ArcGIS\ArcGIS.psm1:261 char:5

Trace-DSCJob : 7/1/2024 3:32:17 PM: The SendConfigurationApply function did not succeed. At C:\Program Files\WindowsPowerShell\Modules\ArcGIS\ArcGIS.psm1:261 char:5

Steps to Reproduce

Important Factoids

Could this be related to #464?

References

GISServer-GeneralPurposeWA_Federated_Share.json

federateServerLog.zip

mikiekelly commented 1 month ago

I've been experiencing a similar issue whereby federation fails at 4.3.0 - I'm working with ArcGIS Enterprise 11.1. It seems like some of the hardcoded default vales are passed into ArcGIS_Federation.psm1 instead of being pulled from the config, e.g. I specify 443 in the config for Federation.PortalPort but 7443 is used to request a token alongside the ExternalLoadBalancer address which doesn't exist. Similarly the default arcgis is used for the Federation.PortalContext instead of what is specified. I got it to work by updating some of these defaults within the ArcGIS_Federation.psm1 (lines 74/78) file.

I also got it to work by using the 7443 address, and ultimately the ExternalLoadBalancer address with 443 was used for federation so I guess there's some logic in there if the ExternalLoadBalancer is specified. But it wasn't designated as the hosting server. Anyway I'm going to revert to 4.2.1 to see whether that resolves things.

One final note - I noticed at one point that even if ConfigData.Federation is not specified, federation is attempted.

mikiekelly commented 1 month ago

Are there certain scenarios whereby the ConfigData.Federation properties get overwritten or are not used? No matter what I specify 7443 appears to be used as the PortalPort along with the Portal ExternalLoadBalancer URL property. If I specify the PortalHostName it gets overwritten by the ExternalLoadBalancer URL. And the PortalContext is set to arcgis even if I specify portal. The only way I've been able to make this function is by adding the following into ArcGIS_Federation.psm1 after both instances of Write-Verbose "Get Portal Token from Deployment '$PortalFQDN'":

$PortalPort = 443
$PortalContext = 'portal'

Once I do this federation succeeds without issue - I've tried at both 4.2.1 and 4.3 and encounter similar issues.

cameronkroeker commented 1 month ago

@minagim

The error Unable to retrieve Portal Token for 'portaladmin' from Deployment 'portal fqdn' is indicating a token was not able to be generated from https://portal fqdn/portal/sharing/rest/generateToken. Let's try specifying the web adaptor hostname when using 443 or if using the portal hostname specify 7443 port with context arcgis. For example:

Portal Web Adaptor: https://PortalWebAdaptorFQDN/portal/sharing/rest/generateToken

"Federation": {
   "PortalHostName": "Portal Web Adaptor FQDN",
   "PortalPort": "443",
   "PortalContext": "portal",
   "PortalAdministrator": {
      "UserName": "admin",
      "Password": "pswd"
    }
}

Portal: https://PortalFQDN:7443/sharing/rest/generateToken

"Federation": {
   "PortalHostName": "portal fqdn",
   "PortalPort": "7443",
   "PortalContext": "arcgis",
   "PortalAdministrator": {
      "UserName": "admin",
      "Password": "pswd"
    }
}
cameronkroeker commented 1 month ago

Are there certain scenarios whereby the ConfigData.Federation properties get overwritten or are not used? No matter what I specify 7443 appears to be used as the PortalPort along with the Portal ExternalLoadBalancer URL property. If I specify the PortalHostName it gets overwritten by the ExternalLoadBalancer URL. And the PortalContext is set to arcgis even if I specify portal. The only way I've been able to make this function is by adding the following into ArcGIS_Federation.psm1 after both instances of Write-Verbose "Get Portal Token from Deployment '$PortalFQDN'":

$PortalPort = 443
$PortalContext = 'portal'

Once I do this federation succeeds without issue - I've tried at both 4.2.1 and 4.3 and encounter similar issues.

The ConfigData.Federation block is only used when federating additional GIS Server roles. When a json file contains a base Enterprise (portal, server, datastore) it does not use ConfigData.Federation:

https://github.com/Esri/arcgis-powershell-dsc/blob/4e1ea910cf3c237c378dfcfc1130a296de3c4bcb/Modules/ArcGIS/ArcGIS.psm1#L2225-L2238

mikiekelly commented 1 month ago

Ah gotcha thanks Cameron - that makes a lot of sense. So in my case it's pulling the CName from the SSL cert which is inaccessible over 7443. So I should specify the Portal.InternalLoadBalancer as the Portal FQDN and it will use that for federation.

minagim commented 1 month ago

Thanks, Cameron. Changing to the web adaptor DNS name resolved the issue. I will close the case.