Maintaining on-premises drive letters for VMs protected by ASR

Scenario
You have a virtual machine running on-premises and all applications have been installed on the D drive. This machine is protected by Azure Site Recovery and in the event that the machine is failed over to Azure, the drive letters must remain the same.

Problem
By default Azure virtual machines are assigned temporary storage and the normal behaviour is for this to assign itself to the drive letter D. Under this scenario the on-premises D drive would then be assigned the next free drive letter of E as the virtual machine powers up in Azure. Obviously this would have massive impact on the applications running on this virtual machine.

For more information on the temporary storage added to Azure virtual machines have a look at this article What is this temporary storage?

Solution
It is possible to make sure that drive letters are maintanted when on-premises virtual machine failover to Azure, forcing the temporary storage to append itself at the end. To do this we need to set the SAN policy to “OnlineAll

To view the current SAN policy from the guest system, follow these steps:

1. On the VM (not on the host server), open an elevated Command Prompt window.
2. Type diskpart.
3. Type SAN.

SANpolicy001

If the drive letter of the guest operating system is not maintained, this command returns either “Offline All” or “Offline Shared.”

To make sure that all disks are brought online and are both readable and writeable, set the SAN policy to OnlineAll. To do this, run the following command at the DISKPART prompt:

SAN POLICY=ONLINEALL

SANpolicy002

NOTE: One thing to keep in mind is that even when this change has been made to the local running virtual machine, you need to make sure that this change has been replicated to ASR as part of the next recovery point, before attempting a failover.

As a final check, it would be worth running a test failover to verify that the drive letters are preserved as required.

For more information about SAN policy, see this Azure Support Team Blog article

Leave a Reply

Your email address will not be published. Required fields are marked *