QuickPost – setting Storage Sense cloud content dehydration on Server 2019

Storage Sense is really useful for helping to keep OneDrive cache down. I wrote an article a while ago explaining how you can use Storage Sense in conjunction with Files On Demand to aggressively trim the OneDrive cache and reduce the load both on your storage and your RDSH servers.

Essentially, Storage Sense has a setting to “dehydrate” what it calls “cloud content” (which to all intents and purposes means OneDrive cache). “Dehydration” is removing the cached copy and falling back to downloading the cloud-stored copy when it is opened. Simple, eh?


On the surface, it would seem yes. On Windows 10, you simply configure the Storage Sense GPOs and away you go. For a comprehensive list of the required GPOs, see the article linked in the introduction.

However – when doing this on Server 2019 (as you need Server 2019 to support Storage Sense and Files On Demand), be prepared for a nasty shock, because the GPOs actually don’t work.

You can see the Storage Sense settings by going into Settings | System | Storage (interesting side note – you can’t see System in the Settings app when you’re logged on via pure RDP), so it obviously works with Server 2019.

Interestingly, at the bottom of that screen, the option for “dehydrate cloud content” doesn’t appear – not until the user actually logs into OneDrive. Once OneDrive is configured and active, it appears in the Settings screen.

But as mentioned, none of these settings take any notice of the configured GPOs and would have to be set up by the user themselves. Which is not great, given that the default is to set the cloud dehydration threshold to “Never”.

Registry settings

Given that the user can actually configure these settings themselves, though, that means that there are bound to be Registry values we can leverage to preset them.

Of course, it would be too much to ask for Microsoft to make the Registry values sensible and predictable. Here I was expecting the value to turn on Storage Sense to be something like “StorageSenseEnabled” with a DWORD of 1 for on and 0 for off, but no, that would be too easy.

Storage Sense base settings

The main Storage Sense settings are stored in the following key:-


They’re numeric values for each setting – and some of the settings have two values rather than one. Yes, that makes perfect sense (that’s with a heavy dousing of sarcasm for those who don’t know me). They map as follows, best I can tell:-

Now, there are other values in this Registry key, but don’t touch those – I have no idea what they do.

Cloud dehydration settings

The settings for cloud content dehydration are another kettle of fish. Oh yes.

These sit in a subkey of HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy, but the name of the subkey goes by the following format:-


Bear in mind that if you have users with multiple OneDrive accounts, you may see subfolders listed as Business1, Business2, etc.

So for mine, which only has one account, it looks like this

This key contains two values which map as below:-

Of course, the real trick is getting the user’s SID and the GUID value so that you can add these into the path to set these last Registry values. The SID is easy enough to pull, but the OneDrive GUID (or the Provider, to give it the correct name) can be found elsewhere in the Registry, most notably at


Getting the user SID can be done easily with PowerShell or even by parsing the whoami command (both shown below)

for /f “skip=5 tokens=2 delims= ” %%a in (‘whoami /user /fo list’) do set USERSID=%%a

$USERSID = [System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

Alternatively, don’t forget that in Group Policy Preferences if you press F3 you get a list of available GPP variables – one of which is the user’s SID (%LogonUserSid%)

The GUID value (or the Provider as it should be called) is a little trickier because it is unique to each user. You will need to read in the Registry key mentioned above and set it as a variable somehow.

If you want something pre-rolled, then see Kasper Johansen’s GitHub for a script that you can run at logon to set all these values nicely for you – linked here


Once you’ve worked out how you want to skin this – whether it’s running Kasper’s script or using some form of GPP or WEM to inject the required Registry settings, you should now be able to deploy Storage Sense settings correctly onto Server 2019 RDSH instances.

Grabbing that user-specific Provider GUID from the Registry at HKEY_CURRENT_USER\Software\SyncEngines\Providers\OneDrive is the key part. Kasper’s script is probably the easiest way to do it – you can either use it in full or do what I did and simply hijack the required line and set a user variable (I called it %OneDriveProvider% and set it via a PowerShell logon script). Dependent on your environment, there are probably loads of ways you could achieve this.

Once I’d done that then a simple injection of GPP variable for the user SID made it good. You can then simply put the variables into the path for the last two Registry items as below.

Once we’ve done that and refreshed Group Policy, all of these Storage Sense settings should be preset for the user when they log into OneDrive.


This is a real pain in the backside. Microsoft, please make Server 2019 respect the Storage Sense GPOs! Until then, this should get you by.

Kudos obviously due to Kasper Johansen for identifying and rectifying this before I even realized it was a problem.



  1. Small correction/addition for Recycle Bin:
    To enable the cleanup of the Recycle Bin you also need to set the registry value “08” (DWORD) with data = “1” (“0” = disabled).
    So, to enable the retention of the Recycle Bin you need the following both registry values:
    “08” (DWORD) = “1”
    “256” (DWORD) = “14” (example for 14 days until retention)

    Maybe the author wants to correct his article…

  2. Hi James,

    How did you achieve the below? I am trying to workout how to do it.

    you can either use it in full or do what I did and simply hijack the required line and set a user variable (I called it %OneDriveProvider% and set it via a PowerShell logon script)

    1. I stole the required line from Kasper’s PS script (referenced not far above) and used it to set an environment variable via a PowerShell logon script.

      1. Thanks James, the setting as environment variable via PS is the bit I am struggling with.

        Was trying the below as a one liner but it doesn’t seem to be working:
        [Environment]::SetEnvironmentVariable(“%OneDriveProvider%”,”$((Get-ChildItem -Path HKCU:\Software\SyncEngines\Providers\OneDrive\)[0].Name.Split(“\”)[-1])”,”User”)

          1. Hi James,

            Managed to sort it out using the below logon script:

            Add-Type -AssemblyName System.DirectoryServices.AccountManagement
            $sid = ([System.DirectoryServices.AccountManagement.UserPrincipal]::Current).Sid.Value
            $OneDriveProvider = ((Get-ChildItem -Path HKCU:\Software\SyncEngines\Providers\OneDrive\)[0].Name.Split(“\”)[-1])
            Set-ItemProperty -Path “Registry::HKEY_USERS\$sid\Environment” -Name ‘OneDriveProvider’ -Value “$OneDriveProvider” -Type String

            Facing another issue now with users having a fresh profile. When they user initially logs on the HKCU:\Software\SyncEngines\Providers\OneDrive does not exist until the sign in to OneDrive has taken place. So the GPP fails as the environment variable is empty. If the user signs out and back in, because the registry key for Providers exists the GPP works as expected.

            Alternative is to add the following on line 173 of Kasper’s script to make it wait for the OneDrive sign in:

            Do {Start-Sleep -Seconds 5}
            while (!(Test-Path HKCU:\Software\SyncEngines\Providers\OneDrive))

            Did you come across this in testing? MS really made it a headache using OneDrive in Server 2019.

          2. Ah that’s good news….I didn’t see that, although the users I tested in the lab (all two of them!) were already signed in to OneDrive anyways, so that probably explains it. Glad to see you’ve got it running….and yes, I really agree that it’s a considerable headache.

  3. Ryan,

    If you do gpo item level targetting, you can just query to see if that registry key exists, much easier than doing via powershell script. 🙂

  4. Hi James,

    I wanted to ask if the problem also exists with Server 2022 or this has been fixed?

    Thanks for feedback


Leave a Reply

Your email address will not be published. Required fields are marked *