There has been a lot of chatter about Azure AD Joined VMs with AVD, and the inability to use Azure Files or ANF with FSLogix. It is true that FSLogix works best with an SMB share (joined to an AD DS domain), but that’s not the only way to use FSLogix… you can deploy without an SMB share!
FSLogix includes a capability called Cloud Cache, which can use Azure BLOB storage instead of (or in addition to) an SMB share… which doesn’t need AD DS!
Using Cloud Cache with Blob is almost as simple as using an SMB share… almost.
You still just need to add the storage location to the VMs registry (just like with an SMB share), but instead of using a share, you use the storage account Connection String.
Below are the FSLogix registry settings I used in a recent AAD-joined test deployment (HKEY_LOCAL_MACHINE\Software\FSLogix\Profiles):
The “CCDLocations” looks a little different than what you might see with a typical FSLogix deployment:
Here’s a closer look at the entry – it’s basically the storage account “Connection String” with a little bit added to the front:
This works great – and creates the VHDs – each as a separate container in the storage account just as you would expect (without the need for a share or AD DS account!):
The cool thing is that I’ve actually put multiple blob connection strings in the registry, so the user profiles are updated in multiple Azure regions (East Coast and West Coast) – all while using less costly BLOB storage, and without any dependency on AD DS.
Using Cloud Cache is not all puppy dogs and rainbows, however, there are security and performance considerations to deal with.
The first “challenge” is that I put the storage account connection string right into the registry – UNPROTECTED – that gives anyone with rights to the registry access to the key… they could (potentially) get to other user profiles!
PRO TIP: ALWAYS USE CREDENTIAL MANAGER
Credential Manager allows you to secure the connection string inside the VM, and should be used for any and all Cloud Cache with BLOB deployments in Azure.
THINK ABOUT PERFORMANCE
The next issue is around performance. Not having access to an SMB share means that each and every read / write uses (relatively) slow REST APIs, which limits the performance and ultimately scale of the deployment. I do not have any performance metrics, but I have been told that for relatively small deployments (a few hundred concurrent users all writing to storage in the same Azure region) should have no trouble using Cloud Cache with BLOB.
Check out this post from Jason Parker on this same topic:
FSLogix profile containers for Azure AD cloud only identities – Microsoft Community Hub