With Microsoft Azure Virtual Desktop (AVD) moving to an Entra 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
I have tried both methods and get not available in both scenarios. I opened a case with Microsoft as they are the ones that sent links to your site originally as the solution to my problem – Implementing FSlogix while keeping the roaming token when starting to use Intune.
Any ideas?
Are you getting any errors within Intune or on the device itself?
No errors, Just the profile showing not applicable to the test machine. I’ve double checked settings and don’t see any errors in setup.
Have you tried the new Settings Catalog settings for FSLogix as well? I think they’ve been added in the last few weeks
I have not. Can you link to that by chance? Quick search didn’t turn anything up.
I haven’t covered it in a post yet, but here is a screenshot
There absolutely is another way, but it’s via Registry.
Create intunewin packages to update the registry settings and apply to device via policy.
Yes, I cover the registry keys in part two:
https://andrewstaylor.com/2021/06/21/configuring-fslogix-without-gpo-runbook-part-2/
Using an application won’t be as easy to manage and update though
Thanks for your reply 🙂
Is there no other way to configure FSLogix via Intune without OMA URI?
I would like to avoid OMA Uri.
Not at this point I’m afraid, I’m not a big fan of them either.
Hopefully they’ll appear in settings catalog soon, but this is the only option for now
No, option 2 via adm import
Try the custom one, ADMX import gets blocked because it’s using some reserved reg keys
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.
Are you using custom OMA-URI ingestion policies?
Followed these steps but it is showing “Not applicable”
What platform do you have it configured for and what OS is it running against? Not applicable normally means a filter, or wrong OS version
Windows 10 Multi-user and Windows 11 Multi-User. I opened Microsoft case and they said it is not supported.
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?