Created Dev Drive volume ends up write-protected

[ALERTua]

Reported by @Eagle3386 in #1.

After the script creates the Dev Drive partition, the resulting volume is write-protected. The reporter was able to enable auto-unlock via PowerShell afterwards, but the volume stayed read-only.

Environment notes from the report:

• no local admin rights; elevation obtained through Admin By Request
• the run had already hit the Enable-BitLocker failure (see the BitLocker issue) and was resumed with a locally modified script, so the volume may have been left half-configured

To do:

• reproduce: create a Dev Drive partition and check Get-Volume / Get-Partition attributes and Get-BitLockerVolume state
• check whether the read-only state comes from a locked BitLocker volume rather than an actual write-protect flag
• if the volume can legitimately end up locked, add a final verification step that confirms the drive is unlocked and writable before the script reports success

[ALERTua]

@Eagle3386 Could you please elaborate on the write-protected volume? I did not encounter such behavior. Any more details? Any errors while trying to write?

[Eagle3386]

I guess the partition got into that mode because the BitLocker part failed & Windows somehow does some "auto-magic" in that case.
Though, that read-only mode was already the case before I enabled auto-unlock.

Regarding your main question: I constantly hit only 2 errors:

1. "Media is write-protected" (manually translated from German by me)
2. Error code 0x80090034 for which a lot of search results pointed me in the (IMHO wrong) direction of MS Office (it's installed on my C: partition, but AFAICT has nothing to do with the script issue), but a couple ones also stated that creating HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb\ProtectionPolicy as a DWORD with its value set to 1 & rebooting should help - spoiler: it didn't.

[ALERTua]

@Eagle3386 Sorry — the registry path I asked you to check earlier was the wrong one, which is why it looked like a dead end.

HKLM\SOFTWARE\Policies\Microsoft\FVE is where the setting lands when it comes from Active Directory group policy. Your machine is managed from the cloud, so the same setting lands somewhere else entirely, under PolicyManager. Looking in the old place proved nothing either way.

Here is why it matters. Microsoft's BitLocker FAQ says that when write access to fixed drives not protected by BitLocker is denied, Windows mounts every unencrypted fixed data drive read-only. Your run had already failed at Enable-BitLocker (#2), so the new volume stayed unencrypted — and a read-only mount is then exactly what that policy is supposed to do. That would explain "Media is write-protected" without anything on the disk being wrong.

Could you run these three, elevated, and paste the output? All three only read.

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker' -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty Property

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker' -ErrorAction SilentlyContinue |
    Select-Object FixedDrivesRequireEncryption, FixedDrivesRecoveryOptions

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE' -ErrorAction SilentlyContinue

Empty output from all three is a useful answer too — it means the policy is not the cause and we look elsewhere.

Either way, the script should not have let you get that far without saying anything. #48 is merged: it now writes a file to the new drive before it starts setting up deduplication, and if that write fails it stops and explains what read-only most likely means, instead of failing several steps later with an error about deduplication.

[Eagle3386]

@Eagle3386 Sorry — the registry path I asked you to check earlier was the wrong one, which is why it looked like a dead end.

I see, thanks for your clarification.

HKLM\SOFTWARE\Policies\Microsoft\FVE is where the setting lands when it comes from Active Directory group policy. Your machine is managed from the cloud, so the same setting lands somewhere else entirely, under PolicyManager. Looking in the old place proved nothing either way.

That registry node (FVE) looks like I showed in my previous comment.
Regarding PolicyManager: where do I find that node? Can't see it around the FVE one & its siblings?! 🤔

Here is why it matters. Microsoft's BitLocker FAQ says that when write access to fixed drives not protected by BitLocker is denied, Windows mounts every unencrypted fixed data drive read-only. Your run had already failed at Enable-BitLocker (#2), so the new volume stayed unencrypted — and a read-only mount is then exactly what that policy is supposed to do. That would explain "Media is write-protected" without anything on the disk being wrong.

Perfect, thanks for that! 👏🏻👍🏻

Could you run these three, elevated, and paste the output? All three only read.

Yes & here you go with their outputs:

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker' -ErrorAction SilentlyContinue |
Select-Object -ExpandProperty Property

That returned nothing at all, not even an empty table.

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker' -ErrorAction SilentlyContinue |
Select-Object FixedDrivesRequireEncryption, FixedDrivesRecoveryOptions

That one got me just this:

FixedDrivesRequireEncryption FixedDrivesRecoveryOptions
---------------------------- --------------------------

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE' -ErrorAction SilentlyContinue

Only this one yielded a couple of lines:

FDVDenyWriteAccess : 1
PSPath             : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE
PSParentPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft
PSChildName        : FVE
PSDrive            : HKLM
PSProvider         : Microsoft.PowerShell.Core\Registry

Empty output from all three is a useful answer too — it means the policy is not the cause and we look elsewhere.

So, since the last one did return "something": does this mean some policy is the cause? 😢

Either way, the script should not have let you get that far without saying anything. #48 is merged: it now writes a file to the new drive before it starts setting up deduplication, and if that write fails it stops and explains what read-only most likely means, instead of failing several steps later with an error about deduplication.

Thanks so much for that, Alexey! Much, much appreciated what you're investing in this! 😍

Tried the script's latest commit version (after expanding C: back to its original size) - these are the outcome's key points:

1. Trust for Defender's performance gain failed:

   Could not mark D: as trusted (fsutil exited with code 1).
   The Dev Drive will still work, but without the Defender performance mode trust enables.
   Check the current state with: fsutil devdrv query D:
   Retry by hand with: fsutil devdrv trust D:

2. The BitLocker step failed & succeeded at the same time: CLI seemed to have worked, but I still confirmed the popped up dialog (Enable BitLocker encryption… (manually translated from what I remember)), too:
   
   (roughly translates to BitLocker drive encryption: This drive must be encrypted by BitLocker before you can save files on it/write on it. [Encrypt with BitLocker] [Don't encrypt])

   That then gave me an error:
   
   (roughly translates to Encryption error: Not a valid drive for encrypting. BitLocker encryption already active/enabled.)

   Due to that, I deleted the partition, expanded C: again, re-ran the script & this time, that dialog popped up again, but I didn't click anything & it disappeared automatically (actually, while I edited my screenshot 😅).

3. Result after 2nd run:

   DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining   Size
   ----------- ------------ -------------- --------- ------------ ----------------- -------------   ----
   D           DevDrive     ReFS           Fixed     Healthy      OK                    506.94 GB 512 GB
   
   ComputerName          : [REDACTED]
   MountPoint            : D:
   EncryptionMethod      : XtsAes128
   EncryptionMethodFlags : None
   AutoUnlockEnabled     : False
   AutoUnlockKeyStored   :
   MetadataVersion       : 2
   VolumeStatus          : EncryptionInProgress
   ProtectionStatus      : Off
   LockStatus            : Unlocked
   EncryptionPercentage  : 99
   WipePercentage        : 0
   VolumeType            : Data
   CapacityGB            : 512
   KeyProtector          : {RecoveryPassword}
   
   Reading the recovery key back off D:
   
   ================================================================
   BITLOCKER RECOVERY KEY FOR D: - WRITE IT DOWN NOW
   AAAAAA-BBBBBB-CCCCCC-DDDDDD-EEEEEE-FFFFFF-GGGGGG-HHHHHH
   ================================================================

   Suggestion: Please ask for the FriendlyName, using DevDrive as default upon Enter.

4. After confirmation that I saved the recovery key elsewhere, the script printed this:

   Backing up the recovery key to Azure AD
   
   ComputerName          : [REDACTED]
   MountPoint            : D:
   EncryptionMethod      : XtsAes128
   EncryptionMethodFlags : None
   AutoUnlockEnabled     : False
   AutoUnlockKeyStored   :
   MetadataVersion       : 2
   VolumeStatus          : FullyEncrypted
   ProtectionStatus      : On
   LockStatus            : Unlocked
   EncryptionPercentage  : 100
   WipePercentage        : 0
   VolumeType            : Data
   CapacityGB            : 512
   KeyProtector          : {RecoveryPassword}
   
   Enabling BitLockerAutoUnlock
   BitLocker setup did not finish. Windows reported: Die Gruppenrichtlinieneinstellungen  lassen keine Erstellung eines Wiederherstellungsschlüssels zu. (0x8031005E)
   The Dev Drive is created and formatted, and BitLocker has already started encrypting it.

   Note: The German part of the error message at the end translates to The group policy settings don't allow creation of the recovery key.

Nonetheless, Dev Drive exists, folders & files can be created.

What's next? 😁😎

[EDIT]
Re-ran fsutil devdrv trust D: manually in an elevated prompt - output (manually translated):

The volume is in use and changes might not be effective immediately.
Stop allocation/provisioning of the volume for the change to apply.
Error 5: Access denied.

How to do that via PowerShell? 🤔

[ALERTua]

@Eagle3386 That output settles it, and it turned up three separate things. Thank you — this is a better bug report than most.

Yes, a policy is the cause

HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE
FDVDenyWriteAccess : 1

FDVDenyWriteAccess is "Deny write access to fixed drives not protected by BitLocker". While it is 1, Windows mounts every unencrypted fixed data drive read-only. Nothing was wrong with your disk, the partition, or the script's formatting — the volume was doing exactly what that setting tells it to.

Your own last run proves it end to end: the drive refused writes while it was unencrypted, and accepted them once BitLocker had finished. That is the whole of #3.

And I sent you to the wrong place twice, so let me correct it properly. PolicyManager is where the setting lands when a device is managed through the modern cloud channel — on your machine it is empty, so that is not how it arrived. It does not matter: HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE is the effective location, where the setting ends up whatever delivered it. That is the one to read, and the only one I will ask anyone to read from now on.

You cannot change this yourself if it comes from your employer's policy, and you should not try to. It is doing its job.

Your question about fsutil

The volume is in use and changes might not be effective immediately. Stop allocation of the volume for the change to apply. Error 5: Access denied.

How to do that via PowerShell?

You do not have to. fsutil will do it itself if you tell it to force the dismount:

fsutil devdrv trust /f D:

The designation takes effect through a dismount, and without /f fsutil only performs that dismount while nothing is holding the volume. Yours was in use, so nothing landed — which is exactly what its message says.

/f is already in main, along with a read-back that asks the volume afterwards whether it really is trusted, instead of believing the exit code. Your run predates both. Confirm with:

fsutil devdrv query D:

It should say the volume is trusted, and list WdFilter as the only filter attached.

The BitLocker message was our fault, not your machine's

Look at what your volume reported:

VolumeStatus         : FullyEncrypted
ProtectionStatus     : On
EncryptionPercentage : 100
KeyProtector         : {RecoveryPassword}

BitLocker succeeded. Encryption completed, the drive is protected, the recovery key exists and went to Azure AD. The only thing that failed is automatic unlocking, and it failed because group policy on your machine forbids it — that is what 0x8031005E means.

The script then announced "BitLocker setup did not finish" and offered to retry. Both are wrong: nothing was left unfinished, and a retry would meet the same refusal. That is #64, and it is a defect in the script.

What it should have told you, and what matters in practice: without automatic unlocking, that drive needs unlocking by hand after every restart. Keep the recovery key.

The dialog that fought with the script

The Windows prompt you saw — "this drive must be encrypted before you can write to it" — is the same policy again, and it appears because the volume is briefly unencrypted. It races with the script, which is already encrypting; answering it is what produced "BitLocker encryption already enabled".

Leave it alone if you see it again. It closes by itself, as you found on the second run. #65 will warn about it before BitLocker starts on a machine with this policy, and will also state in the plan — before anything is created — that BitLocker is effectively mandatory here rather than optional.

Your suggestion

Asking for the volume name with DevDrive on Enter: agreed, filed as #66.

Where that leaves things

Three issues came out of your run: #64 the false failure report, #65 stating the policy up front and warning about the dialog, #66 the volume name. #3 itself stays open until #65 lands, since that is what turns this from a mystery into a line in the plan.

Nothing here needs anything further from you — though if you do run fsutil devdrv trust /f D: and it reports the volume trusted, that is worth knowing, because you are the first machine where the "volume in use" case has actually been seen.