Latest Contributions by DavidColey

I was able to update the hosting site 'server' web adaptor after stopping the web application pools same as @RyanUthoff and @SebastienPetit  - although I did have to run the patch twice to update the 'server' WA (my federated site and portal updated previously without having to stop their respective pools) I suspect the first time I ran the update following the method tech support told Ryan to do is because the files were still locked, and it just needed a few more minutes to clear.    If the 'server' WA still hadn't updated then I would have ran again per @MarceloMarques  - but fortunately did not have to ... View more

Same here - any updates on this?  Does ESRI have any suggestions as to logo dimensions for the Instant apps?   ... View more

I'm sorry but this doesn't make sense to me: "The patch does not apply if you have multiple arcgis application pools."  Yes, at 11.1 each WA now runs in it's own application pool.  So you if you have any kind of Enterprise deploy, you are going to have at least 2 WAs - one for portal, one for the hosting server site.  We have 3 - portal, federated site, hosting site plus the original ArcIGISWebApaptorAppPool v4.0   But as I just noted above, the patch updated 2 of the WA's - according to the dll dates - although the patch ran 3 times - once per 11.1 v6 web adaptor.  The patch summary notes say nothing about stopping the IIS to run the updates.  Is esri now recommending that the patch be re-applied while the IIS is stopped so that the ArcGIS-111-WAI-RU2-Patch.msp patch will update web adaptor pool for 'server'? Such that the ESRI.ArcGIS.WebAdaptor.dll for the 'server' will show as updated?  Because 'View Installed Updates' certainly shows that the updates have been applied.   @KaitlynStevens ? @JonEmch ? ... View more

We have a distributed site, as I have mentioned earlier in this post  For our hosting site, the web adaptor is named 'server' and the ESRI.ArcGIS.WebAdaptor.dll is  dated March 1, 2023.  For our federate site, the web adaptor is named 'agsfed' and the ESRI.ArcGIS.WebAdaptor.dll is dated August 10, 2023.  For the portal WA, the ESRI.ArcGIS.WebAdaptor.dll is dated August 10, 2023. We do not run ANY map and or image and / or server extensions from the hosting site - it purely serves hosted feature layers from portal. All of our map and image and (network, validation, versioning, geolocator) etc services are run through the agsfed WA, per our system design. All 3 WA's, server, agsfed, portal all show the patch as applied through 'installed updates' as accessed through control panel>view installed updates. For IIS, I don't know what multiple bindings means.  We only have 80 and 443 showing as bindings on the Default Web Site.  There are no bindings on anything else. To me, given what @eryildiz just reported, this suggests that ESRI did not expect anyone to be running traditional types of services from the hosting site.  If that's the case, that would seem like an oversite for sure. That being said,  ESRI did not expect anyone to have the letters a-d-m-i-n in the name of their federated web adaptor site at 11.0 - like I do 'agsfed' - yet that did happen and I could not run a webgisdr until I upgraded to 11.1. So - now I understand why maybe we 'got lucky'.  We are not running anything other than hosted feature layers from the hosting site.  All traditional services are accessed from the federated site. And although we have many (250 combined maybe?) traditional map, image, feature access, versioning, geolocator, validation, networking services running through the federated site, that app pool did not freeze before or after patch updates.  I should note that wherever possible, all services on agsfed are using the 'shared instance' dynamic mapping service.  I have that set to 16 instances, appropriate for an 8 core 32gb server. hope this helps some too -  David       ... View more

You know, I outlined the specs of our web adaptor machine in this post several months ago.  We still have yet to experience any of the issues that the patches address.  Nevertheless, I of course have applied these patches. For those that continue to experience "App Pool Freeze" issues, I haven't seen or read any specs on any of the machines that are failing.  I only mention this because of 3 items: DMZ - we use F5. For us, our F5 does no load balancing, it merely directs requests. OS - we are still at Windows Server 2016 on the server hosting our web adaptors.  One of the components required to run web adaptor at 11.1 is the Web Deploy 3.6 .  When you go to this download page, and review the system requirements for the Web Deploy 3.6, you can see that Windows Server 2022 is NOT listed among the supported operating systems: System Requirements Supported Operating Systems Windows XP, Windows 7 Professional, Windows Server 2003 Service Pack 2, Windows Server 2012 R2, Windows Server 2008 R2 SP1, Windows 8 Pro, Windows Server 2012, Windows Vista, Windows 8.1, Windows Server 2016, Windows Server 2019 The supported platform is 64-bit for this download. The .NET 2.0 Framework SP1 or greater must be installed.   Does this mean that the Web Deploy 3.6 supported on Windows Server 2022?  I don't know - Microsoft nor ESRI say anything about it.  NOR does the Microsoft documentation say anything about IIS 10 For others, perhaps they did not follow this item from here: ArcGIS Web Adaptor 11.1 system requirements  Caution: If you installed the ASP.NET Core Runtime - Windows Hosting Bundle before enabling IIS and the required components, you must repair the bundle installation using the bundle installer. Also from the system requirements above: Memory - the system requirements dictate that the 'web adaptor' now requires 8Gb minimum: Hardware requirements ArcGIS Web Adaptor (IIS) requires a minimum of 8 GB of memory, with more potentially required depending on the number of ArcGIS Web Adaptor instances installed and the number and size of the requests received. Does this mean 8Gb per Web Adaptor?  I don't know.  We are running 3 Web Adaptors on a 16Gb Windows 2016 Server with 4 cores, 8 virtual.  So according to the hardware requirements, we are under-memory.  Yet we run about 20% memory utilization on the server day in and day out:   So that's it.  I guess I "lucky?"  I don't know, but I do know more fine-grained info needs to be provided on this thread.         ... View more

From esri on 08/09/23: Updates have been made to the following defect which you are associated with: BUG-000158232 - In Portal for ArcGIS, sharing items with groups does not work when an organization member owns more than 29 groups with the 'isViewOnly' property set to True. Status: Fixed (Learn More) Version Fixed:  11.2 Additional Information:  This issue is resolved in ArcGIS Enterprise 11.2, which will be released in Q4 2023. ... View more

Actually, turns out I was wrong on this for BUG-000158232. When I try to share an existing item via the api to a group that I own, nothing happens.   So this: try: portItems = gis.content.search(query="owner:myusername_portal", item_type="Feature Layer", sort_field="title", sort_order="asc", max_items=5000) for portItem in portItems: if (portItem.title == "CPBoundary"): portFL = FeatureLayerCollection.fromitem(portItem) print (portItem.title) portFL.manager.update_definition(updateDict) #portItem.update(item_properties=itemProperties) #,data=None, thumbnail=None, metadata=None) portItem.share(everyone=False,org=False,groups="mylonggroupid") print(portFL.properties) message = message + "\n" + "1. " + (portItem.title) + " Sync Enabled: " + str(portFL.properties.syncEnabled) except Exception: # If an error occurred, print line number and error message import traceback, sys tb = sys.exc_info()[2] e = sys.exc_info()[1] print(e.args[0]) print ("Line %i" % tb.tb_lineno) message = message + "\n" + "Line %i" % tb.tb_lineno message = message + "\n" + str(e)   works fine in AGOL, but as I own more than 29 groups in our Portal as the portal admin, nothing happens.  For the share method params 'everyone' and 'org', the api works for Portal . . . but not for the groups param. It would be super-helpful if we could get this addressed as a patch at this release.  Like everyone, we have few hundred or more layers to move around and having to go into each group whenever I need to re-share an item gets to be cumbersome. Changing group owner to another admin account for say a subset of our existing groups and then making my admin account a 'Group Manager' on any owner-changed accounts would maybe a work-around, but with so many of my groups participating in distributed collaborations that is tricky and risky . . .  @MarleyGeddes  @nabil  ... View more

Ok whatever someone did seems to have fixed this.  I'm seeing my previews, data grids, etc ... View more

Yes!  I am experiencing the same error with all of my AGOL hosted feature layers, whether public, org-level, group-level or private.  I cannot preview the layers either.  The console log shows a CORS error.... @RussRoberts  maybe you are seeing this too? ... View more

Ok so re-installing this patch through the patch notification tool did not clear the 'show available patches'.  The patch is installed, it shows as an update in control panel> programs and features> View installed updates.   ... View more

Yes,  I am.  Initially, the patch notification tool could not find the patch on Wednesday 6/28/2023: and so I went to the support page and downloaded the msp from there. I then ran the patch, it installed successfully, but as you noted the patch notification tool still shows the patch as an available download, even though window programs installed updates shows the patch as installed, same as in your screen grabs. This has happened before.  The last time was at 10.9 for me.  In my experience, patches that are not downloaded by the patch notification pool will still display as available.  I plan to wait a few more days and if the patch still shows as available, and if the tool can download it, I will download and install again.   That will or should clear the notification tool ... View more

I just want to report that this still has not been an issue for us.  I'd say I was one of the lucky ones, but I'd rather say that our distributed deployment on Windows Server 2016 and all network protocols (open ports, and firewall rules, group policy rules for accounts, IIS roles and features, server roles and features, etc) are responsible for our continued stability.  I have not had to adjust max instance and max queue length values.  Currently the web server is running 4 w3wp processes. We use f5 as our reverse proxy. The f5 does no load balancing at all, it just directs requests. The web (4-core 16Gb Ram) server does not use a DNS alias, rather it is aliased on the f5. We do this so that all machines that do participate in our deployment - portal, hosting site, federated site, 2 data stores - can use our CA wildcard certificate and validate as secure when the certificate is applied to each machines' DNS.   Our configuration server (config store, server directories) has no issues communicating with all machines that participate in the site. UPDATE: Still no issues for our site after applying the second patch. on 08/15/23 Thanks, David David Coley ArcEnterprise Administrator Sarasota County GIS ... View more

Sorry @RussRoberts - buried Thursday and Friday.  Yes, I can verify this is fixed, the vector point style symbol is no longer off-setting . . . thanks for your help ... View more

ok Russ here you go: https://sarco.maps.arcgis.com/home/group.html?id=070b68d0ce8e4d14971b2b83f892502b&showFilters=true#overview Its the SewerManholeVault sublayer . . . ... View more

Or I can add you to a group in our org if you reply here or DM me your agol user name . . .  ... View more