Latest Contributions by DavidColey

When you say "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?"  Not at the moment. It may be a legacy thing from earlier (like 10.6) releases.  I think for our org the main reason we set up admin access through the web adaptor was so that we could access Server Manager while not on our internal network by going through the F5 and the portal user store in case of emergencies -  like hurricanes - and I was not on network or could not be on network but still need access to Server Manager. I don't have a staging environment and don't want to try something like this on the fly.  You said earlier that: "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" Well, I say that this is a bug and needs to be addressed - because it has only shown up at this very latest release.  Don't get me wrong - I really appreciate your insight here. 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. I'm just not sure I can change the admin access - and if something goes wrong and re-enable it, that when I do re-enable that the site will still validate, what will the impact to Monitor be, etc etc. Thanks again - I'll have to give this more thought and will post back ... View more

looks like our messages got crossed.  No - the the services url and the admin url currently are the same.  Both are coming through the web adaptor. This is because I have administrative access enabled on the web adaptor - per the federation instructions - so things like Collector, Field Maps, Quick Capture will work correctly. ... View more

So you are suggesting to simply update my web adaptor settings by disabling administrative access through the web adaptor and in that way the admin access for the federated site will always use the internal dns name: This is what my portal admin page at https://gis5.ou_org.net:7443/arcgis/portaladmin/federation/servers/avo......PfyZJp  reads now for our federated site: Server: Federated Name: Federated Id: avoF0r....p Url: https://ags3.our_org.net/agsfed Role: FEDERATED_SERVER Admin Url: https://gis3.our_org.net:6443/arcgis Server function: First - Won't that break things like field maps?  All the documentation has always said for things like field maps and collector to function properly dmin access through the web adaptor has to be enabled.   Second - Has anyone else ever done this?  It seems very risky to do on a production environment like ours. ... View more

Ok - clearly this seems like a pretty big issue that hopefully can be addressed in an Enterprise patch - or at least addressed at release 11.1, I don't know how anyone could address this without creating a new federated site that somehow has different services and admin url roots.  I would not know how to do that . . .  In the meantime, what I have done is to just set up a robocopy to run each day to copy out the portal content folder and then run seperate site backups on the hosting and federated sites if any new data/layers/objects are published.  The datastore is set to it's default every-four-days automated backups, but I may now change that to daily. Any other suggestions are welcome! Thanks for looking into this Jon -   ... View more

 . . . But I would never do that, I always use https://my_dns_name:6443/arcgis/admin  So I don't see how a federated site could ever have an admin url that has a different root from the services url when the required 'enable  admin access through the web adaptor' is enabled so the federation can work.  ... View more

I'm not following you.  Are you referring to 'enabling administrative access through the web adaptor'?  In that case it is https://ags3.our_org.net/agsfed/admin/    where ags3.our_org.net is the alias we use at the F5.  agsfed is the web adaptor name.  I can access my admin page using the admin url . . .   ... View more

Thanks @JonathanQuinn  if you like, here is the case number I started with support: #03146363 ... View more

Here's one for you guys- we updated our distributed deployment Enterprise to 11 from 10.9.1, but left the federated side at 10.9.1 as it has to continue to support a couple of ArcMap runtime services (feature access that contains a geometric network) for now. The webgis dr tool keeps returning the  ‘Cannot get the the Web GIS configuration. Exiting the WebGIS DR utility.’ I was able to put the new log4j2.xml log config file into debug mode: <!-- Valid levels are debug, info, warn, and error --> <Logger name="com.esri.arcgis.webgis" level="debug" additivity="false"> and it turns out that something in the tool is truncating the 10.9.1 web adaptor name in the request url: . . . .  "privatePortalUrl":https://mydnsname:7443/arcgis ,"portalUrl":https://myf5name/portal ,"serverUrl":https://myf5name/agsfed ,"portalMode":"ARCGIS_PORTAL_FEDERATION","privateHostingServerUrl":https://myf5name/server ,"serverId":"avoF0rF9WMPfyZJp"}} 2022-09-14 13:45:44 DEBUG [ForkJoinPool.commonPool-worker-9] com.esri.arcgis.webgis.service.impl.WebGISDRFrontController - The response returned HTTP status code 404. Requested URL: https://myf5name/agsfe/rest/info  . . . .  So basically something is turning my federated web adaptor name 'agsfed' into 'agsfe' in the request.  How could that happen??   In the meantime, waiting to see what support says for my case . . .    @JonathanQuinn  @DeanMoiler    ... View more

Update: Our upgrade from 10.9.1 - 11.0 on our hosting server went well.  Again, we had disabled ArcMap runtime support on this server at 10.9.1 before running the upgrade to 11.  We also had installed the .Net 6 desktop support so that we could continue to enable .Net support on the hosting server site. No issues with a hanging 'auto-refresh service' step during the post upgrade for the hosting server.  We did not update our federated site - it is remaining at 10.9.1 until we can remove 2 ArcMap based services that contain the geometric network. We do plan to upgrade this site, but before I do I will disable the ArcMap runtime. We are experiencing a possibly related issue where the portal WebDR tool cannot create backups - I think this is because the federated site is still at 10.9.1 @JonEmch  ... View more

Interesting in an unfortunate way.  We were looking at enabling/disabling the VersionManagment privilege for our custom GISStaff role via the  arcgis api for python, but sadly that option is not available as a method, only as a property of the Role and RoleManager classes.    It can be done through the rest api, but I don't know how to do that in python. ... View more

This is perhaps a different scenario we are contemplating.  The Enterprise is at 10.9.1 and would like to move to 11 to take advantage of all the new functionality in portal (map viewer, map viewer edit forms, field maps calculations, instant app updates, etc) to support the rest of the enterprise. We are a distributed deployment, with separate web, portal, hosting and federated sites, and datastores.  The plan is to take advantage of the supported use case and upgrade portal, hosting site and datastore components to 11 and leave the federated site at the 10.9.1 release. We are currently migrating our water and wastewater system via asset package method to UN version 5 and Pro 2.9.4 to file gdb. We will then test, modify, test etc before then moving the UN version 5 to SQL and publish from Pro 2.9.4 to the federated site still at 10.9.1.   I suppose my comment is this:  Over the last 2 months, I cannot find anything anywhere that indicates this is NOT supported.  We built and deployed the Enterprise as distributed for exactly this type of scenario and use case, where the Federated side (site) would or could potentially remain at a lower release to support an integration or other Enterprise tools or objects that are not ready for newer portal releases. Feedback is appreciated. Thanks - @RandyCasey @JonDeRose  @MichaelHirschheimer  ... View more

Hello @DaveK  - assuming that you want to use your AGOL org as the host and your Portal as the guest, and that you want to the Portal guest to Send Content by reference to your AGOL org group, you have to set the share level of all the layers in the Portal workspace/group to 'Everyone', and then set the sharing level for your layers in the AGOL group as appropriate. As long as you have disabled anonymous access to your Portal, this should not be an issue.  This is what we do to send all of our data to our AGOL org for our Open Data site. If you want the Portal guest to Receive Content from your AGOL org group, then it really doesn't matter.  You would have to enable anonymous access to your portal in order to NOT get a login prompt when you open the 'received' content in your portals' web map. You don't want to do that. Typically, you would set up your field collection layer in your portal as I described in the first paragraph, and then have your field staff collect using a field maps form configured from a portal web map.  You could then see updates to the layer in agol depending on the sync frequency. ... View more

License file difference?  Not sure I understand - do you mean the runtime? ... View more

Update: Some more digging. As I said, the current gdal file in our current Server 10.9.1 is named gdal203e.dll version 2.3.3.38 and exists as part of the ArcMap-based runtime.   This file exists on our federated site where we did not disable the ArcMap-based runtime when we upgraded from 10.9.0 to 10.9.1 to support 2 map services containing the Geometric Network. We did disable the ArcMap-based runtime on our hosting site when we upgraded from 10.9.0 to 10.9.1 and so none of the ArcMap-based runtime files exist in the bin folder of the hosting site. While probably not possible for everyone, when we are able to discontinue using the Geometric Network, we had planned on just deleting those services from the federated site before upgrading that site to 11, as everything else on the site was authored in Pro.  In the meantime, we are leaving the federated site at 10.9.1 until our UN is ready to go, and even then the federated site will probably have to remain 10.9.1 until we can move to UN version 6 Also - we did have install the .Net 6 desktop-runtime framework on all 4 vm servers running ArcServer in both our hosting and federated sites.  Hopefully this helps- @JonEmch  ... View more

Thanks for the feedback @KurtisGagne1 .  Yes, a bizarre workaround indeed.  I have never encountered anything like this since we first stood up Enterprise at 10.6 and agree that this is very risky.  Sorry - I have a few questions if you don't mind - why or how would you ever think to compare a gdal dll that is part of the Server framework with one that is contained in Pro - do you have Pro installed on the same machine as Server?  Is this a base or distributed deployment, and if distributed, did this happen on your hosting site or federated site? Update:  The current gdal file in our current Server 10.9.1 is named gdal203e.dll version 2.3.3.38 - so not the same file, at least as far as naming goes. @JonEmch - do you have anything to add?   ... View more