Azure Policy blocking Storage Account ARM migration

I just had to migrate a Storage Account from ASM to ARM, and ran into some issues while doing this. This time the error was a bit difficult to figure out, because the Validate step completed successfully, but the Prepare step failed with “internal server error”.

&lt;br&gt;<br>
$storageAccountName = 'storagename'&lt;br&gt;<br>
$validation = Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName&lt;br&gt;<br>
$validation.ValidationMessages&lt;br&gt;<br>
ResourceType       : Storage&lt;br&gt;<br>
ResourceName       : storagename&lt;br&gt;<br>
Category           : Information&lt;br&gt;<br>
Message            : Storage Account storagename is eligible for migration.&lt;br&gt;<br>
VirtualMachineName :&lt;br&gt;<br>
Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName&lt;br&gt;<br>
Move-AzureStorageAccount : InternalError : The server encountered an internal error. Please retry the request.&lt;br&gt;<br>
At line:1 char:1&lt;br&gt;<br>
+ Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccount ...&lt;br&gt;<br>
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~&lt;br&gt;<br>
    + CategoryInfo          : CloseError: (:) [Move-AzureStorageAccount], ComputeCloudException&lt;br&gt;<br>
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.StorageServices.MoveStorageAccountCommand&lt;br&gt;<br>

After some mails back and forth with Azure Support they engaged with engineering who could tell that one of our Azure Policies blocked the migration. Specifically, we had assigned a policy that blocks creation of new storage accounts, if they they allow HTTP access to blobs. The policy is built-in and named “Ensure https traffic only for storage account”.

After disabling the policy, I was able to migrate the Storage Account, enable HTTPS only traffic, and assign the policy again.

0  

Azure VM Restore Job Progress

If you’ve ever had to restore af VM in Azure, you might have looked around for some information regarding the progress of the job. It’s pretty much standard for backup products, to show how far the job is, ETA etc, but not yet in Azure. There is however a way to check this, with quite accurate data.

When you restore a VM, the disks are transferred to a storage account – even when you use Managed Disks. In this storage account, you can browse to the blobs, and if you check the metadata, you will see something like this:

image

And if you copy the data:

<VhdTransferStatus_V2015_01 xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.datacontract.org/2004/07/Microsoft.Internal.CloudBackup.Common.DiffCopy.Interface”>
<DetailedErrorCode i:nil=”true” />
<ErrorCode>0</ErrorCode>
<m_ChunkStatus>
<ChunkStatusEntity>
<m_Length>549218942976</m_Length>
<m_OffsetToStartFromInChunk>81604378624</m_OffsetToStartFromInChunk>
<m_StartOffset>0</m_StartOffset>
<m_TransfersIssuedOffset>83105939456</m_TransfersIssuedOffset>
</ChunkStatusEntity><ChunkStatusEntity>
<m_Length>549218943488</m_Length>
<m_OffsetToStartFromInChunk>631360192512</m_OffsetToStartFromInChunk>
<m_StartOffset>549218942976</m_StartOffset>
<m_TransfersIssuedOffset>633885163520</m_TransfersIssuedOffset>
</ChunkStatusEntity>
</m_ChunkStatus>
<m_DetailedErrorCode i:nil=”true” />
<m_ErrorCode>0</m_ErrorCode>
<m_IcChecker16KBChecksumBlobsIndexToStartFrom>0</m_IcChecker16KBChecksumBlobsIndexToStartFrom>
<m_IcChecker4MBChecksumBlobsOffsetToStartFrom>0</m_IcChecker4MBChecksumBlobsOffsetToStartFrom>
<m_IcCheckerDataBlobsCheckPointData i:nil=”true” />
<m_IcrementalIcChecker16KBChecksumBlobsCheckPoint i:nil=”true” />
<m_IcrementalIcChecker4MBChecksumBlobsCheckPoint i:nil=”true” />
<m_IcrementalIcCheckerDataBlobsCheckPoint i:nil=”true” />
<m_IsIR>true</m_IsIR>
<m_MessageQueueTime>PT3M0.4366027S</m_MessageQueueTime>
<m_Num16KBBlocksTransferred>9940224</m_Num16KBBlocksTransferred>
<m_NumBlocksMismatched>261889</m_NumBlocksMismatched>
<m_NumBlocksProcessed>261889</m_NumBlocksProcessed>
<m_NumBlocksTransferred>39040</m_NumBlocksTransferred>
<m_NumOfChunks>2</m_NumOfChunks>
<m_PercentageCompleted>14</m_PercentageCompleted>
<m_SnapshotTime>4/11/2018 1:39:30 AM</m_SnapshotTime>
<m_StartTimeForBackup>2018-04-11T17:04:22.4366027Z</m_StartTimeForBackup>
<m_State>Processing</m_State>
<m_TimeTakenForBackup>PT1H26M39.56091S</m_TimeTakenForBackup>
<m_TimeTakenForCompleteBackupCycle>PT1H26M39.56091S</m_TimeTakenForCompleteBackupCycle>
<m_TotalNumBlocks>261889</m_TotalNumBlocks>
<m_Version>V2015_01</m_Version>
</VhdTransferStatus_V2015_01>

Here you can see how many 16KB blocks has been transferred (m_Num16KBBlockTransferred), and the percentage of the complete transfer (m_PercentageCompleted). In this case I know 960 GB of the disk is used, so by doing a few calculations, I can confirm that the percentage is somewhat accurate. It’s good enough for me, at least until we can get the information directly in the backup jobs ;-)

You can also use PowerShell to get this data:

$resourceGroupName = "resource group name"
$storageAccName = "storage account name"
$vhdContainer = "vhd container name"
$storageAcc = Get-AzureRMStorageAccount -Name $storageAccName -ResourceGroupName $resourceGroupName
[XML]$metadata = (Get-AzureStorageBlob -Container $vhdContainer -Context $storageAcc.Context)[1].ICloudBlob.Metadata.Values
$metadata.DocumentElement.m_PercentageCompleted

In the above code, I have 2 blobs, but only wanted a status for the 2nd one – and I reference this by using [1] in the Get-AzureStorageBlob line.

0