If you have a server in Azure and you are noticing that it boots into the recovery console and asks for the recovery keys, then follow this steps to remedy the situation:
BOLD sections need to ne updated as they are variables, as with anything on this blog you need to be sure of what you are doing before you go clicking around in the Azure portal.
- Created a rescue VM in the same subscription, resource group and region as the affected one and attached a copy of the affected OS disk as data disk
- Connected to the VM and confirmed that we see the affected disk locked in file explorer
- Once the guest agent become available in Azure portal on rescue VM, we went on disks -> additional settings -> Disks to encrypt, selected OS & data disk, then selected original key vault and created a new key (to be sure that old one is not expired)
- Once confirmed that the disks are unlocked on the troubleshooting VM, we have then proceeded with the below commands in Azure Cloud Shell -> Powershell to set the correct subscription, disable and remove the encryption:
- Set-AzContext -SubscriptionId <subscription ID>
- Disable-AzVMDiskEncryption -ResourceGroupName <rgname> -VMName '<vmname> -VolumeType "all"
- Remove-AzVMDiskEncryptionExtension -ResourceGroupName <rgname> -VMName <vmname>
- Check the rescue VM the progress for removing the encryption using an admin session for cmd and running the following command: manage-bde -status
- Once all the disk reached 0%, we have swapped the OS disk on the original VM but we reached the same BitLocker screen.
If you also have boot issues with the OS then continue on, if not you are done at step 8. - Then we have brought the Disk back on the recue VM, make it Offline from Disk Management and create a VM from it in Hyper-V, which requires installing the Hyper-V role on the recovery VM and mounted the disocnnected volume as the disk for Hyper-V to boot from
- The VM booted in recovery mode using Dart, the a startup repair was performed on the boot volume, the VM entered in check disk, repair, and afterwards booted up
- Next swap the disk on the original VM and confirmed we can login to it via RDP (ensuring 3389 is open on the NSG rules)
- As the data drive remained locked, we used (after creating snapshots for both OS disk and data disk) the procedure from step 3, and this way the data drive is unlocked
Please note you may not want to leave your disks unencrypted therefore to re-encrypt follow step three again to re-encrypt your disks