Performance Tiers

When creating a storage account, you must choose between the Standard and Premium performance tiers. This setting cannot be changed later.

• Standard This tier supports all storage services: blobs, tables, files, queues, and unmanaged Azure virtual machine disks. It uses magnetic disks to provide cost-efficient and reliable storage.

• Premium This tier is designed to support workloads with greater demands on I/O and is backed by high performance SSD disks. They only support page blobs, and do not support the other storage services. In addition, Premium storage accounts only support the locally-redundant (LRS) replication option, and do not support access tiers.

Replication options

When you create a storage account, you can also specify how your data will be replicated for redundancy and resistance to failure. There are four options, as described in Table 2-1.

Table 2-1 Storage account replication options

Access tiers

Azure blob storage supports three access tiers: Hot, Cool, and Archive. Each represents a tradeoff of performance, availability, and cost. There is no trade-off on the durability (probability of data loss) which is extremely high across all tiers.

The tiers are as follows:

• Hot This access tier is optimized for the frequent access of objects in the storage account. Relative to other tiers, data access costs are low while storage costs are higher.

• Cool This access tier is optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days. The availability SLA is lower than for the hot tier. Relative to the Hot tier, data access costs are higher and storage costs are lower.

• Archive This access tier is designed for long-term archiving of infrequently-used data that can tolerate several hours of retrieval latency, and will remain in the Archive tier for at least 180 days. This tier is the most cost-effective option for storing data, but accessing that data is more expensive than accessing data in the Hot or Cool tiers.

There is a fourth tier, Premium, providing high-performance access for frequently-used data, based on solid-state disks. This tier is now available at: https://azure.microsoft.com/blog/azure-premium-block-blob-storage-is-now-generally-available/. It is only available from the Block Blob storage account type.

Table 2-2 compares the key features of each of the Hot, Cool, and Archive blob storage access tiers.

Table 2-2 Blob storage access tiers

When using Azure storage, a default access tier is defined at the storage account level. This default must be either the Hot or Cool tier (not the Archive tier). Individual blobs can be assigned to any access tier, regardless of the account-level default. For Archive, there is only support for block blobs without any snapshots (A blob block that has snapshots cannot be re-tiered).

Account Kind

Another storage account setting is the account kind. There are three possible values: general-purpose v1, general-purpose v2, and blob storage. The features of each kind of account are listed in Table 2-3. Key points to remember are:

• The blob storage account is a specialized storage account used to store block blobs and append blobs. You can’t store page blobs in these accounts, therefore you can’t use them for unmanaged disks.

• Only general-purpose v2 and blob storage accounts support the hot, cool and archive access tiers.

• Only general-purpose v2 accounts support zone-redundant (ZRS) storage.

General-purpose v1 and blob storage accounts can both be upgraded to a general-purpose v2 account. This operation is irreversible. No other changes to the account kind are supported.

Table 2-3 Storage account types and their supported features

Creating an Azure Storage Account (Portal)

To create a storage account by using the Azure portal, first click Create a resource and then select Storage. Next click Storage account, which will open the Create storage account blade (Figure 2-1). You must choose a unique name for the storage account name. Storage account names are more restrictive than for other resources types—the name must be globally unique, and can contain lower-case characters and digits only. Select the Azure region (Location), the performance tier, the kind of storage account, the replication mode, and the access tier. The blade adjusts based on the settings you choose so that you cannot select an unsupported feature combination.

The Advanced tab of the Create storage account blade is shown in Figure 2-2. This tab allows you to specify whether SSL is required for accessing objects in storage, access from all or a specific virtual network, as well as a preview feature for Data Lake Storage integration. Clicking the Tags tab allows you to specify tags on the storage account resource.

Creating an Azure Storage Account (PowerShell)

The New-AzStorageAccount cmdlet is used to create a new storage account using Azure PowerShell. The cmdlet requires the ResourceGroupName, Location, and SkuName parameters to be specified, although you can also specify the account kind and access tier using the Kind and AccessTier parameters. If Kind is not specified, a general purpose v1 account is created by default.

The following PowerShell script creates a new resource group called ExamRefRG using the New-AzResourceGroup cmdlet and then creates a new storage account using the New-AzStorageAccount cmdlet.

Click here to view code image

$resourceGroup = "ExamRefRG"
$accountName   = "mystorage112300"
$location      = "WestUS"
$sku           = "Standard_LRS"
$kind          = "StorageV2"
$tier          = "Hot" 
New-AzResourceGroup -Name $resourceGroup -Location $location
New-AzStorageAccount -ResourceGroupName $resourceGroup `
            -Name $accountName `
            -SkuName Standard_LRS `
            -Location $location `
            -Kind $kind `
            -AccessTier $tier

When creating a storage account with PowerShell you can specify several additional options such as custom domains using the CustomDomainName parameter, and optionally also the UseSubDomain switch if using the intermediary method of registering custom domains (for further information, see: https://docs.microsoft.com/azure/storage/blobs/storage-custom-domain-name). You can also specify whether to require HTTPS/SSL by specifying EnableHttpsTrafficOnly, assign a network rule set for virtual network access by passing a set of firewall and network rules using the NetworkRuleSet parameter, and automatically create and assign an identity to manage keys in Azure KeyVault using the AssignIdentity parameter.

The Set-AzStorageAccount cmdlet is used to update an existing storage account. In this next example the storage account access tier is changed to Cool. The Force parameter is specified to avoid a prompt notifying that changing the access tier may result in price changes.

Click here to view code image

Set-AzStorageAccount -ResourceGroupName $resourceGroup `
            -Name $accountName `
            -AccessTier Cool `
            -Force

Creating an Azure Storage Account (CLI)

The az storage account create command is used to create an Azure Storage Account using the Azure CLI. This next example shows an Azure CLI script which creates a new resource group called ExamRefRG using the az group create command and then creates a new storage account using the az storage account create command. Note that this won't run in a PowerShell prompt with the Azure CLI installed without Bash variables.

Click here to view code image

resourceGroup="ExamRefRG"
accountName="mystorage112301"
location="WestUS"
sku="Standard_LRS"
kind="StorageV2"
tier="Hot"
az group create -l $location --name $resourceGroup
az storage account create --name $accountName –resourceg-roup $resourceGroup --location
$location --sku $sku

Similar to creating a storage account using PowerShell, there are several optional parameters that allow you to control additional account options such as custom domains using the custom-domain parameter, whether to require HTTPS/SSL by specifying https-only, and to automatically create and assign an identity to manage keys in Azure KeyVault using the assign-identity parameter.

Install and use Azure Storage Explorer.

Azure Storage Explorer is a cross-platform application designed to help you quickly manage one or more Azure storage accounts. It can be used with all storage services: blobs, tables, queues and files. In addition, Azure Storage Explorer also supports the CosmosDB and Azure Data Lake Storage services

You can install Azure Storage Explorer by navigating to its landing page on https://azure.microsoft.com/features/storage-explorer/ and selecting your operating system choice out of Windows, macOS, or Linux.

In addition, a version of Storage Explorer with similar functionality is integrated into the Azure portal. To access, simply click Storage Explorer (Preview) from the storage account blade.

Connecting Storage Explorer to Storage Accounts

After Storage Explorer is installed, you can connect to Azure storage in one of five different ways (shown in Figure 2-3):

• Add an Azure Account This option allows you to sign in using a work or Microsoft account and access all of your storage accounts via role-based access control.

• Using a connection string This option requires you to have access to the connection string of the storage account. The connection string is retrievable by opening the storage account blade in the Azure portal and clicking on Access keys.

• Using a storage account name and key This option requires you to have access to the storage account name and key. These values can also be accessed from the Azure portal under Access keys.

• User a shared access signature URI A shared access signature provides access to a storage account without requiring an account key to be shared. Access can be restricted, for example to read-only access for blob storage for one week only.

• Attach to a local emulator Allows you to connect to the local Azure storage emulator as part of the Microsoft Azure SDK.

After connecting, you then filter on which subscriptions to use. Once you select a subscription, all of the supported services within the subscriptions will be made available. Figure 2-4 shows an expanded Azure Storage Account named mystorage112300.

Using Storage Explorer

Using Storage Explorer, you can manage each of the storage services: blobs, tables, queues and files. Table 2-4 summarizes the supported operations for each service.

Table 2-4 Storage Explorer Operations

In each case Azure Storage Explorer provides an intuitive GUI interface for each operation.

Storage Firewall

The storage firewall is used to control which IP address and virtual networks can access the storage account. It applies to all storage account services (blobs, tables, queues and files). For example, by limiting access to the IP address range of your company, access from other locations will be blocked.

To configure the storage firewall using the Azure portal, open the storage account blade and click Firewalls And Virtual Networks. Click to allow access from Selected Networks to reveal the firewall and virtual network settings, as shown in Figure 2-5.

When accessing the storage account via the Internet, use the storage firewall to specify the Internet-facing source IP addresses that will make the storage requests. You can specify a list of either individual IPv4 addresses or IPv4 CIDR address ranges (CIDR notation is explained in the chapter on Azure Networking).

The storage firewall includes an option to allow access from trusted Microsoft services. These services include Azure Backup, Azure Site Recovery, and Azure Networking, for example to allow access to storage for NSG flow logs. There are also options to allow read-only access to storage metrics and logs.

Virtual Network Service Endpoints

In some scenarios, a storage account is only accessed from within an Azure virtual network. In this case, it is desirable from a security standpoint to block all Internet access. Configuring Virtual Network Service Endpoints for your Azure storage accounts allows you to remove access from the public Internet, and only allow traffic from a virtual network for improved security.

Another benefit of using service endpoints is optimized routing. Service endpoints create a direct network route from the virtual network to the storage service. This is important when forced tunneling is used to direct outbound Internet traffic from the virtual network via an on-premises network security device. Without service endpoints, access from the virtual network to the storage account would also be routed via the on-premises network, adding significant latency. With service endpoints, the direct route to the storage account takes precedence over the on-premises route, so no additional latency is incurred.

Configuring service endpoints requires two steps. First, from the virtual network subnet, specify Microsoft.Storage in the service endpoint settings. This creates the route from the subnet to the storage service but does not restrict which storage account the virtual network can use. Figure 2-6 shows the subnet settings, including the service endpoint configuration.

The second step is to configure which virtual networks can access a particular storage account. From the storage account blade click Firewalls And Virtual Networks. Click to allow access from Selected Networks to reveal the firewall and virtual network settings, as already seen in Figure 2-5. Under Virtual networks, select the virtual networks and subnets which should have access to this storage account. To further restrict access, the storage firewall can be configured with private IP addresses of specific virtual machines.

Blob storage access levels

Storage accounts support an additional access control mechanism, limited only to blob storage. By default, no public read access is enabled for anonymous users, and only users with rights granted through role-based access control (RBAC), or with the storage account name and key, will have access to the stored blobs. To enable anonymous user access, you must change the container access level. The supported levels are as follows:

• No public read access The container and its blobs can be accessed only by the storage account owner. This is the default for all new containers.

• Public read-only access for blobs only Blobs within the container can be read by anonymous request, but container data is not available. Anonymous clients cannot enumerate the blobs within the container.

• Full public read-only access All container and blob data can be read by anonymous request. Clients can enumerate blobs within the container by anonymous request but cannot enumerate containers within the storage account.

You can change the access level through the Azure portal, Azure PowerShell, Azure CLI, programmatically using the REST API, or using Azure Storage Explorer. The access level is configured separately on each blob container.

A Shared Access Signature token (SAS token) is a URI query string parameter that grants access to specific containers, blob, queues, and tables. Use a SAS tokens to grant access to a client that should not have access to the entire contents of the storage account (and therefore should not have access to the storage account keys), but still requires secure authentication. By distributing a SAS URI to these clients, you can grant them access to a specific resource, for a specified period of time, with a specified set of permissions.

Managing Access Keys in Azure Key Vault

It is important to protect the storage account access keys because they provide full access to the storage account. Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services, such as authentication keys, storage account keys, data encryption keys and certificate private keys.

The following example shows how to create an Azure Key Vault and then securely store the key in Azure Key Vault (using software protected keys) using PowerShell.

Click here to view code image

$vaultName = "[key vault name]"
$rgName = "[resource group name]"
$location = "[location]"
$keyName = "[key name]"
$secretName = "[secret name]"
$storageAccount = "[storage account]"
# create the key vault 
New-AzKeyVault -VaultName $vaultName -ResourceGroupName $rgName -Location $location
# create a software managed key
$key = Add-AzKeyVaultKey -VaultName $vaultName -Name $keyName -Destination 'Software'
# retrieve the storage account key (the secret)
$storageKey = Get-AzStorageAccountKey -ResourceGroupName $rgName -Name $storageAccount
# convert the secret to a secure string
$secretvalue = ConvertTo-SecureString $storageKey[0].Value -AsPlainText -Force
# set the secret value
$secret = Set-AzKeyVaultSecret -VaultName $vaultName -Name $secretName -SecretValue
$secretvalue

The same capabilities exist with the Azure CLI tools. In the following example, the az keyvault create command is used to create the Azure KeyVault. From there, the az keyvault key create command is used to create the key. Finally, the az keyvault secret set command is used to set the secret value.

Click here to view code image

vaultName="[key vault name]"
rgName="[resource group name]"
location="[location]"
keyName="[key name]"
secretName="[secret name]"
storageAccount="[storage account]"
secretValue="[storage account key]"
# create the key vault
az keyvault create --name "$vaultName" --resource-group "$rgName" --location "$location"
# create a software managed key
az keyvault key create --vault-name "$vaultName" --name $keyName --protection "software"
# set the secret value
az keyvault secret set --vault-name "$vaultName" --name "$secretName" --value
"$secretValue"

Keys in Azure Key Vault can be protected in software or by using hardware security modules (HSMs). HSM keys can be generated in place or imported. Importing keys is often referred to as bring your own key, or BYOK.

Accessing and unencrypting the stored keys is typically done by a developer, although keys from Key Vault can also be accessed from ARM templates during deployment.

Using shared access signatures

Each SAS token is a query string parameter that can be appended to the full URI of the blob or other storage resource the SAS token was created for. Create the SAS URI by appending the SAS token to the full URI of the blob or other storage resource.

The following example shows the combination in more detail. Suppose the storage account name is ‘examrefstorage’, the blob container name is ‘examrefcontainer1’, and the blob path is ‘sample-file.png’. The full URI to the blob in storage is then:

Click here to view code image

https://examrefstorage.blob.core.windows.net/examrefcontainer1/sample-file.png

The combined URI with the generated SAS token is:

Click here to view code image

https://examrefstorage.blob.core.windows.net/examrefcontainer/sample-file.png?sv=2018-
03-28&sr=b&sig=%2B6TEOoJyT5EAL3HF9OhApxnPOXNWHUeAPZosRaBZBG4%3D&st=2018-12-
09T20%3A37%3A01Z&se=2018-12-10T00%3A37%3A01Z&sp=rwd

Using a stored access policy

A standard SAS token incorporates the access parameters (start and end time, permissions, etc) as part of the token. The parameters cannot be changed without generating a new token, and the only way to revoke an existing token before its expiry time is to roll over the storage account key used to generate the token Or to delete the blob. These limitations can make standard SAS tokens difficult to manage in practice.

Stored access policies allow the parameters for a SAS token to be decoupled from the token itself. The access policy specifies the start time, end time and access permissions, and is created independently of the SAS tokens. SAS tokens are generated that reference the stored access policy instead of embedding the access parameters explicitly.

With this arrangement, the parameters of existing tokens can be modified by simply editing the stored access policy. Existing SAS tokens remain valid, and use the updated parameters.

An existing token can be deactivated by simply setting the expiry time in the access policy to a time in the past.

Figure 2-10 shows the Azure Storage Explorer creating two stored access policies.

To use the created policies, reference them by name during creation of a SAS token using Storage Explorer, or when creating a SAS token using PowerShell or the CLI tools.

Changing storage account replication mode

Storage accounts can be moved freely between the LRS, GRS, and RA-GRS replication modes. Azure will replicate the data asynchronously in the background as required.

Migrating to or from the ZRS replication mode works differently. The recommended approach is to simply copy the data to a new storage account with the desired replication mode, using a tool such as AzCopy. This may require application downtime. Alternatively, you can request a live data migration via Azure Support.

You can set the replication mode for a storage account after it is created through the Azure portal by clicking the Configuration link on the storage account and selecting the Replication Type (see Figure 2-16).

To change replication mode using the Azure PowerShell cmdlets, use the Type Inline code parameter of New-AzStorageAccount (at creation) or the Set-AzStorageAccount cmdlets (after creation), as shown:

Click here to view code image

$resourceGroup = "[resource group name]"
$accountName = "[storage account name]"
$type        = "Standard_RAGRS"
Set-AzStorageAccount -ResourceGroupName $resourceGroup `
                          -Name $accountName `
                          -SkuName $type

Using the async blob copy service

The async blob copy service is a server-side based service that can copy files you specify from a source location to a destination in an Azure Storage account. The source blob can be located in another Azure Storage account, or it can even be outside of Azure, as long as the storage service can access the blob directly for it to copy. This service does not offer an SLA on when the copy will complete. There are several ways to initiate a blob copy using the async blob copy service.

Async blob copy (PowerShell)

Use the Start-AzStorageBlobCopy cmdlet to copy a file using PowerShell. This cmdlet accepts either the source URI (if it is external), or as the next example next shows, the blob name, container, and storage context to access the source blob in an Azure Storage account. The destination requires the container name, blob name, and a storage context for the destination storage account.

Click here to view code image

$blobCopyState = Start-AzStorageBlobCopy -SrcBlob $blobName `
                       -SrcContainer $srcContainer `
                       -Context $srcContext `
                       -DestContainer $destContainer `
                       -DestBlob $vhdName `
                       -DestContext $destContext

Let’s review the parameters in the preceding example:

• SrcBlob Expects the file name of source file to start copying.

• SrcContainer Is the container the source file resides in.

• Context Accepts a context object created by the New-AzStorageContext cmdlet. The context has the storage account name and key for the source storage account and is used for authentication.

• DestContainer Is the destination container to copy the blob to. The call will fail if this container does not exist on the destination storage account.

• DestBlob Is the filename of the blob on the destination storage account. The destination blob name does not have to be the same as the source.

• DestContext Also accepts a context object created with the details of the destination storage account, including the authentication key.

Here is a complete example of how to use the Start-AzStorageBlob copy cmdlet to copy a blob between two storage accounts:

Click here to view code image

# Copy blob between storage accounts
# Source account, blob container, and blob must exist
# Destination account must exist. Destination blob container will be created
$blobName           = "[blob name]"
$srcContainer       = "[source container]"
$destContainer      = "[destination container]"
$srcStorageAccount  = "[source storage]"
$destStorageAccount = "[dest storage]"
$sourceRGName       = "[source resource group name]"
$destRGName         = "[destination resource group name]"
# Get storage account keys (both accounts)
$srcStorageKey = Get-AzStorageAccountKey `
  -ResourceGroupName $sourceRGName `
  -Name $srcStorageAccount

$destStorageKey = Get-AzStorageAccountKey `
  -ResourceGroupName $destRGName `
  -Name $destStorageAccount

# Create storage account context (both accounts)
$srcContext = New-AzStorageContext `
  -StorageAccountName $srcStorageAccount `
  -StorageAccountKey $srcStorageKey.Value[0]

$destContext = New-AzStorageContext `
  -StorageAccountName $destStorageAccount `
  -StorageAccountKey $destStorageKey.Value[0]

# Create new container in destination account
New-AzStorageContainer `
  -Name $destContainer `
  -Context $destContext 

# Make the copy
$copiedBlob = Start-AzStorageBlobCopy `
  -SrcBlob $blobName `
  -SrcContainer $srcContainer `
  -Context $srcContext `
  -DestContainer $destContainer `
  -DestBlob $blobName `
  -DestContext $destContext

There are several cmdlets in this example. The Get-AzStorageKey cmdlet accepts the name of a storage account and the resource group it resides in. The return value contains the storage account’s primary and secondary authentication keys in the .Value array of the returned object. These values are passed to the New-AzStorageContext cmdlet, including the storage account name, and the creation of the context object. The New-AzStorageContainer cmdlet is used to create the storage container on the destination storage account. The cmdlet is passed the destination storage account’s context object ($destContext) for authentication.

The final call in the example is the call to Start-AzStorageBlobCopy. To initiate the copy this cmdlet uses the source ($srcContext) and destination context objects ($destContext) for authentication. The return value is a reference to the new blob object on the destination storage account.

Pipe the copied blob object to the Get-AzStorageBlobCopyState cmdlet to monitor the progress of the copy as shown in the following example.

$copiedBlob | Get-AzStorageBlobCopyState

The return value of Get-AzStorageBlobCopyState contains the CopyId, Status, Source, Bytes-Copied, CompletionTime, StatusDescription, and TotalBytes properties. Use these properties to write logic to monitor the status of the copy operation.

Async blob copy (CLI)

The Azure CLI tools support copying data to storage accounts using the async blob copy service. The following example uses the az storage blob copy start command to copy a blob from one storage account to another. The following script gives an example. For authentication, the command requires the storage account name and key for the source (if the blob is not available via public access) and the destination. The storage account key is retrieved using the az storage account keys list command.

Click here to view code image

# Copy blob between storage accounts
# Source account, blob container, and blob must exist
# Destination account and blob container must exist
blobName="[file name]"
srcContainer="[source container]"
destContainer="[destination container]"
srcStorageAccount="[source storage]"
destStorageAccount="[destination storage]"
$srcStorageKey="[source account key]"
$destStorageKey="[destination account key]"
az storage blob copy start 
  --account-name "$destStorageAccount" 
  --account-key "$destStorageKey" 
  --destination-blob "$blobName" 
  --destination-container "$destContainer" 
  --source-account-name "$srcStorageAccount" 
  --source-container "$srcContainer" 
  --source-blob "$blobName" 
    --source-account-key "$srcStorageKey"

After the copy is started, you can monitor the status using the az storage blob show command as shown here:

Click here to view code image

az storage blob show 
   --account-name "$destStorageAccount" --account-key "$destStorageKey" 
   --container-name "$destContainer" --name "$blobName"

Async blob copy (AzCopy)

The AzCopy application can also be used to copy between storage accounts. The following example shows how to specify the source storage account using the /source parameter and / sourcekey, and the destination storage account and container using the /Dest parameter and / DestKey.

Click here to view code image

AzCopy /Source:https://[source storage].blob.core.windows.net/[source container]/
/Dest:https://[destination storage].blob.core.windows.net/[destination container]/
/SourceKey:[source key] /DestKey:[destination key] /Pattern:disk1.vhd

AzCopy offers a feature to mitigate the lack of SLA with the async copy service. The /SyncCopy parameter ensures that the copy operation gets consistent speed during a copy. AzCopy performs the synchronous copy by downloading the blobs to copy from the specified source to local memory, and then uploading them to the Blob storage destination.

Click here to view code image

AzCopy /Source:https://[source storage].blob.core.windows.net/[source container]/
/Dest:https://[destination storage].blob.core.windows.net/[destination container]/
/SourceKey:[source key] /DestKey:[destination key] /Pattern:disk1.vhd /SyncCopy

Async blob copy (Storage Explorer)

The Azure Storage Explorer application can also take advantage of the async blob copy service. To copy between storage accounts, navigate to the source storage account, select one or more files and click the copy button on the tool bar. Then navigate to the destination storage account, expand the container to copy to, and click Paste from the toolbar. In Figure 2-17, the Workshop List – 2017.xlsx blob was copied from examrefstoragesrccontainer to examrefstorage2destcontainer using this technique.

Blob containers

Figure 2-18 shows the layout of the blob storage service. Each storage account can have one or more blob containers and all blobs must be stored within a container. Containers are similar in concept to a hard drive on your computer, in that they provide a storage space for data in your storage account. Within each container you can store blobs, much as you would store files on a hard drive. Blobs can be placed at the root of the container or organized into a folder hierarchy.

Each blob has a unique URL. The format of this URL is as follows:
https://[account name].blob.core.windows.net/[container name]/[blob path and name].

Optionally, you can create a container at the root of the storage account, by specifying the special name $root for the container name. This allows you to store blobs in the root of the storage account and reference them with URLs such as:
https://[account name].blob.core.windows.net/fileinroot.txt.

Understanding blob types

Blobs come in three types, and it is important to understand when each type of blob should be used and what the limitations are for each.

• Page blobs A Optimized for random-access read and write operations. Page blobs are used to store virtual disk (VHD) files which using unmanaged disks with Azure virtual machines. The maximize page blob size is 8 TB.

• Block blobs Optimized for efficient uploads and downloads, for video, image and other general-purpose file storage. The maximum block blob size is slightly over 4.75 TB.

• Append blobs Optimized for append operations, and do not support modification of existing blob contents. Page blobs are most commonly used for log files. Up to 50,000 blocks can be added to each append blob, and each block can be up to 4MB in size, giving a maximum append blob size of slightly over 195 GB.

Blobs of all three types can share a single blob container.

Managing blobs and containers (Azure portal)

You can create and manage containers through the Azure Management Portal, Azure Storage Explorer, third-party storage tools, or through the command line tools. To create a container in the Azure Management Portal, open a storage account by clicking All Services, then Storage Accounts, and choose your storage account. Within the storage account blade, click the Blobs tile, and then click the + Container button, as shown in Figure 2-19. See Skill 2.1 for more information on setting the public access level.

After a container is created, you can also use the portal to upload blobs to the container as demonstrated in Figure 2-20. Click the Upload button in the container and then browse to the blob to upload. If you click the Advanced button you can select the blob type (Blob, Page or Append), the block size, and optionally a folder to upload the blob to.

Managing blobs and containers (PowerShell)

To create a container using the Azure PowerShell cmdlets, use the New-AzStorageContainer cmdlet. The access tier is specified using the Permission parameter.

To create a blob within an existing container, use the Set-AzStorageBlobContent cmdlet.

Both New-AzStorageContainer and Set-AzStorageBlobContent require a storage context, which specifies the storage account name and authentication credentials (for example access keys or SAS token). A storage context can be created using the New-AzStorageContext cmdlet. The context then can be passed explicitly when accessing the storage account, or implicitly by storing the context using the Set-AzCurrentStorageAccount cmdlet.

The following PowerShell script shows how to use these cmdlets to get the account key, create and store the storage context, then create a container and upload a local file as a blob.

Click here to view code image

$storageAccount = "[storage account name]"
$resourceGroup = "[resource group name]"
$container = "[blob container name]"
$localFile = "[path to local file]"
$blobName = "[blob path]"

# Get account key
$storageKey = Get-AzStorageAccountKey `
  -Name $storageAccount `
  -ResourceGroupName $resourceGroup

# Create and store the storage context
$context = New-AzStorageContext `
  -StorageAccountName $storageAccount `
  -StorageAccountKey $storageKey.Value[0]

Set-AzCurrentStorageAccount -Context $context

# Create storage container
New-AzStorageContainer -Name $container `
  -Permission Off

# Create storage blob
Set-AzStorageBlobContent -File $localFile `
  -Container $container `
  -Blob $blobName

Managing blobs and containers (CLI)

The Azure CLI tools can also be used to create a storage account container with the az storage container create command. The public-access parameter is used to set the permissions. The supported values are off, blob, and container.

Click here to view code image

storageaccount="[storage account name]"
containername="[blob container]"
az storage container create --account-name $storageaccount --name $containername
--public-access off

You can use the Azure CLI to upload a file as well using the az storage blob upload command as shown next

Click here to view code image

container_name="[blob container]"

account_name="[storage account name]"
account_key="[storage account key]"
file_to_upload="[path to local file]"
blob_name="[blob name]"
az storage blob upload --container-name $container_name --account-name $account_name
--account-key $account_key --file $file_to_upload --name $blob_name

Managing blobs and containers (Storage Explorer)

Azure Storage Explorer provides rich functionality for managing storage data, including blobs and containers. To create a container, expand the Storage Accounts node, and expand the storage account you want to use, right-clicking on the Blob Containers node. This will open a new menu item where you can create a blob container as shown in Figure 2-21.

Azure Storage Explorer provides the ability to upload a single file or multiple files at once. The Upload Folder feature provides the ability to upload the entire contents of a local folder, recreating the hierarchy in the Azure Storage Account. Figure 2-22 shows the two upload options.

Managing blobs and containers (AzCopy)

AzCopy is a command line utility that can be used to copy data to and from blob, file, and table storage, and also provides support for copying data between storage accounts. AzCopy is designed for optimal performance, so it is commonly used to automate large transfers of files and folders.

There are currently two versions of AzCopy: one for Windows and one for Linux. The latest preview version, v10, combines Windows, Linux and macOS support in a single release. For more information, see https://docs.microsoft.com/azure/storage/common/storage-use-azcopy-v10.

The following example shows how you can use AzCopy (v10) to download a single blob from a container to a local folder. In this example, a SAS token is used to authorize access.

Click here to view code image

AzCopy copy "https://[source storage].blob.core.windows.net/[source container]/
[path-to-blob]?[SAS]" "[local file path]"

This example shows how you can switch the order of the source and destination parameters to upload the file instead.

Click here to view code image

AzCopy copy "[local file path]" "https://[destination storage]
.blob.core.windows.net/[destination container]/[path-to-blob]?[SAS]"

Soft delete for Azure storage blobs

The default behavior of deleting a blob is that the blob is deleted and lost forever. Soft delete is a feature that allows you to save and recover your data when blobs or blob snapshots are deleted even in the event of an overwrite. This feature must be enabled on the Azure Storage account and a retention period set for how long the deleted data is available (see Figure 2-23).

Configuring CDN endpoints

To publish content in a CDN endpoint, first create a new CDN profile. To do this using the Azure portal click Create a resource, then click Web, then select CDN to open the create CDN profile blade (Figure 2-25). Provide a name for the CDN profile, the name of the resource group, along with the region and pricing tier.

After the CDN profile is created, add an endpoint to the profile. Add an Endpoint by opening the CDN profile in the portal and click the + Endpoint button. On the creation dialog, specify a unique name for the CDN endpoint, and the configuration for the origin settings, including the type (Storage, Web App, Cloud Service, or Custom), the host header and the origin port for HTTP and HTTPS), and then click the Add button. Figure 2-26 shows an endpoint using an Azure Storage account as the origin type. An endpoint can also be created when creating the CDN profile, and also directly from the blob storage settings of a storage account.

Blobs stored in public access enabled containers are cached in the CDN edge endpoints. To access the content via the CDN, instead of directly from your storage account, change the URL used to access the content to reference the CDN endpoint, as shown in the following example:

• Original URL within storage:

  • http://storageaccount.blob.core.windows.net/imgs/logo.png

• New URL accessed through CDN:

  • http://examrefcdn-blob.azureedge.net/imgs/logo.png

How the Azure CDN Works

Figure 2-27 shows how CDN caching works at a high level. In this example, the file logo.png has been hosted in blob storage in West US. A user in the UK can access the file, but due to the physical distance, the user experiences a high latency which slows down their browsing experience.

To address this, a CDN endpoint is deployed, using the blob storage account as the origin. To access the logo.png from the CDN, the URL for the file is changed from http://storageaccount.blob.core.windows.net/imgs/logo.png to http://examrefcdnh.azureedge.net/imgs/logo.png.

The CDN provides a worldwide network of caching servers. Users accessing the ‘examrefcnd.azureedge.net’ domain are automatically routed to their closest available server cluster, providing low-latency access to the CDN.

When a request for logo.png is received by a CDN server, the server checks to see if the file is available in its local cache. If not, this is called a cache miss, and the CDN will retrieve the file from the origin. The file is then cached locally and returned to the client. Subsequent requests for the same file will result in a ‘cache hit’, and the cached file is returned to the client directly from the CDN, avoiding a round-trip to the origin.

This local caching provides for lower latency and a faster browsing experience for the user.

Cache duration

Content is cached by the CDN until its time-to-live (TTL) elapses. The TTL is determined by the Cache-Control header in the HTTP response from the origin server. You can set the Cache-Control header programmatically in web apps by specifying it in the HTTP header. This setting can be set programmatically when serving up the content, or by setting the configuration of the web app.

You can manage the content expiration directly for blobs served directly from an Azure storage account by setting the time-to-live (TTL) period of the blob itself. Figure 2-28 demonstrates how to use Storage Explorer to set the CacheControl property on the blob files directly. You can also set the property using Windows PowerShell or the CLI tools when uploading to storage.

You can also control the TTL for your blobs using the Azure portal depending on the type of CDN endpoint created (see https://docs.microsoft.com/azure/cdn/cdn-features to compare the different SKU feature sets). In Figure 2-29 you can see the options for setting the cache duration of the Standard Verizon CDN endpoint.

Versioning assets using query string parameters

To permanently remove content from the Azure CDN, it should first be removed from the origin servers. If the content is stored in storage, you can set the container to private, or delete the content from the container, or even delete the container itself. If the content is in an Azure web app, you can modify the application to no longer serve the content.

Keep in mind that even if the content is deleted from storage, or if it is no longer accessible from your web application, cached copies may remain in the CDN endpoint until the TTL has expired. To immediately remove it from the CDN, purge the content as shown in Figure 2-30.

Purging content is also used when the content in the origin has changed. Purging the CDN cache of the old content means the CDN will pick up the new content from the origin when the next request for that content is received.

Using query strings is another technique for controlling information cached in the CDN. For instance, suppose your application hosted in Azure cloud services or Azure web apps has a page that generates content dynamically, such as: http://[CDN Endpoint].azureedge.net/chart.aspx. You can configure query string handling to cache multiple versions, depending on the query string that is passed in. The Azure CDN supports three different modes of query string caching:

• Ignore query strings This is the default mode. The CDN edge node will pass the query string from the requestor to the origin on the first request and cache the asset. All subsequent requests for that asset that are served from the edge node will ignore the query string until the cached asset expires.

• Bypass caching for URL with query strings In this mode, requests with query strings are not cached at the CDN edge node. The edge node retrieves the asset directly from the origin and passes it to the requestor with each request.

• Cache every unique URL This mode treats each request with a query string as a unique asset with its own cache. For example, the response from the origin for a request for foo.ashx?q=bar is cached at the edge node and returned for subsequent caches with that same query string. A request for foo.ashx?q=somethingelse is cached as a separate asset with its own time to live.

Configuring custom domains for storage and CDN

Both an Azure storage account and an Azure CDN endpoint allow you to specify a custom domain for accessing blob content instead of using the default domain name (<account name>. blob.core.windows.net). To configure either service, you must create a new CNAME record with the DNS provider that is hosting your DNS records.

For example, to enable a custom domain blobs.contoso.com foran Azure storage account, create a CNAME record that points from blobs.contoso.com to the Azure storage account [storage account].blob.core.windows.net. Table 2-10 shows an example mapping in DNS.

Table 2-9 Mapping a domain to an Azure Storage account in DNS

Table 2-10 Mapping a domain to an Azure Storage account in DNS with the asverify intermediary domain

Mapping a domain that is already in use within Azure may result in minor downtime as the DNS entry must be updated before it is registered with the storage account. If necessary, you can avoid the downtime by using a second option to validate the domain. In this approach, you create the DNS record asverify.<your domain> to verify your ownership of your domain, allowing you to register your domain with your storage account without impacting your application. You can then modify the DNS record for your domain to point to the storage account. Because the domain name is already registered with the storage account, traffic will be accepted immediately, avoiding any downtime. The asverify record can then be deleted.

Table 2-11 shows the example DNS records created when using the asverify method.

Table 2-11 Mapping a domain to an Azure CDN endpoint in DNS

To enable a custom domain for an Azure CDN endpoint, the process is almost identical. Create a CNAME record that points from cdn.contoso.com to the Azure CDN endpoint [CDN endpoint]. azureedge.net. Table 2-12 shows mapping a custom CNAME DNS record to the CDN endpoint.

Table 2-12 Mapping a domain to an Azure CDN endpoint in DNS with the cdn intermediary domain

The cdnverify intermediate domain can be used just like asverify for storage. Use this intermediate validation if you’re already using the domain with an application because updating the DNS directly can result in downtime. Table 2-13 shows the CNAME DNS records needed for verifying your domain using the cdnverify subdomain.

After the DNS records are created and verified you then associate the custom domain with your CDN endpoint or blob storage account.

Creating an Azure File Share (Azure portal)

To create a new Azure File using the Azure portal, open a Standard Azure storage account (Premium is not supported), click the Files link, and then click the + File Share button. On the dialog shown in figure 2-32, you must provide the file share name and the quota size, which can go up to 5120 GB.

Creating an Azure File Share (PowerShell)

To create a share, first create an Azure Storage context object using the New-AzStorageContext cmdlet. This cmdlet requires the name of the storage key, and the access key for the storage account, which is retrieved by calling the Get-AzStoragerAccountKey cmdlet or copying it from the Azure portal. Pass the context object to the New-AzStorageShare cmdlet along with the name of the share to create, as the next example shows.

To create a share using the Azure PowerShell cmdlets, use the following code:

Click here to view code image

$storageAccount = "[storage account]" 
$rgName = "[resource group name]" 
$shareName = "contosoweb" 
$storageKey = Get-AzStorageAccountKey `
     -ResourceGroupName $rgName `
     -Name $storageAccount 
$ctx = New-AzStorageContext -StorageAccountName $storageAccount `
                               -StorageAccountKey $storageKey.Value[0] 
New-AzStorageShare -Name $shareName -Context $ctx

Creating an Azure File Share (CLI)

To create an Azure File Share using the CLI, first retrieve the connection string using the az show connection string command, and pass that value to the az storage share create command, as the following example demonstrates.

Click here to view code image

rgName="[resource group name]" 
storageAccountName="[storage account]" 
shareName="contosoweb" 
constring=$(az storage account show-connection-string -n $storageAccountName 
-g $rgName --query 'connectionString' -o tsv) 
az storage share create --name $shareName --quota 2048 --connection-string $constring

Connecting to Azure File Service outside of Azure

Because Azure File Service provides support for SMB 3.0 it is possible to connect directly to an Azure File Share from a computer running outside of Azure. In this case, remember to open outbound TCP port 445 in your local network. Some Internet service providers may block port 445, so check with your service provider for details if you have problems connecting.

Connect and mount with Windows File Explorer

There are several ways to mount an Azure File Share from Windows. The first is to use the Map network drive feature within Windows File Explorer. Open File Explorer and find the This PC Node in the explorer view. Right-click This PC, and you can then click the Map Network Drive option, as shown in Figure 2-33.

When the dialog opens, specify the following configuration options, as shown in Figure 2-34:

• Folder \[name of storage account].files.core.windows.net[name of share]

• Connect Using Different Credentials Checked

When you click Finish, you see another dialog like the one shown in Figure 2-35 requesting the user name and password to access the file share. The user name should be in the following format: Azure[name of storage account], and the password should be the access key for the Azure storage account.

Connect and mount with the net use command

You can also mount the Azure File Share using the Windows net use command as the following example demonstrates.

Click here to view code image

net use x \erstandard01.file.core.windows.netlogs /u:AZUREerstandard01
r21Dk4qgY1HpcbriySWrBxnXnbedZLmnRK3N49PfaiL1t3ragpQaIB7FqK5zbez/sMnDEzEu/dgA9Nq/W7IF4A==

Connect and mount with PowerShell

You can connect and mount an Azure File using the Azure PowerShell cmdlets. In this example, the storage account key is retrieved using the Get-AzStorageAccountKey cmdlet. The account key is the password to the ConvertTo-SecureString cmdlet to create a secure string, which is required for the PSCredential object. From there, the credentials are passed to the New-PSDrive cmdlet, which maps the drive.

Click here to view code image

$rgName = "[resource group name]"
$storageName = "[storage account name]"
$storageKey = (Get-AzStorageAccountKey -ResourceGroupName $rgName
-Name $storageName).Value[0]
$acctKey = ConvertTo-SecureString -String "$storageKey" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential
-ArgumentList "Azure$storageName", $acctKey
New-PSDrive -Name "Z" -PSProvider FileSystem -Root
"\$storageName.file.core.windows.net$shareName" -Credential $credential

Automatically reconnect after reboot in Windows

To make the file share automatically reconnect and map to the drive after Windows is rebooted, use the following command (ensuring you replace the place holder values):

Click here to view code image

cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE<storage-
account-name> /pass:<storage-account-key>

Connect and mount from Linux

Use the mount command (elevated with sudo) to mount an Azure File Share on a Linux virtual machine. In this example, the logs file share would be mapped to the /logs mount point.

Click here to view code image

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/logs /logs -o
vers=3.0,username=<storage-account-name>.,password=<storage-account
-key>,dir_mode=0777,file_mode=0777,sec=ntlmssp

Deploying the Azure File Sync agent

To add endpoints to your Azure File Sync Group you first need to register a server to the sync group by installing the Azure File Sync agent on each server. The agent can be downloaded from the Microsoft Download Center: https://go.microsoft.com/fwlink/?linkid=858257. The installer is pictured in Figure 2-38.

Prerequisites

• Internet Explorer Enhanced Security configuration must be disabled before installing the agent. It can be re-enabled after the initial install.

• Install the latest Azure PowerShell module on the server. See the following for installation instructions: https://go.microsoft.com/fwlink/?linkid=856959.

After the agent is installed, sign in with the Azure credentials for your subscription, as shown in Figure 2-39.

Next, register the server with the storage sync service, as shown in Figure 2-40.

Adding a server endpoint

After the server is registered, you must navigate back to the sync group in the Azure portal and click on Add Server Endpoint. In the registered server dropdown, you will find all the servers that have the agent installed and associated with this sync service.

Enable cloud tiering to only store frequently accessed files locally on the server while all your other files are stored in Azure files. This is an optional feature that is configured by a policy.

Figure 2-41 shows the blade in the Azure portal to add the server endpoint. Ensure that you are only synching the location to one sync group at a time and that the path entered exists on the server.

Agent installation and server registration

If you run into issues installing the storage sync agent run the following command to generate a log file that may give you better insight into what the failure is:

StorageSyncAgent.msi /l*v AFSInstaller.log

Agent installation fails on Active Director Domain Controller

If you try to install the sync agent on an Active Directory domain controller where the PDC role owner is on a Windows Server 2008R2 or below OS version, you may hit an issue where the sync agent will fail to install. To resolve this, transfer the PDC role to another domain controller running Windows Server 2012R2 or a more recent OS, then install sync.

This server is already registered error

If you need to move the server to a different sync group, or you are troubleshooting why the server does not appear in the list, you may receive the error “This server is already registered during registration.” Run the following commands from PowerShell to remove the server:

Click here to view code image

Import-Module "C:Program Files
AzureStorageSyncAgentStorageSync.Management.ServerCmdlets.dll"
Reset-StorageSyncServer

AuthorizationFailed or other permissions issues

If you receive errors creating a cloud endpoint that point to a permissions related problem, ensure that your user account has the following Microsoft.Authorization permissions:

• Read Get role definition

• Write Create or update custom role definition

• Read Get role assignment

• Write Create role assignment

The Owner and User Access Administrator roles both have the correct permissions.

Server endpoint creation fails, with this error: “MgmtServerJobFailed” (Error code: -2134375898)

This error occurs because you are enabling cloud tiering on the system volume. Cloud tiering is not supported on the system volume.

Server endpoint deletion fails, with this error: “MgmtServerJobExpired”

This error occurs because the sync service can no longer reach the server due to network connectivity or the server is just offline. See the following for details on removing servers that are no longer available: https://docs.microsoft.com/azure/storage/files/storage-sync-files-server-registration#unregister-the-server-with-storage-sync-service.

Unable to open server endpoint properties page or update cloud tiering policy.

This issue can occur if a management operation on the server endpoint fails. You can update the server endpoint configuration by executing the following PowerShell code from the server:

Click here to view code image

Import-Module "C:Program Files
AzureStorageSyncAgentStorageSync.Management.PowerShell.Cmdlets.dll"
# Get the server endpoint id based on the server endpoint DisplayName property
Get-AzureRmStorageSyncServerEndpoint `
    -SubscriptionId mysubguid `
    -ResourceGroupName myrgname `
    -StorageSyncServiceName storagesvcname `
    -SyncGroupName mysyncgroup
# Update the free space percent policy for the server endpoint
Set-AzureRmStorageSyncServerEndpoint `
    -Id serverendpointid `
    -CloudTiering true `
    -VolumeFreeSpacePercent 60

Server endpoint has a health status of “No Activity” or “Pending” and the server state on the registered server’s blade is “Appears offline”

This issue occurs when the Storage Sync Monitor process is not able to communicate with the Azure File Sync service. It could be caused by the process is not running, or a proxy or firewall is blocking communication. The following steps can help you resolve this issue:

• Ensure that the AzureStorageSyncMonitor.exe process is running by looking in Task Manager on the server. If it is not running try to restart the server or use Microsoft Update to update the Azure File Sync Agent.

• If the server is behind a firewall you can use the following code to set application specific proxy settings if you are using version 4.0.1.0 or later:

  Click here to view code image

  Import-Module "C:Program Files
  AzureStorageSyncAgentStorageSync.Management.ServerCmdlets.dll"
  Set-StorageSyncProxyConfiguration -Address <url> -Port <port number>
  -ProxyCredential <credentials>

• You can set machine-wide proxy settings for earlier versions. For more information on machine-wide proxy settings see the following:
  https://docs.microsoft.com/azure/storage/files/storage-sync-files-firewall-and-proxy#proxy.

• For troubleshooting firewalls, ensure that outbound port 433 (HTTPS) is open and the endpoints documented here are not blocked:
  https://docs.microsoft.com/azure/storage/files/storage-sync-files-firewall-and-proxy#firewall.

Server endpoint has a health status of “No Activity” and the server state on the registered servers blade is “Online”

This issue occurs because there is a delay when changes occur because the service is still scanning for changes. Wait for the job to complete and the status should change.

Monitoring synchronization health

Open the sync group in the Azure portal. A health indicator is displayed by each of the server endpoints with green indicating a healthy status. Click on the endpoint to drill in to see stats such as the number of files remaining, size, and any resulting errors.

Create a Recovery Services vault (Azure portal)

To create a Recovery Services vault from the Azure portal, click Create a resource, and in the marketplace search dialog box enter Backup and Site Recovery (OMS), and click the Backup And Site Recovery (OMS) option. Figure 2-43 shows the search box to find the service.

Within the marketplace page for Backup And Site Recovery (OMS), click Create. Enter the name of the vault and choose or create the resource group where it resides. Next, choose the region where you want to create the resource, and click Create as shown in Figure 2-44.

Create a Recovery Services vault (PowerShell)

To create a Recovery Services vault with PowerShell, start by creating the resource group it should reside in.

New-AzResourceGroup -Name 'ExamRefRG' -Location 'WestUS'

Next, create the vault.

Click here to view code image

New-AzRecoveryServicesVault -Name 'MyRSVault' -ResourceGroupName 'ExamRefRG' -Location
'WestUS'

The storage redundancy type should be set at this point. The options are Locally Redundant Storage or Geo Redundant Storage. It is a good idea to use Geo Redundant Storage when protecting IaaS virtual machines, because the vault must be in the same region as the VM being backed up. Having the only backup copy in the same region as the item being protected is not wise, so Geo Redundant storage gives you three additional copies of the backed-up data in the sister (paired) region.

Click here to view code image

$vault1 = Get-AzRecoveryServicesVault –Name 'MyRSVault'
Set-AzRecoveryServicesBackupProperties -Vault $vault1 -BackupStorageRedundancy
GeoRedundant

Create a Recovery Services vault (CLI)

To create a Recovery Services vault with CLI, start by creating the resource group it should reside in.

az group create --location $location --name 'ExamRefRG'

Next, create the vault.

Click here to view code image

az backup vault create --name 'MyRSVault' --resource-group 'ExamRefRG'
--Location 'WestUS'

Using a Backup Agent

There are different types of backup agents you can use with Azure Backup. There is the Microsoft Azure Recovery Services (MARS) agent, which is a stand-alone agent used to protect files and folders. There is also the DPM protection agent that is used with Microsoft Azure Backup Server and with System Center Data Protection Manager. Finally, there is the VMSnapshot extension that is installed on Azure VMs to allow snapshots to be taken for full VM backups. The deployment of the DPM protection agent can be automated with either the use of System Center Data Protection Manager or Azure Backup Server. The VMSnapshot or VMSnapshotLinux extensions are also automatically deployed by the Azure fabric controller. The remainder of this section focuses on deploying the MARS agent.

The MARS agent is available for install from within the Recovery Services vault. Click Backup under Getting Started. Under the Where Is Your Workload Running? drop-down menu, select On-Premises, and under What Do You Want To Backup?, choose Files And Folders. Next, click Prepare Infrastructure, and the Recovery Services agent is made available, as shown in Figure 2-45.

Notice there is only a Windows agent because the backup of files and folders is only supported on Windows computers. Click the link to download the agent. Before initiating the installation of the MARS agent, also download the vault credentials file, which is right under the download links for the Recovery Services agent. The vault credentials file is needed during the installation of the MARS agent.

During the MARS agent installation, a cache location must be specified. There must be free disk space within this cache location that is equal to or greater than five percent of the total amount of data to be protected. These configuration options are shown in Figure 2-46.

The agent needs to communicate to the Azure Backup service on the Internet, so on the next setup screen, configure any required proxy settings. On the last installation screen, any required Windows features are added to the system where the agent is being installed. After it is complete, the installation prompts you to Proceed to Registration, as shown in Figure 2-47.

Click Proceed to Registration to open the agent registration dialog box. Within this dialog box the vault credentials must be provided by browsing to the path of the downloaded file. The next dialog box is one of the most important ones. On the Encryption Settings screen, either specify a passphrase or allow the installation program to generate one. Enter this in twice, and then specify where the passphrase file should be saved. The passphrase file is a text file that contains the passphrase, so store this file securely.

After the agent is registered with the Azure Backup service, it can then be configured to begin protecting data.

In the last section, the MARS agent was installed and registered with the Azure Backup vault. Before data can be protected with the agent, it must be configured with settings such as, when the backups occur, how often they occur, how long the data is retained, and what data is protected. Within the MARS agent interface, click Schedule Backup to begin this configuration process.

Click to move past the Getting Started screen and click Add Items to add files and folders. Exclusions can also be set so that certain file types are not protected, as shown in Figure 2-48.

Next, schedule how often backups should occur. The agent can be configured to back up daily or weekly, with a maximum of three backups taken per day. Specify the retention you want, and the initial backup type (Over the network or Offline). Confirm the settings to complete the wizard. Backups are now scheduled to occur, but they can also be initiated at any time by clicking Back up now on the main screen of the agent. The dialog showing an active backup is shown in Figure 2-49.

To recover data, click the Recover Data option on the main screen of the MARS agent. This initiates the Recover Data Wizard. Choose which computer to restore the data to. Generally, this is the same computer the data was backed up from. Next, choose the data to recover, the date on which the backup took place, and the time the backup occurred. These choices comprise the recovery point to restore. Click Mount to mount the selected recovery point as a volume, and then choose the location to recover the data. Confirm the options selected and the recovery begins.

Backing up and Restoring an Azure Virtual Machine

In addition to the MARS agent and protecting files and folders with Azure Backup, it is also possible to back up IaaS virtual machines in Azure. This solution provides a way to restore an entire virtual machine, or individual files from the virtual machine, and it is quite easy to set up. To backup an IaaS VM in Azure with Azure backup, navigate to the Recovery Service vault and under Getting Started, click Backup. Select Azure as the location where the workload is running, and Virtual machine as the workload to backup and click Backup, as shown in Figure 2-50.

The next item to configure is the Backup policy. This policy defines how often backups occur and how long the backups are retained. The default policy accomplishes a daily backup at 06:00am and retains backups for 30 days. No more than one backup can be taken daily and a VM can only be associated with one policy at a time. It is also possible to configure custom Backup policies. In this example, a custom Backup policy is configured that includes daily, weekly, monthly, and yearly backups, each with their own retention values. Figure 2-51 shows the creation of a custom backup policy.

Next, choose the VMs to backup. Only VMs within the same region as the Recovery Services vault are available for backup.

After the VMs are selected, click Enable Backup, as shown in Figure 2-52.

When you click the Enable Backup button, behind the scenes the VMSnapshot (for Windows) or VMSnapshotLinux (for Linux) extension is automatically deployed by the Azure fabric controller to the VMs. This allows for snapshot-based backups to occur, meaning that first a snapshot of the VM is taken, and then this snapshot is streamed to the Azure storage associated with the Recovery Services vault. The initial backup is not taken until the day/time configured in the backup policy, however an ad-hock backup can be initiated at any time. To do so, navigate to the Protected Items section of the vault properties, and click Backup items. Then, click Azure Virtual Machine under Backup Management type. The VMs that are enabled for backup are listed here. To begin an ad-hock backup, right-click on a VM and select Backup Now, as shown in Figure 2-53.

Preview Features: Backup support for Azure Files and SQL Server in an Azure VM

Azure Backup also directly supports the ability to backup and restore data from Azure Files and SQL Server in an Azure virtual machine. These two features are currently in preview, but it is still a good idea to have a basic understanding of the capabilities as they may eventually appear on the exam.

When to use Azure Backup Server

Azure Backup Server is a stand-alone service that you install on a Windows Server operating system that stores the backed-up data in a Microsoft Azure Recovery Vault. Azure Backup Server inherits much of the workload backup functionality from Data Protection Manager (DPM). Though Azure Backup Server shares much of the same functionality as DPM, Azure Backup Server does not back up to tape and it does not integrate with System Center.

You should consider using Azure Backup server when you have a requirement to back up the following supported workloads:

• Windows Client

• Windows Server

• Linux Servers

• VMWare VMs

• Exchange

• SharePoint

• SQL Server

• System State and Bare Metal Recovery

Prerequisites

• Create an Azure Storage account that will contain the report related data.

• Create a Power BI account if you do not already have one at the following URL: https://powerbi.microsoft.com/landing/signin/. With this account you can view, customize, and create your own reports in the Power BI portal.

• Register the Microsoft.Insights resource provider for your subscription if it’s not already registered. To do this using the Azure portal navigate to All Services, Subscriptions, your subscription, then Resource Providers.

• After you enable the prerequisites, click Backup Reports, then Turn On Diagnostics to configure diagnostics for the recovery vault (Figure 2-54).

The diagnostics configuration allows you to storage diagnostics data in Azure Storage, Event Hubs or Log Analytics. In Figure 2-55 a storage account is selected and AzureBackupReport data is configured for 30 days retention.

Backup report data is not available until 24 hours after configuring the storage account.

View Reports in Power BI

After your data has synchronized you can then login to Power BI at the following URL: https://powerbi.microsoft.com/landing/signin/. After you are signed in, select Get Data and in the More Ways To Create Your Own Content section select Service Content Packs. Search for Azure Backup and then click Get It Now on the returned result.

After selecting Azure Backup, you will be prompted for the storage account name and key created in the previous step. Retrieve these from the Azure portal by navigating to your storage account blade, then Keys.

Having completed the Power BI configuration for Azure Backup, you can now navigate to Power BI to review the status of your backups (Figure 2-56).