FSLogix on Entra Joined AVD

I am currently investigating whether joining AVD only to Entra is an option. One of the subjects is FSLogix on Entra Joined AVD hosts.

Using FS Logix on Entra Joined AVD hosts with proper NTFS permissions on the share is possible. You can use this doc from Microsoft Learn to do so:

Microsoft Doc

It has a few quirks. So, I wanted to write a very detailed blog about it.

Prerequisites

The prerequisites are mentioned in the Microsoft Doc. Take a good look at it. It is important.


Configuring FS Logix for Entra Joined AVD

Firstly, we need to activate Microsoft Entra Kerberos for the storage account. So, go to the storage account in the Azure Portal and click on this button:

After that, click on Microsoft Entra Kerberos:

And, set it up:

You need to fill out the Domain name and the Domain GUID. You can get this info by logging on to a machine with AD domain tools installed and running this command:

Get-ADDomain

This will be the output: (red rectangles for the values that you need for the Microsoft Entra Kerberos config)

After that, Microsoft Entra Kerberos is enabled:

This process created a new App Registrations with the name of the storage account:

The Microsoft Docs state that you need to add permissions and grant consent. But the permissions are granted and consent is not required according to the portal:

It seems that you don’t have to grant consent from the picture above. But, I got feedback from https://twitter.com/xenappblog that you should. Otherwise, you will run into weird issues.

The next step is to exclude the storage account from Conditional Access. I would rather use the compliance option in Conditional Access to bypass the MFA prompt but this is up to you.

After that, we set up the NTFS permissions. Log on to a machine that has a line of sight to a Domain Controller and mount the Azure File Share on the machine.

You can mount the Azure File Share by using the script that the storage account provides:

I use a script to set up the NTFS permissions. This is it:

$localpathshare = "Z:\"

$AdminGroup = ""
$UserGroup = ""

#Set Permissions on the FSLogix Profile Share
icacls $localpathshare /inheritance:r
icacls $localpathshare /grant:r "CREATOR OWNER:(OI)(CI)(IO)(M)"
icacls $localpathshare /grant:r "$($AdminGroup):(OI)(CI)(F)"
icacls $localpathshare /grant:r "$($UserGroup):(M)"
icacls $localpathshare /remove:g "Authenticated Users" /t /c
icacls $localpathshare /remove:g "Users" /t /c

Fill the group variables accordingly and the permissions are set.

This is the result:

Configuring Intune

Next, is the Intune configuration. We need to create a setting catalog policy to configure FS Logix. I exported mine to a JSON file and made it available on GitHub.

Import the policy in the Intune:

You only need to specify the path to your storage account.

Lastly, we need to add a registry key to the AVD machines. I tried a couple of things. The CSP option doesn’t work because that’s not supported on multi-session AVD hosts. The GPO option is not available for obvious reasons. So, the registry is the one that works. I made a Win32App to push the key and also made it available on Github:

Link to GitHub

After that, finally, we log on to the AVD machine and you use FSLogix with NTFS permissions on an Azure File Share with Microsoft Entra Kerberos:

Other posts:

How to create your DevOps pipeline with Packer:

Packer YAML

2 thoughts on “FSLogix on Entra Joined AVD”

  1. Hi Niels!
    Nice blog.
    I wonder though. I’ve been succesfully deploying pure-cloud Azure Virtual Desktop with FSLogix through the use of a blob storage account for almost a year now and it works like a charm.
    Sure, you cannot set NTFS permissions, but this is not a requirement since it is cloud-only and using the Blob contributer / owner ‘share’ permissions.
    Is this the main advantage to the above compared to my deployment?
    Thanks again!

    Reply
    • Hi Jeroen,
      Your deployment sounds great and it will work surely!
      The only thing is, users use the machine account of their AVD machine to connect to their profiles. So whoever has local admin permissions or who has permissions in Azure to do so can access all the profiles. As long as you accept that risk everything is fine. 🙂
      Thanks.
      Niels

      Reply

Leave a Comment