4 min. Read
Azure Disk Encryption is a feature announced in May 2016 that allows you to encrypt Windows and Linux IaaS VMs. Azure disk encryption take advantage of an industry standard BitLocker feature in windows and vista DM-direction A Linux feature that provides operating system and disk encryption to protect data. The solution is integrated Azure Key Vault helps manage and control the disk encryption keys and secrets of your keystore order while ensuring that all disk data on virtual machines is encrypted at rest in Azure storage.
When you deploy a disk encryption management solution, you can meet the following business needs:
- IaaS virtual machines are protected at rest by using industry-standard encryption technology to meet an organization’s security and legal requirements.
- IaaS virtual machines start up according to customer-driven keys and policies. You can check their use in your key vault using cloud-based key management system or hybrid (bring your key). In some situations, there may be regulatory, policy, or technical reasons why you cannot store keys in a key management system provided by a public cloud service, so you can keep your own key on site.
If you are not using Azure Disk Encryption today, I recommend enabling encryption for maximum security. Learn more Azure disc Encryption, check next article to get started.
I was recently involved in enabling disk encryption for several Azure IaaS Windows virtual machines and everything went as expected.
One day I noticed that one of the Windows VMs Standard A-level does not start. When I checked Start-up diagnostics, I found the following message:
Connect a USB drive with a BitLocker key.
This issue may occur if the virtual machine cannot find the BitLocker Recovery Key (BEK) files to decrypt, or if for some reason the BitLocker keys were removed from the “Bek Volume” section of the virtual machine.
BitLocker encryption keys (BEKs) are used to encrypt operating system boot volume and data volumes. The BEKs are protected in the key case as secrets. Microsoft has a detailed document troubleshooting BitLocker startup errors on the Azure virtual machine here. If the BEK files were missing, you can simply stop and share the virtual machine and restart it. This action forces the virtual machine to retrieve the BEK file from Azure Key Vault and then place it on the encrypted disk. However, none of the solutions mentioned in the troubleshooting guide worked for me …
After digging the logs, I found out that this virtual machine was automatically moved again at midnight due to an unexpected error on the host server of the Azure data center !!!
The automatic recovery feature was triggered by a hardware problem on the physical node hosting the virtual machine. As planned, the virtual machine was automatically moved to another and healthy physical node to avoid new effects. So all requests for services running inside the virtual machine may have failed during this time. This behavior is known as Improving service – Automatic recovery of virtual machines built into the Azure platform. For more information about Azure AutoRecover, read on next article.
To ensure a better level of security and redundancy for your application in Azure, it is recommended to group at least two virtual machines availability set. However, this virtual machine is not a task-critical workload, which is why it was not a part availability set.
I contacted the Azure team because this is weird behavior. After investigation, they found that standard-sized and encrypted virtual machines have a known problem. The virtual machine in question is a Standard_A2_v2 it does not support first-class storage, and this can cause a problem. However, the size of my regular virtual machine is a fully supported scenario to enable disk encryption. If you want to understand the disk encryption requirements and limitations, check next article.
As you type this issue, you must change the target size of the virtual machine that supports Premium storage so that the virtual machine can boot and then resize it back to standard mode later.
To resolve this issue, follow these steps:
- Despite this, a backup of this virtual machine already exists, but I would rather be safe than sorry and I would also have Snapshot created on the virtual machine. You can use Azure Portal to create a snapshot for all virtual machines connected to this virtual machine, or use PowerShell New AzSnapshot cmdlet.
- Next, you need to change the size of the Azure Portal virtual machine to this disk size that it supports Premium storage. You can always resize this back when the virtual machine has been successfully booted after resizing it. For a list of general-purpose virtual machine sizes and whether they support Premium storage, see here.
- Before resizing a virtual machine, navigate to that virtual machine and Stop (share it.
- Choose “Size“From the navigation bar on the left and select one of the supported sizes Premium storage.
- Once the virtual machine has been resized successfully (do not make changes to the disks, leave them as Ordinary hard drive).
- When the size of the virtual machine is successful, restart the virtual machine. When the virtual machine is fully booted, try RDP to the virtual machine. Note that the virtual machine may need to be restarted if an RDP connection cannot be established.
- Finally, you can resize the virtual machine back Standard size A without stopping. The virtual machine will restart automatically and you should be able to run the RDP on the machine successfully! Note that if you decide to resize the virtual machine back Standard size A, then select the size previously assigned to it, and not a different A-size, in my case it is Standard_A2_v2.
Last but not least, Microsoft is actively working to investigate this issue to find the cause and find a lasting solution. Standard size A VMs with disk encryption.
Thanks to the Azure team for helping me get to the bottom of this.
Hope this helps someone out there!
Thanks for locking my blog.
If you have any questions or feedback, please leave a comment.