Latest Contributions by danbecker

The AttachmentsCreated feature service webhook fires reliably, but I discovered Editor Tracking on the SDE geodatabase attachment table has to be enabled in order for the attachments:{adds:[]} JSON object returned from /extractChanges to be populated with the attachment info.    But ONLY in an online workflow. If the field maps app is used offline, then the feature (with attachment) is synced, the webhook fires, but attachments:{adds:[]} is empty.  Anyone else experience this? We're using ArcGIS Enterprise 11.4 ... View more

My only advice is to migrate both FsLogix profile containers AND GIS file share to Azure NetApp files and stop fussing with Azure Files (all storage/transaction tiers).  We have 1 Azure NetApp 3TB capacity pool (premium tier) that's used for /profile and /gis shares and have had zero issues since my above thread reply. We opted for manual throughput, so that we could favor the /gis volume and assign it 132 MiB/Sec. The profiles are a bit slow to sign-out due to the throughput bottleneck, but we just advised users to sign-out of AVD, then minimize the AVD session and go about their business on the local PC. FsLogix eventually completes all communication with the profile container in netapp and signs-out w/out any issues. We started using this CPU SKU: Standard NC16as T4 v3, and we're able to comfortably fit 4 pooled (multi-session) users on the same VM. I actually think we could increase that to 5, maybe 6... and all of them are using Pro. It's pretty amazing.     ... View more

Thanks David. Yes, Count(FeatureSetByName) returns a different number depending on replica sync, vs. inserting a feature using Pro.  VERY confusing and not documented at all (at least from what I could find).  This arcade script is already bloated at 500 lines. Could be trimmed down if I take some more time, but complex. I really see no other alternative to firing a script by insert trigger. Maybe a feature service webhook would be more reliable. Better yet, that webhook calls powerAutomate flow, that invokes an Azure python runbook... ... View more

Fortunately, this was just cached browser data causing the issue! I initially cleared Edge cache from "Last 7 days" selected, but I tried "All Time" when clearing it this time, and it's working great now!  Phew... didn't want to deal with this on a Fri evening. ... View more

@DevinBartley2 wrote: Appreciate the extra provided detail and comments, this saves me an immense amount of time and lets me focus on the heart of the issue. Your comment makes me wonder how the performance would have been if you stuck with Azure Files but had the AVD hosts Entra ID joined and Kerberos auth enabled on Azure Files.   The performance of Azure Files with AVD hosts Entra ID joined would still not match the NetApp volume (Premium performance Tier). How do I know this? After we deployed Entra ID joined AVD session hosts, we continued to use Azure Files for our FsLogix profile containers (user_name.vhdx). To do so, we had to create a new Azure Files premium StorageAccount for the "profiles" file share because you can only configure 1 authentication method per storage account, and the old storage account was configured for AD DS authentication. AD DS auth. isn't supported for Entra ID joined AVD session hosts, so the new storage account was configured with Kerberos authentication.  We tried to migrate the old user_name.vhdx profile containers to the new storage account, but were unsuccessful, because the SID of the user_name changed (AD DS identity vs. syned Entra ID identity). Something internal with how FsLogix looks up the location of the user's profile container prohibited it from working, generally it's unsupported according to MS docs; migrating a profile container after a user's SID is changed.  Everything seemed to work great, UNTIL the session host failed to retrieve an updated Kerberos ticket from Microsoft (Azure Files) to authenticate the "profiles" share that was hosting the user_name.vhdx profile container. Windows command: klist would show that the "profiles" share kerberos ticket expired 1 hour after it was issued. If that ticket wasn't updated by Windows successfully before that expiration date/time, then it was the equivalent of pulling a hard drive out of a working windows machine, complete chaos ensues for the user's session. I have no clue why Windows wasn't able to retrieve updated Kerberos tickets from Azure Files. It would work fine for all users for hours, then all of a sudden, it wouldn't. There was no rhyme/reason why it would/not work and when. All I can think of is Azure vnet sputtering or packet loss was the cause. Someone on StackOverflow said they cannot think of a worse use-case scenario for Azure Files (profile container hosting)...that's all we had to hear and pulled the plug on Azure Files, especially given our past GIS experience with it.  Now, remember the Windows command: klist. While we were troubleshooting the above profile container issue with Azure Files, we noticed that the kerberos ticket for the NetApp "GISfiles" volume (stores FGDBs, ect.) was being issued by our AD machine, and had a lifespan of 10 hours. So, why not create another NetApp volume "profiles" and simply move the profile containers to there? That's exactly what we did, and all of our problems are now solved. Something tells me that the un-reliable Kerberos ticket renewal process with Azure Files would cause problems for GIS data stored on there as well, I can almost guarantee it. Pro would throw the "General Function Failure" error when that ticket expires, if a new one wasn't issued in time. I recently overheard an analyst last week "has anyone worked on their local machine with Pro lately?" someone then responded "no, the AVD machines are 10x faster". Simple conversation, but very satisfying to hear, we've been put through the paces getting this technology to work. When paired with a high performing NVIDIA GPU, our Pro machines are BLAZING fast. Next step will be to purchase another 1TB of capacity on our NetApp capacity pool, so the total would be 3TB, split between 2 volumes (GIS and Profiles), then we get 3 * 64 MiB/sec =  192 MiB/sec throughput to play with. NetApp lets you manually specify how much throughput to allocate to each volume, its highly configurable and super simple. I would highly recommend NetApp, it's amazing. ... View more

I had a different thread I was updating: Azure Files premium file share - SLOW File Geodata... - Esri Community Yes, absolutely upgrade to NetApp files, you will not be disappointed. But, also note that we found performance still lacking until our AVD session hosts were Entra ID joined; and Kerberos authentication to the NetApp volume was configured.  Traditional AD-joined AVD session hosts still had issues with NetApp performance, the machines would seemingly drop the NetApp volume connection, which caused Pro to display "General Function Failure" when accessing an attribute table of a FGDB layer, that was stored on the NetApp volume.  ... View more

We deployed a new Azure Virtual Desktop host pool that only contained Entra ID joined session host VMs, same NVIDIA GPUs. upgraded to Pro 3.2. Since the VMs were no longer AD joined, we had to migrate all the AD Group Policy Objects to InTune, which really wasn't that difficult given the GPO import tools in InTune. FsLogix profile containers were switched away from Azure Files Premium and are being stored in an Azure NetApp Volume, just like our GIS file-based data.  Entra ID-joined session hosts can only authenticate with SMB shares using Kerberos authentication, not NTLM (on-prem AD). So, Kerberos auth. and ACLs (permissions) were configured per Azure docs. for both the NetApp \profile and \gis volumes.  For the results: ALL PROBLEMS ARE SOLVED!  Added bonus is that all MS office apps, including the Remote Desktop client are SSO using Entra ID (cloud) credentials. The VMs, Pro, and FGDB access is 100% improved.  I wish I had a better explanation, but our problems with FGDB performance in AVD was 100% caused by authentication issues with traditional on-prem AD (which was a VM in Azure, not really on-prem).  With the sputtering/performance issues resolved, I have no doubt that better performance could be achieved by increasing the NetApp capacity pool quota (i.e. monthly A$ure invoice). Our current cap. pool quota is 2TB which comes with 128 MiB/s throughput, divided how ever we want between \profile and \gis volumes. Another 1TB would add +64 MiB/s throughput.  Azure NetApp is quite amazing, so simple.  ... View more