Azure Disk Encryption (ADE) vs Storage Service Encryption (SSE)

When talking about VM data encryption a lot of customers start looking at Azure Disk Encryption (ADE) and Storage Service Encryption (SSE).  These two offerings are similar, but unique.  Whether you stick with SSE (always enabled) or add ADE on top is up to you – really it depends on your security needs and design.

Below is my quick breakdown of the pros and cons to help you decide what is the best design for your organization.

SSE (default)


and thanks for Eric Marks for raising this question!

Using Azure CLI 1.0 to Copy a File between Subscriptions

note: examples are from the Azure Government cloud but the command used will work in all clouds


Goal: Use Azure CLI 1.0 to copy a blob file between to different subscriptions

Syntax:  azure storage blob copy start “sourceSAS” destContainer -a destStorageAccount -k destStorageKey

Example: azure storage blob copy start “” vhds –a secondstorage -k zcSRtkJO9LzJuiYbOgoRW6Fgr3lS7lIFIEvIb3hbzJ62XBmZl5Igg1zfogNee8FtwGNGoJ6ADr7kAls6b+wJNQ==

note: the SAS and storage account key are used for access to the storage accounts, subscription access is not required to execute this command.


Now let’s break it down….here’s how you gather each of the required inputs.

1.  SourceSAS – the SAS is the source file URL + the Shared Access Signature (SAS).  For example if your source URL is and your SAS Token is ?sv=2016-05-31&ss=bfqt&srt=sco&sp=rwdlacup&se=2017-05-16T06:59:23Z&st=2017-05-15T22:59:23Z&spr=https&sig=lyzka%2F3ID1qFhLeoxlDcjBpNuHDB001qWL0ubiD66wo%3D your SourceSAS is  Note: There are no spaces when you join the two items and you’ll need to put the string in quotes when used in AzureCLI.

  • Source URL – there are a few ways to get this, but the simplest is via the portal.  Browse to your storage account –> blob –> your container –> your file.  A new blade opens and the URL is the second item listed.


  • SAS – again the simplest way to generate the SAS token is via the portal.  Browse to your storage account –> Shared Access Signature, update the values (the default will work, but it’s more secure to restrict the SAS Token to only the time frame and resources needed), and then click “Generate SAS”


2.  Destination container – this is the name of the container only (not a URL) that already exists in the destination storage account

3.  Destination Storage Account – this is the name of the storage account only (not a URL) that already exists in the destination subscription

4.  Destination Storage Access Key – there are a few ways to get this, but the simplest is via the portal.  Browse to your storage account –>Access Keys and copy either key1 or key2.

…and a special thanks to Madan Nagarajan for his sourceSAS breakthrough!


*previously posted at

Working with Azure ARM VMs, Images, and Unmanaged Disk (Storage Accounts)

A lot of the pre-managed disk documentation has become hard to find.  Below is a cheat-sheet on where to find the documents you need to work with Azure ARM VMs, images, and storage accounts.

Create an Azure VM from custom image (VHD) –

Create an Azure VM from existing VHD –

Create an Azure VM Image (and VM) from existing Azure VM –

*previously posted at

Moving files between Azure Storage and RHEL

There are several options when you want to move files in or out of an Azure Storage account to a Red Hat Linux (RHEL) server.  Below is a quick break down of the most commonly used options.

Azure CLI

Azure CLI is design to run on Linux or Windows so is the ideal tool when a Linux machine is involved.  Azure CLI 2.0 ( is the latest and preferred version.  See for syntax.


#Start the copy of the blob

az storage blob copy start –account-name ${storage_account} –account-key ${key} –source-account-name ${source_account} –source-account-key ${source_key} –source-container ${blob_container} –source-blob ${blob_name} –destination-container $target_container –destination-blob $target_blob_name

#Now wait while this copy happening. This could take a while.

while [ $(az storage blob show –account-name ${storage_account} –account-key ${key} –container-name $target_container –name $target_blob_name| jq .properties.copy.status| tr -d ‘”‘) == “pending” ]; do

progress=$(az storage blob show –account-name ${storage_account} –account-key ${key} –container-name ${target_container} –name ${target_blob_name} | jq -r .properties.copy.progress)

done_count=$(echo $progress | sed ‘s,\([0-9]*\)/\([0-9]*\),\1,g’)

total_count=$(echo $progress | sed ‘s,\([0-9]*\)/\([0-9]*\),\2,g’)

progress_percent=$((100 * $done_count / $total_count))

echo “Copying: $progress ($progress_percent %)” && sleep 5


echo “Copying done”


AzCopy on Linux is a command-line utility designed for copying data to/from Azure Blob and File storage using simple commands.  See  Specific steps for the file copy are here.

To Install on RHEL, you first need to install .NET Core 1.1.1

  1. sudo yum install rh-dotnetcore11
  2. scl enable rh-dotnetcore11 bash
  3. source scl_source enable rh-dotnetcore11

Then you install AzCopy per the article.

  1. wget -O azcopy.tar.gz
  2. tar -xf azcopy.tar.gz
  3. sudo ./

Example from RHEL 7.4:



The final approach is to downloading is to generate a SAS token, append it to the blob URL and simply use wget in Linux.

See for details on how to generate the SAS token and append it to the the blob URL (aka, “sourceSAS”).


*previously posed on