Getting a portal token error while federating a general purpose server

[minagim]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request

Module Version

• 4.3.0

Affected Resource(s)

• ArcGIS_Federation

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 -Job $Job -JobName $ConfigurationName -DebugMode $De ...
  

• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
  • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Trace-DSCJob

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

• Trace-DSCJob -Job $Job -JobName $ConfigurationName -DebugMode $De ...
  

• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
  • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Trace-DSCJob

Steps to Reproduce

Important Factoids

Could this be related to #464?

References

GISServer-GeneralPurposeWA_Federated_Share.json

federateServerLog.zip

[mikiekelly]

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]

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]

@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]

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:

arcgis-powershell-dsc/Modules/ArcGIS/ArcGIS.psm1

Lines 2225 to 2238 in 4e1ea91

	if($PortalCheck){
	$PortalServerFederation = $True
	$PortalHostName = if($null -ne $ConfigurationParamsHashtable.ConfigData.Portal.InternalLoadBalancer){ $ConfigurationParamsHashtable.ConfigData.Portal.InternalLoadBalancer }else{ if($PrimaryPortalMachine.SSLCertificate){ $PrimaryPortalMachine.SSLCertificate.CName }else{ $PrimaryPortalMachine.NodeName } }
	$PortalPort = if($null -ne $ConfigurationParamsHashtable.ConfigData.Portal.InternalLoadBalancerPort){ $ConfigurationParamsHashtable.ConfigData.Portal.InternalLoadBalancerPort }else{ 7443 }
	$PortalContext = 'arcgis'
	}elseif($ConfigurationParamsHashtable.ConfigData.Federation){
	$RemoteFederation = $True
	$PortalHostName = $ConfigurationParamsHashtable.ConfigData.Federation.PortalHostName
	$PortalPort = $ConfigurationParamsHashtable.ConfigData.Federation.PortalPort
	$PortalContext = $ConfigurationParamsHashtable.ConfigData.Federation.PortalContext
	$RemoteSiteAdministratorPassword = (Get-PasswordFromObject -Object $ConfigurationParamsHashtable.ConfigData.Federation.PortalAdministrator)
	$RemoteSiteAdministrator = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ( $ConfigurationParamsHashtable.ConfigData.Federation.PortalAdministrator.UserName, $RemoteSiteAdministratorPassword )
	}

[mikiekelly]

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]

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