Microsoft Azure 101, Virtual Network Essentials

This Azure 101 series presents a set of core competencies of Microsoft Azure for IT professionals including: virtual network, storage, cloud service and virtual machines. In each topic, i walked through the specifics of processes and steps with screen-to-screen details of examined scenarios.

This post is specific to creating and configuring a Microsoft Azure virtual network.

Microsoft Azure Site Recovery (ASR) as Disaster Recovery (DR) Solutions for Businesses of All Sizes

No longer is DR a process too complex to implement and too expensive to afford. DR today is a realistic and achievable solution with manageable costs. With Microsoft Azure, IT can now implement relatively easily compared with what it was a few years ago a DR solution to restore IT capabilities at the same facility or across physical sites in a DR scenario.

Azure Site Recovery, or ASR, is a Microsoft solution to protect applications in DR scenarios by automating, monitoring and orchestrating the replication, failover and recovery of physical and virtual machines relevant to both Microsoft and VMware environments. As of February, 2015, there are five targeted ASR scenarios as listed below.


And each is with prescriptive guidance to step through the processes for building an associated DR solution. A replication coordinated by ASR can be directed to another on-premises datacenter, Azure or a hosting service provider without facing the financial commitment and implementing the technical complexities of building and managing a company-owned secondary location. The simplicity, automation, customizable recovery plans, health monitoring and orchestrated recovery and supported SLAs makes ASR a reliable DR solution that is readily available for businesses of all sizes.

To facilitate IT pros to assess ASR as a DR solution, this article highlights the following essentials.

  • First acquiring an Azure subscription
  • Starting with an ASR Recovery Vault
  • Familiarizing with the 5 Scenarios which ASR Manages, Automates and Orchestrates

First acquiring an Azure subscription

Microsoft Azure is a subscription-based public cloud offering and requires an active subscription to access her services. A free 30-day trial of an Azure subscription with $200 credit for deploying Azure services is available at


MSDN subscribers

For those who are active MSDN subscribers, an associated Azure subscription is already put in place. However, a subscriber first needs to activate the associated Azure subscription from the Account page once authenticated into MSDN subscriber web site at


Starting with an ASR Recovery Vault

Upon authenticated into Azure Management Portal,, either scroll down on the left navigation pane then click +NEW or simply click +NEW in the lower left corner of the black menu bar at the bottom to create a Recovery Vault. 


image image image image

A name and a region are the required two pieces of information. And upon creating a Recovery Vault, a Quick Start should appear. However if the Quick Start page does not automatically display itself instead it shows the name list, as shown in the last screen capture, click the arrow next to the vault name to bring up the dashboard. And as needed, click the little-blue-cloud-with-a-lightening icon which is the first one and next to DASHBOARD to bring up the Quick Start page, as illustrated below.

Quick Start Page

There is a Quick Start page on most, if not all, Azure services. This is an important reference with official guidance to implement/configure an associated service. The Quick Start page is readily available  by clicking the indicated icon i.e. the associated page tab.


Familiarizing with the 5 Scenarios which ASR Manages, Automates and Orchestrates

Notice on the Quick Start page, there are 5 site recovery scenarios available as shown above. To employ ASR as a DR solution, one should first get familiar with these scenarios and their associated processes and tasks. One direct and quick way to master ASR is to create various recovery vaults and follow the guidance of each scenario to experiment and assess the automation, replication and failover relevant to particular business requirements. Here I am including the Quick Start page of each of the five scenarios.






Closing Thoughts

Over the years, DR has remained a critical part in protecting business facing unplanned events overwhelming an entire business application or an IT facility. What has dramatically changed is the availability, readiness and affordability of a DR solution by employing cloud computing as an integral part. Businesses in all sizes can now implement a DR solution that is not only technically feasible and verifiable, but financially affordable and manageable as a subscribed service like ASR.

While recognizing this opportunity and the availability, reliability and readiness of a DR infrastructure is not longer an issue, IT now must validate business plans, develop ASR DR solutions and incorporate the ASR processes and operations into standard operating procedures. On a regular basis, simulate failovers to DR sites based on business scenarios to ensure DR readiness.

The good news is that Azure has done the heavy lifting by providing a DR infrastructure in cloud with on-demand accessibility and availability and wizard-driven processes to implement DR solutions based on business requirements. What IT must do now is to translate business DR requirements into configurations and processes by following what is presented in the ASR Quick Start page.

Azure Weekly Demo

Every Friday, there is a short online demo session on Microsoft Azure. You can register for it at It’s very focused and with just a few slides. Here’s my session on Jan. 9th, 2015 on creating a virtual network in Microsoft Azure. If you would like to evaluate Microsoft Azure, a 30-day free trial with $200 credit is available at

Changing Server Installation Option from Server Core to Server-Gui-Shell

This is a follow-up post of my earlier article of Features on Demand, where I also illustrated changing server installation options and developing minimal server footprint. In this post, I walked through the process of changing the server installation option from server core to server-gui-shell.

In this scenario, I installed a server core, as shown below, to a VM from the Windows Server 2012 R2 iso file, en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso, downloaded from MSDN. And later changed the server core installation to one with server-gui-shell, i.e. with a full server GUI using DISM online commands. The OS disk is 40 GB in size.

image image

The following displayed the c drive of a clean server core install. And the feature store is at c:\windows\winsxs as shown. Here I also included the command in the screen capture.

image image

The following are some highlights of a formatted output of the server features of a clean install of server core using a DISM online command.


Since the GUI components had a state of “disabled with payload removed”, I needed to pointed out the source to enable the GUI feature. Below, I first shared out the feature store, i.e. c:\windows\winsxs, with read access to everyone on the machine, named VMM, which is a full gui installation as the source.

image image

Then I ran the DISM online command to enable server-gui-shell as:

dism /online /enable-feature /featurename:server-gui-shell /source:\\vmm\winsxs /all

To include all dependencies, I used /all in the statement. Notice the default behavior of enabling a feature is to ultimately go to Windows Updates, if an installation source is not specified or the needed bits are not found. Remember to include /LimitAccess in the statement to prevent seeking Windows Updates, as needed.

This statement took a few moments to run and complete the statement since it’s a gigabyte operation.  After finishing enabling server-gui-shell, I did a dir on the feature store just to show the difference made by enabling the feature. Notice there were 4,006 directories added to the feature store by this enabling server-gui-shell operation.

image image

After reboot, I noticed I was not able to find Server Manager in the Apps page. Opening a command prompt, I typed and ran the statement, powershell “get-windowsfeature”, and interestingly none of the GUI components was enabled. This may be an anomaly. So I ran the statement, powershell “install-windowsfeature server-gui-shell” to install the gui shell again. I thought I would need to reboot, the operation ran successfully and did not require a reboot. I then saw Server Manager, PowerShell ISE, etc. Server Manager came up fine and all seemed back to normal apparently.


Finally, you may notice that the above operations do not work on a Hyper-V Server which is a free and dedicated stand-alone product with the hypervisor, Windows Server driver model, virtualization capabilities, and supporting components such as failover clustering. A Hyper-V Server however does not contain the set of features and roles as a Windows Server operating system which requires a purchased license.

Call to Action

  • Register at Microsoft Virtual Academy,, and work on the server track to better understand the roles and features of Windows Server 2012 R2.
  • Download Windows Server 2012 R2 trial from and evaluate the product.
  • Follow the Features on Demand series,, and assess a minimal server footprint based on your business requirements.

High Availability, Disaster Recovery, and Microsoft Azure

Both High Availability (HA) and Disaster Recovery (DR) have been essential IT topics. Fundamentally HA is about fault tolerance relevant to the availability of an examined subject like application, database, VMs, etc. While DR roots on the ability to resume operations in the aftermath of a catastrophic event. A fundamental difference of these two is that HA expects no down time and no data loss, while DR does. They are different issues and should be addressed separately.


For many IT shops, either HA or DR has been a high risk and high cost item. Both are essential to business continuity, while traditionally tough technical problems to solve with very significant and long-term commitments on resources. Not only they are technically challenging, but a continual cost-cutting which has become an IT standard practice in the past two decades makes purchasing hardware/software and constructing either HA or DR solution on premises further distant from IT’s financial and technical realties.

Sense of Urgency

Too often, the technical challenges and resource commitments overwhelm IT and turn HA and DR into academic discussions, or symbolic items on a project checklist. At the same time, information is rapidly exploding as internet, mobility and social-network are becoming integral in our daily lives and businesses. There are progressively more data to process and store. For many businesses, the needs for HA and DR is urgent for better managing risks. And continual availability and on-demand recoverability of IT are becoming increasingly critical.

This Is the Reality, Now

The good news is that the recent introduction of cloud computing has fundamentally changed how an HA or DR solution can be implemented. Microsoft Azure is a vivid example of HA and DR solutions with significantly reduced the required financial commitment and involved technical complexities. The traditional approach by establishing redundancy and acquiring a physical DR site with long-term resources and financial commitments is now largely replaced with consumable services which can be configured in minutes by mouse-clicking and with a manageable cost structure based on usage. HA and DR have become IT solutions which are financially realistic and technically feasible for businesses in all sizes.

HA, Redundancy, and Microsoft Azure LRS

HA is to eliminate a single point of failure of an examined component, an application for example. It denotes a strategy to employ redundancy such that a target application can and will continue being available without downtime while experiencing a failure of hosting hardware or software. There are various and well-developed HA solutions like a hyper-V host cluster using redundant hardware to eliminate a single point of failure of hosting OS or hardware, and an application cluster for eliminating a single point of failure by running the application in multiple VM instances with a synchronous state. Although HA implementations may vary, the fundamental principle nevertheless remains the same. HA expects neither downtime nor data loss while experiencing an outage of a target hardware or software.

HA has become dramatically simple in Microsoft Azure. Basically, all data written to disk in Microsoft Azure are kept at least in the so-called LRS, Locally Redundant Storage. LRS replicates a transaction synchronously to three different storage nodes across fault domains and upgrade domains within the same region for durability. In layman’s terms, Microsoft Azure by default maintains at least three copies of user data to achieve HA.

DR, Replication, and Microsoft Azure GRS

DR is about having a plan and backups in place to resume operations in the aftermath of a catastrophic event. Unplanned outage is assumed in a DR scenario, therefore some data loss is also expected. Notice that HA and DR are different business problems and addressed differently.

While both HA and DR are based on applying redundancy, i.e. a source and replicas, or multiple identical nodes of an examines component like application instance, databases, or VMs, there are however differences between the two. A DR solution generally employs replicas or backups, are implemented with asynchronous processes, and expects an outage of a source and with some data loss in transit while the outage occurs. While HA requires a logical representation with a real-time integrity using synchronous processes across all participating nodes, expects neither downtime nor data loss while experiencing an outage of a participating node.

For a critical workload, one approach of DR is to establish geo-replication to address an outage of an entire geographic area caused by a natural disaster, for example. The concern is that a catastrophic event may impact an entire geographic area causing a datacenter where a mission critical application is being hosted becomes unavailable for an extended period of time.


In Microsoft Azure, Geo Redundant Storage or GRS is the default and an optional setting, as shown above, while configuring a storage account. GRS will queue a transaction committed to LRS as an asynchronous replication to a secondary region, a few hundreds miles away from the primary region where a storage account is originated. At the secondary region, data is also stored in LRS, i.e. made durable by replicating it to three storage nodes.


Specifically, a Microsoft Azure storage account configured with GRS essentially maintains three replicas locally for high availability, and replicates the content and maintains three replicas at a secondary datacenter a few hundreds miles away for DR. So all are six copies, three locally and three remotely. All these are configured by one, yes one mouse click from a dropdown list while creating a storage account. The above is a conceptual model illustrated a data flow of GRS.

GRS replication has little performance impact on an application since application data are committed to LRS in real-time while replication to GRS is queued, i.e. asynchronously. A write to LRS is synchronous and in real-time, once committed, the changes are expected within 15 minutes to be asynchronously replicated to the secondary site.

For a RA-GRS storage account, in addition to one primary endpoint for read/write operations as it is in a GRS, there is also one secondary endpoint as read only becomes available as shown below. image

The cost implications of GRS or RA-GRS include the additional storage and the transmission costs for egress traffic, as applicable, of the secondary datacenter. Ingress traffic is free. And Microsoft Azure Storage SLA offers 99.9% availability and a cost calculator is also available.

Microsoft Azure Recovery Services

So far, much is about backing up or replicating data. To successfully restore, a DR plan must be put in place and ensure its availability upon a DR scenario in progress. Either placing a DR plan at a primary site where the source is or a secondary site where a replica stays has some issues and concerns.

Keeping a DR plan at the source site where all the resources are in place and on-the-job trainings seems logical. Or does it? DR is assuming a catastrophic event over an extended geographic areas where the source site is experiencing an outage. In such case, keeping a DR plan in the source site defeats the purpose.

Maintaining a DR plan at the secondary site is the choice then. In a DR scenario, a recovery site is to be brought on line within a expected period of time according to a DR plan, and having the DR plan right there and then at a recovery site makes all the sense. Or does it? This decision introduces a number of requirements including the physical readiness, the timeliness, and the financial implications on securing and maintaining a DR plan at a remote physical facility.

For a VMM server running on System Center 2012 SP1 or later, an idea, reliable and straightforward way is to use Azure Recovery Services to maintain a DR plan as shown below. And for any backup needs, using cloud as a backup site makes backing up and restoring data an anytime anywhere operation.


Azure Site Recovery Vault

This service essentially acts as the director of a DR process. It orchestrates and manages the protection and failover of VMs in clouds managed by Virtual Machine Manager 2012 SP1 or later. A noticeable advantage is the ability to test a recovery configuration, exercise a proactive failover and recovery, and automate recovery in the event of a site outage.

The SLA of Site Recovery Services is 99.9% availability to ensure a configured DR plan is always in place with expected updates. This is a DR solution that IT can implement, simulate, verify, bring online and be absolutely confident with the readiness.


Azure Backup Vault

This is a reliable, scalable and inexpensive data protection solution with zero capital investment and extremely low operational expense. Like other secure communication with Microsoft Azure, you will first upload a public certificate to Microsoft Azure. Then download the backup agent to register a target server with the backup vault. Then select what to be backed up. Both Microsoft Azure Backup SLA (99.9% availability) and cost calculator are available for better assessing the solution.

Closing Thoughts

Form an application’s view, HA is an on-going event while DR is an anticipation. HA and DR are different business problems and should be addressed differently. Nevertheless, Microsoft Azure provides a single platform to gracefully address HA with LRS, DR with GRS, and DR orchestration with Recovery Services, and all with published SLAs and a predictable cost structure. Going forward, IT pros can now include HA and DR as a reliable, scalable and relatively inexpensive proposition by employing Microsoft Azure as a solution platform.

Call to Action