QuickPost – FSLogix Registry Redirection (HKLM to HKCU), or “how to turn Computer Config GPOs into User Config GPOs”

One of FSLogix’s lesser-known features, which I have written about before, is the capability to do redirection of any filesystem or Registry area to a different location.

This can be very useful on a filesystem level, for redirecting device-based configuration areas to user-specific ones. I’ve already used it to redirect specific users or groups of users to custom default user profiles or Start Menu LayoutModification.xml files.

The Registry redirection is another little-used, but very useful, feature of this product suite. You can effectively send any Registry key or value to another location within the Registry. The obvious application of this is to take settings that are HKLM-specific and redirect them into the HKCU hive, effectively allowing you to take a setting that is per-device and apply it differently to groups of users on the same endpoint by redirecting based on user or group.

Let’s find an example to use for this. Without any software to hand that writes per-device Registry items that would make more sense per-user (but trust me, there’s plenty of them out there), let’s do something a bit subversive – we will take a Computer Configuration GPO item and turn it into a user-specific setting.

Out of the hat, we have picked the setting Computer Configuration | Administrative Templates | Windows Components | Windows Security | Systray | Hide Windows Security Systray

As it says in the description, this setting, when Enabled, will hide the Windows Security notification area icon (shown below).

I personally think this is a good GPO to try this with as most of the Windows Security notifications need administrative access, so there’s no use presenting them to a standard user. However, as it is a Computer Config item, if you turn it off, you turn it off for all users – including administrators. So this is a legitimate use case to test with, as this is one of those GPOs that has been published in Computer Config when it would have made much more sense to place it in User Config, in my opinion.

In order to make this happen, we first need to understand the Registry location of the policy that we are trying to manipulate. Microsoft used to publish Excel spreadsheets with details of all Group Policy settings, but this has now been stopped since Windows 10 v1809. Some community sites are keeping this going, but it will be a frustrating day when it finally stops and we are reduced to unpicking the ADMX files by hand or running Process Monitor. For now, there is still a 1909 list of settings available over at 4SysOps.

Search through the spreadsheet until you find the setting you want to deal with, and read out the entry from the “Registry Key” column. For the setting we are looking at, the Registry path is as below

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Systray\HideSystray – DWORD 1 to Enable, 0 to Disable

Now let’s think about how GPOs read in these settings. They iterate through the Registry until they find the setting they are looking for. We need to intercept that path iteration at some point and redirect it into the HKCU hive.

For this setting, we are going to do the “interception” at the Registry key above – so when the session reads down into HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Systray we will then send that traffic somewhere else. In this instance, we will send it to a Registry key called HKCU\Software\FSLogixRedirect\Microsoft\Windows Defender Security Center\Systray. Within this key will be the value it expects, HideSystray. We have preserved the full path so we can easily understand which GPO it is we are referencing.

Don’t forget that we can’t actually use the GPO, because if we do, it will simply hammer through our redirected Registry path and overwrite the entry. So for the first part of this, we need to make sure that the actual HKLM Registry path exists, or it won’t be found.

Create a Computer Config Group Policy Preference Registry item with the following values (in Computer Config | Preferences | Windows Settings | Registry)

• Action – Create
• Hive – HKEY_LOCAL_MACHINE
• Key path – SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Systray

This will make sure that the policy path actually exists in HKLM so that it can be read.

Next, we need to create entries for specific users. We have two users, jrankin and jrankin2. We will turn the policy to Enabled for jrankin, and to Disabled for jrankin2, so we can show how this setting can be divided up.

Let’s lean on GPP again to do this (although you could use Citrix WEM, Ivanti UWM, or any one of the other UEM tools out there to get it done). Firstly, let’s create a GPP targeted to the first user

User Configuration | Preferences | Windows Settings | Registry

• Action – Replace
• Hive – HKEY_CURRENT_USER
• Key path – Software\FSLogixRedirect\Microsoft\Windows Defender Security Center\Systray
• Value name – HideSystray
• Value type – REG_DWORD
• Value data – 1

Apply an Item-Level Targeting so that it is scoped to the user or group required (in this case the user jrankin)

Now repeat the settings for the second GPP, but this time we will simply set the DWORD value to 0 instead of 1, and point the ILT to jrankin2 instead of jrankin.

So the two configured GPP items now look like this

Finally, we need to configure the key part – the FSLogix Redirection rule that points the HKLM Systray path to the HKCU Systray path. Open the FSLogix Rules Editor and start with a blank rule

Add a new Redirection Rule with the settings as below

Note that instead of using HKCU in the Destination path, we use HKU\__USER_SID__\ instead (hat tip due to Nathan S for pointing this out). Those are double underscores before and after USER_SID, which is separated with a single underscore. This variable tells FSLogix to substitute the user’s SID and go into the appropriate HKU hive.

[Interesting possible urban myth here, but I heard that the reason Registry folder structures are called hives is allegedly because one of the lead programmers at Microsoft working on the Registry had an irrational fear of bees and his co-workers called them such to get a reaction from him]

Once you’ve configured the FSLogix rule, you can optionally set assignments for it. I’ve chosen to restrict it to the two users I have been testing on.

Also, this may sound ridiculously obvious but you need the FSLogix Apps software installed on the target endpoints! 🙂

Now, it’s a simple matter of copying the FSLogix rules to the target machine(s), updating Group Policy, and seeing what happens…

So when user jrankin logs in, we can see that the HKLM Registry path is redirected into the HKCU key which shows the Systray value is set to 1, and no Security Center is present in the notification area

But when user jrankin2 logs in, the same HKLM value appears to be set to 0, and the Security Center is now visible in the notification area.

There we have it – a lovely way to redirect HKLM to HKCU and also to twist Computer Configuration GPOs into User Config ones. For posterity, when an administrator logs in to this machine it also shows the Security Center (because there is no entry in the Policies key and the default behaviour is to show it). So it works just how we want it to.

I’d use this setting with care, because it can get messy when doing a lot of redirections out of HKLM, but if you document and test them properly you will find this an invaluable tool when dealing with badly-written applications or policies that were clearly not thought through. But it’s yet another situation where the FSLogix suite can come to the rescue.