Today I experienced an issue which I want to share on my blog, it is related to a setting related to BitLocker which gets tattooed meaning that it doesn’t get removed from the device if you modify the setting afterwards.

Let me explain the scenario first.

For a customer who is using both the Security Baseline for Windows 10 and later and the Microsoft Defender for Endpoint Baseline with the default settings I received the request to make writing to a removable drive not protected by BitLocker available for a certain group of users within the organization. And what started as a simple task, ended up with some heavy troubleshooting in order to create a solution.

So normally when I want to create exceptions to the Security baselines, I remove the settings defined in the Security Baseline and define a Configuration Profile with the same settings, allowing me to specify a group which gets excluded from these settings. By doing so I can keep the settings in the baseline for the majority of users, while allowing for exceptions.

For the setting “Block write access to removable data-drives not protected by BitLocker” I first needed to make modifications in both the  Security Baseline for Windows 10 and later and the Microsoft Defender for Endpoint Baseline

For the  Security Baseline for Windows 10 and later the following settings were changed

Security Baseline for Windows 10 and later

For the Microsoft Defender for Endpoint Baseline the following settings were changed

Microsoft Defender for Endpoint Baseline

Once the settings were removed from the baseline, I created a new configuration profile using the settings catalog with the following settings

Setting Catalog Configuration Profile

I then assigned the new configuration profile to the same group as the assignments for the baselines, and created a new group for the exclusion users which I excluded from the policy.

So up until this point I thought it was an easy task, and I started testing the results on one of my test devices, but for some reason after inserting a portable USB drive, it still kept asking for the “Before you can save files on this drive, you need to encrypt it using Bitlocker”

I started troubleshooting the process in order to determine whether the setting was applied to my system using the article I wrote earlier on MDM policy processing, but nothing could be found. The new policy got applied correctly which was reflected in both the Eventlog and the Registry as well. I also tried to see if the issue would resolve itself after a reboot, but that wasn’t the solution either.

After a lot of Googling I found the following thread on Reddit: “Bitlocker removable drive exception” and decided to check the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetPoliciesMicrosoftFVE registry path

Registry values for BitLocker

So it turned out that even though the setting was reverted, this was not populated to this registry location. So after first testing the outcome of setting the RDVDenyWriteAccess key to 0 and validating that I could insert a USB drive again without me asking for BitLocker to Go encryption.

Normally when tattooing takes place, you could just deploy a setting undoing the initial setting, but since the setting in the Configuration Profile only allows for yes and not configured, and therefore lacks the No option, I couldn’t create a policy which would solve the issue.  I decided to solve the issue by creating a small PowerShell script which I deploy to the exception group.

The script contains the following command: Set-ItemProperty -Path HKLM:SYSTEMCurrentControlSetPoliciesMicrosoftFVE -Name RDVDenyWriteAccess -Value 0 -Type Dword

Keep in mind that you would only need this setting if the user received the policy Denying access, and afterwards gets added to the exception group.

Even though Microsoft changed the behavior of the CSP policy processing more than one year ago where they moved away from tattooing the CSP settings to a model where the settings were removed if the CSP profile got unassigned as well. There are still some exceptions as this blogpost proves though. Let’s hope someone experiencing the same issue finds this article and can more easily solve the issue.

Changed Intune Policy Processing Behavior on Windows 10

Previous articleConditional Access announcements from Ignite November 2021 reviewed
Next articleThe Pursuit of HAPPY…. Uhhh TPM AMD Happyness (Part 3)
I started my career in 1995 as a System Engineer in the broadcast industry, building and maintaining video editing suites and television studio's and later specializing in Telecine equipment. In 1998 I switched to a first line support function within the Information Technlogy on the dealing room of a large bank, working my way up to a 3rd line support engineer. From this position i started to work on projects, which eventually resulted in projects where I worked across the border. In this period I implemented and designed several deployment solutions for mass rollout of workstations, laptops and servers. Since 2009 I switched to a consultancy function mainly focusing on but not limited to System Center design and implementation projects, besides that I became a Microsoft Certified Trainer (MCT) and currently teach System Center Related Classes (SCCM, SCOM and SCSM). In Januari 2010 I received the Microsoft MVP award with the expertise Setup & Deployment which was extended in 2011 and 2012. In 2013 and 2014 I was awarded the VMware vExpert award. In october 2014 I received the Microsoft MVP award with the expertise System Center Cloud and Datacenter Management (SCCDM).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.