Hyper-V to Azure ASR Replication and Bitlocker Drives

Hello, I've recently started using Azure ASR as a DR solution. We have one customer that requires us to host their data separate from our other data and to keep it encrypted. I've got their data on it's own VHD and it is encrypted with Bitlocker.

I set up out Hyper-V server to replicate to Azure and upon testing the failover I discovered that the encrypted drive is there but there is no data present. I've asked on the MSDN forums and the answer I got was that Bitlocker is not supported with ASR.

My dilemma is I've got to have this drive encrypted but I need to replicate it to and have it available for failover in ASR. Does anyone have any thoughts on this?

David MundtDirector of Information TechnologyAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
The MS article stated not supported too and I believe it is not straightforward for HDD encryption since the DR will also means the bitlocker crypto keys (including recovery) has to DR over and this is definitely going to be thought through thoroughly . Also Bitlocker using tpm is most secure but can be challenging when VHD virtual instance has to be h/w binding - I think it is tough since we are talking of such security h/w are not supposed to be duplicated and tamperproof with secure firmware ...

Azure virtual machines      

Virtual machines you want to protect should conform with Azure prerequisites.
Disk count—A maximum of 31 disks can be supported on a single protected server
Disk sizes—Individual disk capacity shouldn't be more than 1023 GB
Clustering—Clustered servers aren't supported
Boot—Unified Extensible Firmware Interface(UEFI)/Extensible Firmware Interface(EFI) boot isn't supported

Volumes—Bitlocker encrypted volumes aren't supported

Server names—Names should contain between 1 and 63 characters (letters, numbers and hyphens). The name must start with a letter or number and end with a letter or number. After a machine is protected you can modify the Azure name.
Source machines must comply with Azure VM requirements:

Disc count: maximum of 32 disks per protected source machine
Individual disk capacity of no more than 1023 GB
Clustered servers not supported
UEFI/EFI boot not supported
BitLocker encrypted volumes not supported
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
What version of Hyper-V on-premises? Are the VMs gen 1 or gen 2?

When the VM is spooled up in Azure do you get the BitLocker Recovery Key black screen prompt?

Is the BitLocker AD management component enabled?
btanExec ConsultantCommented:
To clarify -  Basically, BitLocker is not supported because there is no way for Azure to handle the key management portion of the Virtual Machine startup. Since Azure consists of multiple physical servers, there is not a good way to manage your BitLocker keys until now.

However, Azure cloud platform does support at-rest encryption of Windows Server VM data volumes via BitLocker. This requires to attach at least one data disk to your Azure VM. BitLocker is supported for Azure VM data disks, but it is not natively supported for operating system disks.

You may want to check CloudLink which has the capability to manage the BitLocker keys for you so that you can encrypt your data at rest using BitLocker while still using the Microsoft Azure Public Cloud infrastructure.  Specifically, Cloudlink is capable to encrypt their virtual machine data on a multi-tenant shared infrastructure and full control of the encryption keys for their data on the Azure storage infrastructure.

But for info - if the encryption is the data volume, and done correctly, even the attached data disk done in the DR site may differs from what is originally attached, this complicates.

The norm for automatic unlocking of data volumes upon startup is to identify and permit an AD user account that will be used as an additional BitLocker protector. In this case is F: data volume (so is this existing in the DR e.g. what is the status of "Get-BitLockerVolume F:" ?)
# Add an AD user account as an additional BitLocker protector
Add-BitLockerKeyProtector F: `
    -ADAccountOrGroupProtector `
    -ADAccountOrGroup "CONTOSO\BitLockerAdmin"
To automatically unlock BitLocker-protected volumes at VM startup, you can register this script to run as a startup task under the credentials used as the AD account protector above.
Register-ScheduledJob `
    -Name UnlockAtStartup `
    -FilePath C:\unlock.ps1 `
    -Credential (Get-Credential CONTOSO\BitLockerAdmin) `
    -MaxResultCount 30 `
    -ScheduledJobOption `
        (New-ScheduledJobOption –DoNotAllowDemandStart) `
    -Trigger `
        (New-JobTrigger –AtStartup)
Sidenote - if your VM will be running other services that will be storing data on the BitLocker-protected data volume, those services will need to start after this startup task unlocks the volume.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.