Latest Contributions by JonathanQuinn

Yes, if you're confident you won't need your 10.8.1 data anymore, you can delete it.  ... View more

Permissions to layers and items is based on the sharing model, which can be shared with everyone, (public access), the organization, specific group(s), or not shared at all: https://enterprise.arcgis.com/en/portal/latest/use/share-items.htm As the administrator of a group, you decide who is part of the group: https://enterprise.arcgis.com/en/portal/latest/administer/windows/manage-groups.htm So sharing an item with only certain members would mean creating a group, adding those users to the group, and then sharing the item with the group. ... View more

Yes, that should work. You can either: Run the Configure Web Adaptor Utility to re-register the web adaptor without admin access, then run the backup, then again with admin access. If the web adaptor is not on the same machine as where you're running the DR tool, then you'll need to run it remotely via Powershell and the Invoke-Command function (https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=powershell-7.2) Use an API which allows you to update the setting from anywhere that the API is accessible from (https://server.domain.com:6443/arcgis/admin/system/webadaptors/<web adaptor id>/update) https://developers.arcgis.com/rest/enterprise-administration/server/updatewebadaptor.htm I'll keep a lookout for the bug. ... View more

Well, I say that this is a bug and needs to be addressed - because it has only shown up at this very latest release. Absolutely. Have the support analyst log a bug. They can contact me directly if they have any questions. As always, I poured through the issues addressed  https://downloads.esri.com/support/downloads/other_/110-IssuesAddressedList_07192022.pdf and all of the 'what's new' and saw nothing about this, even in the 'Disaster Recovery' section of the document. The original issue was found internally and an official bug wasn't created, which is why it wasn't added to the Issues Addressed list. ... View more

While I don't work on those apps, I'm not aware of any client requirement for administrative access to be enabled on the Web Adaptor. Can you point me to the doc that says that? Do you have a staging environment that uses similar constructs for URLs? Is your question has any ever disabled admin access on the web adaptor, or has anyone disabled admin access on a live production environment? If it's the former, then yes, it's a common practice especially in more secure environments to restrict who can reach the administrative APIs and endpoints for Server. Our security team has put together recommendations for load balancers, reverse proxies, and WAFs to disable access to administrative APIs as well. If it's the latter, then also yes; if there are workflows or operations that rely on accessing the Admin APIs or Manager through the services URL, those workflows may be impacted. ... View more

@DavidColey if https://ags3.our_org.net/agsfed is your services URL and has administrative access enabled and https://my_dns_name:6443/arcgis is your admin URL, try to disable administrative access on the web adaptor. ... View more

To sort out what to do next, it seems like your services URL is https://ags3.our_org.net/agsfed, and your admin URL is https://my_dns_name:6443/arcgis. It also seems like you have administrative access enabled on the Web Adaptor for https://ags3.our_org.net/agsfed. If this is the case, then the DR tool will use that URL for a few requests and result in the parsing error I mentioned above. If administrative access is not enabled for the Web Adaptor on https://ags3.our_org.net/agsfed , then it will solely use https://my_dns_name:6443/arcgis. The last character in https://my_dns_name:6443/arcgis is not in the list of "a","d","m","i","n", so it will not truncate the URL incorrectly. ... View more

Sorry, let me clarify; at 10.9.1 and earlier, we had a parsing issue. We check whether the services URL has admin access enabled, and if not, use the admin URL. Ultimately, though, the DR tool constructs the URL to the admin API as https://admin.domain.com/arcgis/admin. It then needed to parse out the "/admin" URL path from the end, but mistakenly stripped the first occurrence. This meant there were requests going to https://.domain.com/arcgis, which of course wouldn't resolve. We addressed this in 11.0, but used an incorrect method, which looks for any character in the URL that matches any character in "admin". In your case, https://ags3.our_org.net/agsfed/admin/ all of the bolded characters are characters in "admin", therefore got stripped from the URL, resulting in https://ags3.our_org.net/agsfe. My question was whether the services URL and Admin URL are both set to https://ags3.our_org.net/agsfed, which makes a workaround more challenging. ... View more

Unfortunately, this is a regression from a change to handle "admin" in the admin URL hostname. It strips any characters in the word "admin" from the end of the URL, which is why your URL that ends in "d" has the "d" stripped. Your services URL is https://myf5name/agsfed; what's the admin URL? ... View more

Hm, the DR tool shouldn't even need to make a request to the services URL; it should use the admin URL for everything. I'll take a look. ... View more

When creating a Server site, there are two important parameters; where the config-store will be located and where the directories will be located. The config-store, which is where site and service configuration, security information, and other things are stored, can be in cloud storage. The directories, which store published services, output of jobs and map operations, must be on the file system. A file share will always be provisioned for a site that uses cloud storage. ... View more