Latest Contributions by FredSpataro

Update:  Interesting result from adding a machine in two environments (TEST & PROD)...  In my test environment, the new standby datastore loaded with the default values for backup schedule and location ie not the same values as the primary In my prod environment, the new standby datastore loaded with the same value for both backup schedule and location as the primary The one notable difference is that in TEST, I installed the datastore, configured it, then ran the patch utility which found a 'Highly Available' patch which I installed --- but after the store/machine was joined.  In PROD, i knew the patch was needed so I installed that patch right after installing the software, before doing the configuration wizard.  All suspect, as I swear these never seem to go exactly the same ever... The patch doc doesn't specifically say it, but does seem like there was an issue with backups:   BUG-000156440 - Restoring highly available relational ArcGIS Data Store through webgisdr shows PostgreSQL databases return primary statuses for both machines when point-in-time recovery (PITR) is enabled. So maybe having the standby configured exactly the same is the correct setup?    ... View more

Thanks Cody... I like your approach...seems like a 'standby' shouldn't even run a backup but also doesn't seem to make sense to have the location same as the primary in case something goes wrong or conflicts... so a different location covers the bases. ... View more

Hi, sorry haven't found a solution. Let me know if you're able to dig on up. ... View more

Here's another ... same symptoms slightly more detail about "WHY" https://community.esri.com/t5/python-questions/python-package-certifi-win32-is-missing-after/m-p/1495558#M73503   ... View more

Adding another related: https://community.esri.com/t5/python-questions/missing-soap-packages-after-upgrading-to-3-1-1/m-p/1299855#M68398   Seems like the same 'package manager acting weird and different for each user' kind of issue, no explanation about why but workaround is to install directly from the conda command line...   ... View more

@Luke_Pinner had one of my local office users run both config and search commands: both match your output... so it finds msal at the cmd search but can't find it in the UI search ...  Had my client user run the conda install cmd and it seems successful => msal folder is now in the pkgs folder but his UI doesn't show msal as installed or addable ... they using a citrix env so i'm sure that's somehow causing issues but they are really the ones i need to get working.      idk ... sort of the usual arcgis voodoo ... View more

@Luke_Pinner thanks for digging deeper on this!   What i'm seeing is not isolated to my machine... a couple of machines in my office and at least one at a client location as well but all are showing that 10K range of packages. FredSpataro_0-1746741623241.png   ... View more

Thanks Luke! That's odd, have you ever installed it before? Here's my package manager: FredSpataro_3-1746660952352.png   ... View more

Update:  It's possible we manually installed at the command line in the older 3.1 and I've just forgotten about it.  It seems to have successfully installed running: conda install microsoft::msal at the command line ... but why make me work so hard 🙂 ... what use is a package manager UI that can't install all the packages...  ... View more

Found myself here hoping for the enlightenment but found everyone having the same issue... tldr: I think it's working, just not obvious to prove....   Assuming @ChrisBeaudette's (tag your it 😏) response from esri is valid then there must be some other way to prove it's working so I kept digging a bit and think I found the way to verify it is in fact working.  Setup: V11.1 standalone server Query operation on MapServer/1 "cacheControlMaxAge":"3600" I've been expecting to see some clear 'it's from cache' cue in the chrome dev tools... but never see a 304 response or 'disk/memory cache' in the size column and the response header always displays: the max-age:0;must-revalidate... chalking it up to the 'javascript fetch/etag' implementation and whatever about security that esri mentioned.  So, the chrome dev tools network tab has a handy little checkbox "Disable cache'.  Using this and the same service from two different servers (one with the cache control set and one without), I see this: Requests to first server with cache control setting at 3600  Enabled, Enabled, Disabled, Disabled, Enabled FredSpataro_0-1743549898958.png I had been hitting the service a bunch so the first requests are already cached (small), then disable the local cache, boom... larger network transfer, then re-enable the local cache, back to smaller    Requests to second server with cache control setting not defined Enabled, Enabled, Disabled, Disabled, Enabled,  FredSpataro_1-1743549984377.png Always 709, as expected no difference b/c there's no cache setting   Painful but I think isn't enough to convince myself it's doing what I want and it's worth deploying the setting.       ... View more

Yes please! ... View more