Configuring FSLogix without GPO – Intune (part 1)

With Microsoft Azure Virtual Desktop (AVD) moving to an AAD join, using Group Policy to configure FSLogix settings will soon be seen as ‘old fashioned’

As yet there aren’t any administrative templates in Microsoft Intune for FSLogix so we need to get a bit more creative.

In these posts I am going to run through two of the more automated options available, of course the settings can be manually added to the registry, but that is well covered on the Microsoft documentation here:
https://docs.microsoft.com/en-us/fslogix/profile-container-configuration-reference

Updated October 2022 to include ADMX Import

Option 1 – Microsoft Intune using ADMX ingestion

Whilst the admin templates aren’t available yet, we can still use Microsoft Intune via the admx template ingestion and Custom-URI settings.

Unfortunately this isn’t quite as simple as the likes of Chrome settings as the policy uses strings instead of names.

First we need to ingest the admx policy. Normally this would just be a case of opening in notepad and grabbing the contents, but the FSLogix policy contains some HKLM:\SYSTEM strings which will fail if you try and ingest them.
To make things easier for you, I have a copy of the amended policy here
https://raw.githubusercontent.com/andrew-s-taylor/public/main/Powershell%20Scripts/AVD/fslogixadmx.xml

So, let’s ingest it!

Load Intune and navigate to Windows Configuration Policies and create a New Policy

Select Windows 10 or later, Templates and then Custom:

Give it a name and a description:

Click Next and press the Add button:

First step is to ingest the template
Add a name and description and in the OMA-URI type this:
./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/FSLogix/Policy/FSLogixAdmx;

Select String from the Drop-down and paste in the ADMX contents from the link above:

Click Save and then click Add again, now we will add the basic settings

First up, let’s enable it, always a good start:

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/FSLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~6a0b4022f3fb5302d7535c6053c98986/6bf06db968eddea70ab86c1a5b03abce

Type String
Data:

<enabled/>
<data id="6bf06db968eddea70ab86c1a5b03abce" value="true"/>

Click Save and add a new row

Keep Local Dir (I disable this to keep the box clean)

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/FSLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~6a0b4022f3fb5302d7535c6053c98986~66530266148a698477a6d33560717d5d/d5d2df5ad6046e369d584cc78fab45f2
Type: String
Data:

<enabled/>
<data id="d5d2df5ad6046e369d584cc78fab45f2" value="false"/>

Volume Type (VHDX is just better)

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/FSLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~a885268a05693066a9ec2ba0c5ac3240/2569640d13155c8f7ba400191940a6d0
Type: String
Data:

<enabled/>
<data id="2569640d13155c8f7ba400191940a6d0" value="VHDX"/>

VHD Location

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/FSLogix~Policy~2594ab6a0d5b818dbbc9ccba35b26929~6a0b4022f3fb5302d7535c6053c98986/7afe18ca9a4c1ba51f9fbc85c55b9f24
Type: String
Data:

<enabled/>
<data id="7afe18ca9a4c1ba51f9fbc85c55b9f24" value="PATH"/>

That is the basic settings, to add any more, the OMA-URI is in this format:
./Device/Vendor/MSFT/Policy/Config/FSLogix~Policy~(Top-Level Ref)~(Parent Category)/(PolicyName)
In the data, the data id is the policy name, NOT the value name

For example if we look at the code for VHD locations:

    <policy name="7afe18ca9a4c1ba51f9fbc85c55b9f24" class="Machine" displayName="$(string.7e38cb0238061de2af810505ab10b334)" explainText="$(string.b8754431ecbf22448c6998fd912bbc0d)" presentation="$(presentation.7afe18ca9a4c1ba51f9fbc85c55b9f24)" key="Software\FSLogix\Profiles">
      <parentCategory ref="6a0b4022f3fb5302d7535c6053c98986" />
      <supportedOn ref="18aba9a1585c1a6d76e6736fcb39d2b8" />
      <elements>
        <text id="7afe18ca9a4c1ba51f9fbc85c55b9f24" key="Software\FSLogix\Profiles" valueName="VHDLocations" required="true" />
      </elements>
    </policy>

The Parent Category is listed for that policy (6a0b4022f3fb5302d7535c6053c98986) which goes in the (Parent-Category) item above

The PolicyName is listed clearly enough (7afe18ca9a4c1ba51f9fbc85c55b9f24) which goes in both the PolicyName and in the data id

To find the Top Level Ref though is slightly more tricky. For that you have to find the Parent Category ID at the top of the ADMX file which then has it’s own Parent Category listed:

    <category name="6a0b4022f3fb5302d7535c6053c98986" displayName="$(string.6a0b4022f3fb5302d7535c6053c98986)">
      <parentCategory ref="2594ab6a0d5b818dbbc9ccba35b26929" />
    </category>

This parent category is your Top-Level-Ref.

Once you have finished adding the rows, simply assign the policy and deploy to your machines

Option 2 ADMX Import

With the new ADMX Import Functionlity, we can use that instead of a Custom OMA-URI:

First, grab the ADMX and ADML files:

https://github.com/andrew-s-taylor/public/blob/main/Powershell%20Scripts/AVD/fslogix.admx

https://github.com/andrew-s-taylor/public/blob/main/Powershell%20Scripts/AVD/fslogix.adml

Now we need to import those in Device Configuration – Import ADMX

Now refresh until it’s available

On to create the policy, select Templates – Imported Administrative Templates

Set whatever settings you need

Then simply assign the policy

In Part 2 I will cover deploying FSLogix Config via Azure Runbook

10 thoughts on “Configuring FSLogix without GPO – Intune (part 1)”

        • That’s annoying, are you targeting a Device group? It’s a device level policy so the only other reason if they’ve added it to the exclusion list.

          If you deploy the reg keys, does FSLogix work on it’s own?

          Reply
  1. I have exactly the identical problem. Not Applicable is displayed. Windows 11 multi-user OS version 10.0.22621.1105
    The policy is also applied to computer accounts.

    Reply
  2. Thanks for your reply 🙂
    Is there no other way to configure FSLogix via Intune without OMA URI?
    I would like to avoid OMA Uri.

    Reply

Leave a Comment