ArcGIS Server admin URL without the port specified & duplicate federated server names on portal

[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

• 3.0.2

Affected Resource(s)

• ArcGIS_Server
• ArcGIS_Portal

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.

6 BaseDeployment_DataStore_Server_DB_Portal_WA_DNS_SSC_Federated_Github.txt Federated_Server_1_WA_DNS_Federation_Github.txt Federated_Server_2_WA_DNS_Federation_Github.txt

Expected Behavior

1. Hosted & federated ArcGIS Server Admin URL with 6443 port specified in the portal admin.

2. Federated ArcGIS Server names with context names to differentiate hosted & federated ArcGIS servers with different privileges & access rules. Fine-grained access control of federated servers https://enterprise.arcgis.com/en/portal/latest/administer/windows/administer-a-federated-server.htm [federated server name]_Publishers [federated server name]_Administrators

Actual Behavior

1. I learned that the AGS admin URL should have the port specified in the portal admin. Is this an absolute requirement or would it function properly with the web adapter address?

https://www.youtube.com/watch?v=VYJtC6tzbSU

2. The web adapters for all ArcGIS servers are installed on the same WA host computer. They all seem to have the same server name even if the IDs are different.

Here is the list of ArcGIS servers in the portal.

Hosting Server

Federated server 1

Federated Server 2

I changed the server role in portal to be FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING on the federated servers to manage different groups of users with different federated servers. When I changed the role to FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING for both federated servers, the group names that were created from the action were the same (I think because the ArcGIS server names are the same) and the second set of the groups weren't recognized in the portal and I have errors publishing to the second federated server. Also, you couldn't delete the groups once created.

https://enterprise.arcgis.com/en/portal/latest/administer/windows/administer-a-federated-server.htm https://support.esri.com/en/technical-article/000022131

[federated server name]_Publishers [federated server name]_Administrators

List of Administrator & Publisher groups for managing privileges The first set is for one federated server and the other set for the other federated server.

Once these groups are created, they can't be deleted unless you unfederate the servers.

Are there any issues with the hosted and federated server names registered in the portal? If so, how should my script be modified to correct the problem? Do you think the reason the groups are not working correctly because the server names are the same for all arcgis servers in the portal admin? If so, is there any way to correct the problem without unfederating servers?

Thanks.

Steps to Reproduce

Important Factoids

References

[cameronkroeker]

Hello @minagim ,

When Admin Access is enabled on the WebAdaptor, "WebAdaptor": {"AdminAccessEnabled": true}, the ArcGIS Module will use the Web Adaptor URL for the federation Server Admin URL. Toggle this to false within the json file and then the ArcGIS module will use the 6443 URL for the federated Server Admin URL. However, for this change to take effect the servers would first need to be manually unfederated, which could have a negative impact on existing items/content/users/groups etc that have been published/created.

First though log into the portal sharing endpoint with the portal administrator account to see if all the federated servers have the same value for Server Name:

https://portal_WA_host_MachineName.domain/stgPortal/sharing/rest/portals/0123456789ABCDEF/servers

Here you will see all the federated servers listed along with Server Id, Server Name, Server URL, Is Hosted, and Admin URL.

In theory using the WebAdaptor for the federation Server Admin URL should be fine even if all the WebAdaptors reside on the same machine since they will all have a unique context name. However, I am wondering if the Server Name within the portal sharing endpoint is the same for all of them? And if they are all the same then perhaps this could possibly be the culprit to the issue.

Thanks, Cameron K.

[minagim]

Thanks for clarifying the admin URL issue.

Here is the Server List page on the portal sharing endpoint.

Would taking off admin access from the web adapters give each ArcGIS server the ArcGIS server DNS name instead of the web adapter host server name for the Server Name? Do you think this would be a solution for the proper FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING role and privilege maintenance for multiple federated servers? It looks like FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING role has been around for a while but I feel that the Fine-grained access control of federated servers page doesn't explain all the implications from different configuration scenarios explicitly.

This is our staging env and we don't have much contents in the system. Are the portal & server contents the only issue when unfederating servers? If I were to reconfigure all three ArcGIS servers, what would be the safest way?

In general, what would be the best practice for installing arcgis servers and web adapters when you have multiple federated servers? Should each ArcGIS server have a separate web server?

Thanks,

Mina

[cameronkroeker]

Thanks for clarifying the admin URL issue.

Here is the Server List page on the portal sharing endpoint.

Would taking off admin access from the web adapters give each ArcGIS server the ArcGIS server DNS name instead of the web adapter host server name for the Server Name? Do you think this would be a solution for the proper FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING role and privilege maintenance for multiple federated servers? It looks like FEDERATED_SERVER_WITH_RESTRICTED_PUBLISHING role has been around for a while but I feel that the Fine-grained access control of federated servers page doesn't explain all the implications from different configuration scenarios explicitly.

This is our staging env and we don't have much contents in the system. Are the portal & server contents the only issue when unfederating servers? If I were to reconfigure all three ArcGIS servers, what would be the safest way?

In general, what would be the best practice for installing arcgis servers and web adapters when you have multiple federated servers? Should each ArcGIS server have a separate web server?

Thanks,

Mina

Hi Mina,

We can actually update the 'Server Name' field manually without having to unfederate or do any harm to the federation. If you go to

https://portal_WA_host_MachineName.domain/stgPortal/sharing/rest/portals/0123456789ABCDEF/servers

Then select the 'Server ID', make note or copy the 'Admin URL' value (you will need it in the next step), and select 'Update Server'. You can then update the 'Name' field. I suggest using something like stg-gisservices.yourdomain.com/stgFHNRMapsAGS. Before selecting 'Update' ensure to paste in the Admin URL. It's key that this does not change in any way.

Then once the changes are saved go into portaladmin endpoint to ensure federation still validates. Then repeat this for each federated server.

Would taking off admin access from the web adapters give each ArcGIS server the ArcGIS server DNS name instead of the web adapter host server name for the Server Name?

Yes, or it would at least include the port in the name. For example 'Server Name' would be agsMachine.domain.com:6443. Thus giving it a unique name for each federated server.

[minagim]

Thanks for the great news, Cameron K. I am excited to hear that there is a way to change the server names for the federated servers. My only concern is that I wasn't able to delete the privilege groups ServerName_Administrator & ServerName_Publisher once created and I am not sure what behavior I would expect for the groups that is working for one of the federated servers. If the old ones are just inactive not affecting the new ones, I think I can live with it.

I am planning to follow the steps you suggested and try renaming both federated servers and test the behaviors with the privilege groups one by one. I'd like to change the server names on both to standardize configurations for all federated servers as we are planning to introduce more.

If this doesn't work out for me in configuring the Admin & Publisher groups, would you recommend uninstalling and reinstalling the entire system? After all, the power of ps dsc deployment is once you have all the scripts and files in place, installation and uninstallation would be easily executed.

Thanks,

Mina

[pfoppe]

I think you ran into this issue? https://support.esri.com/en/bugs/nimbus/QlVHLTAwMDEwOTYyMw==

Curious if there was any update to this proposed fix for this situation (basically, manually update the "Server Name" value to a unique value). And... where there any cascading impacts/effects? Like future upgrades?

We are looking into a manual workaround/fix of creating 2 new groups (publishers and administrators) for the federated server and sharing the server publisher and administration items with those 2 manually created groups.

just trying to find out the best implementation around this bug. Thanks!

[pfoppe]

Update,

We exhaustively attempted a workaround using the 'server name' value for the BUG I mentioned above. We determined that (at least at v1081) that portal "publisher" and "administrator" items get created REGARDLESS of the value we updated on the server name. We did not re-federate...

Here are the things we tried -

• Update the "server name" while the server was set to federated with restricted publishing. Result - no change to the existing publisher/administrator server items
• Set back to 'federated' without the restricted publishing, delete the publisher/administrator server items (that was hard). Then set the server name to a unique name (ex - www.example.com.fed1) and reset the federated with restricted publishing. Result - no change. The items were created with the existing fully qualified domain name (www.example.com).
• Set back to 'federated' without the restricted publishing, delete the publisher/administrator server items (that was hard), then set the server name to a unique name (ex - www.example.com.fed1). RESTART the portal, then reset the federated with restricted publishing. Result - no change. The items were created with the existing fully qualified domain name (www.example.com).

All of these attempts failed.

Our next approach is to just let the server items get created, and manually create groups and share them to new groups. We plan to do an upgrade to v1091 (from 1081) and hope this does not cause us any issues with the Install, license, configure (and pray) operation.

Any other suggestions/feedback would be super helpful. thanks!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.