Latest Contributions by danbecker

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

We deployed a new Azure Virtual Desktop host pool that contains NVIDIA GPUs and Pro 3.2.1. This general function failures STILL happen, only when accessing FGDBs stored in Azure NetApp files. Anyone experience this, ESRI, any advice here? ... View more

I can't believe this isn't documented, or discussed more..? We abandoned Azure Files and deployed an Azure NetApp Files 2TB smb volume, premium tier. Throughput given that tier and volume size is 128 MiB/s, equivalent to an on-prem 1000 Mbps network.    And, the performance shows, Id say it's faster then our 10k RPM SSD SATA disks on a 1000mbos network.   This is our identical architecture: https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/esri-arcgis-azure-virtual-desktop The only issue we have are random "general function failures" in Pro 3.1.2. Happens when the project is using FGDBs. SDE GDBs and you never get that failure. I'd say that error was happening 1-4 times /hr on Azure Files, and now once per day on NetApp files. It seems to happen when you open an attribute table. There's no way for Pro to recover, nothing draws, ect until you close Pro, then re-open..back to normal. So close to a REALLY nice, highly scalable virtual platform.  ... View more

I have this same question. Background: we've been using Azure Virtual Desktop (VD; Win10 multi-session host), FsLogix user profiles are stored in Azure Files share. So far, Pro has worked great in the VD environmetn, EXCEPT our "GIS" file share for FGDBs, Pro Projects, ect. The "GIS" file share was configured as a Premium Azure Files storage account in the same Azure region (Azure GOV Virginia) as the VDs, smb multi-channel enabled. AD DS authentication is enabled, VD machines and storage account are all AD joined, they both have line of sight to Domain Controller. Opening Pro projects stored in Azure Files is painful, so too are field calculations. Just opening the field calculation tool takes 5-10 seconds for it to fully populate all controls. If the Pro project and FGDB is copied to a local, managed drive, everything is 10x faster. Our Azure deployment is configured according to this doc, EXCEPT for Azure NetApp files. Our IT consultant told us "it shouldn't matter" if we used Azure Files instead. https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/esri-arcgis-azure-virtual-desktop Anyone have recommendations? Should we just switch to NetApp files? ... View more