Ability to Federate ArcGIS Server with the Administration URL set to the Public Services URL

[dimesv]

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.2.0

Affected Resource(s)

• ArcGIS_Server
• ArcGIS_Portal

Configuration Files

Expected Behavior

There should a flag in the DSC Federation section to use the same URL in both the Services URL and Administration URL. This simplifies the deployment as the services URL is already being load balanced and we don't require an internal load balancer routing requests through port 6443. Note that we can already use WAF to apply security policies to only allow certain IPs to access the endpoints.

Actual Behavior

The DSC module federates the hosting server as well as all other ArcGIS Server sites with the administration URL set to either a specific machine or an internal load balancer using port 6443 which complicates the deployment further unnecessarily from our view.

If we change the federation settings after the fact, the next time we run the DSC module it acknowledges that the deployment is different than what has been set in the config, and the DSC module attempts to change it, which of course it can't resulting in an error and a message that the site is already federated.

Our current workaround is to configure our Azure Pipelines to continue on error. We have a YAML pipeline that runs after we run our IaC that streamlines an entire GIS Platform deployment.

Steps to Reproduce

Important Factoids

References

[cameronkroeker]

Hi @dimesv,

Can you try adding these 2 attributes to your json configuration file(s)?

• ConfigData.ServerContext
• ConfigData.Server.ExternalLoadBalancer

The parameter name is a bit misleading but this is used along with ConfigData.ServerContext parameter to set the WebContextURL property and also used for the federated Services URL and Administrative URL.

Thanks, Cameron K.

[dimesv]

Hi @cameronkroeker ,

Thanks for coming back to me. This is precisely the point. We currently have these two parameters in place and we have tried pretty everything else to see if the Administration URL would be set to the public services URL and it doesn't seem to work. It always federates using port 6443, including the hosting server.

Thanks, Jose

[cameronkroeker]

Hi @cameronkroeker ,

Thanks for coming back to me. This is precisely the point. We currently have these two parameters in place and we have tried pretty everything else to see if the Administration URL would be set to the public services URL and it doesn't seem to work. It always federates using port 6443, including the hosting server.

Thanks, Jose

I see. Is there an ArcGIS Web Adaptor? If so then try setting ConfigData.WebAdaptor.AccessEnabled to true in the json configuration file(s). However, if there isn't a web adaptor then try making the following modification to the module:

Change:

https://github.com/Esri/arcgis-powershell-dsc/blob/3d056fe815c68e9676789afe9d4ca71c05cefc8d/Modules/ArcGIS/ArcGIS.psm1#L2094

To:

if(-not($WebAdaptorCheck) -or ($ConfigurationParamsHashtable.ConfigData.WebAdaptor.AdminAccessEnabled -or ($ServerRole -ieq 'NotebookServer') -or ($ServerRole -ieq 'MissionServer'))){

[dimesv]

Hi @cameronkroeker ,

I have tested the module with the change above and it still does not work. See error below.

Hope you can help us find out where the issue is.

Thanks, Jose

[cameronkroeker]

Hi @dimesv,

If ArcGIS Server is already federated and the services url and admin url that is being passed in do not match the existing settings then it will first need to be unfederated manually prior to re-running the module. Be cautious though if there is already content then unfederating can significant consequences

https://developers.arcgis.com/rest/enterprise-administration/portal/unfederate-server.htm

Thanks, Cameron K.

[dimesv]

Hi @cameronkroeker ,

We have changed the existing settings manually to have the Services URL the same as the Administration URL. Then we ran the DSC with the fix above. If the change worked well, then it shouldn't have complained about anything because it would have matched it. So this means that somewhere in the logic it still compares the Administration URL with the port 6443.

I can't unfederate the environment as this would have major consequences.

Thanks, Jose

[dimesv]

Hi @cameronkroeker ,

The issue was on my side, where the DSC was being cached. Found this useful: "Remove-DscConfigurationDocument -Stage Current, Pending, Previous -Verbose -Force"

Can you your proposed changes to the next version? I would also add the following which is located below the changes you suggested:

From:

To:

This makes sure that the portal home URL is displayed in the output.

From:

To:

This makes sure that the URLs displayed in the output show the correct admin URLs.

Thanks again for your help. Jose Esri NZ

[cameronkroeker]

Thanks @dimesv confirming the suggested modification worked. We can definitely include this and your suggestion of the URL output as well into the next release of the module. There isn't an exact time table yet but we do plan to release a minor update (v4.2.1) that will include it.

Thanks, Cameron K.

[cameronkroeker]

Hi @dimesv,

v4.2.1 has been officially released and includes the fixes for this issue.

https://github.com/Esri/arcgis-powershell-dsc/releases/tag/v4.2.1

Thanks, Cameron K.