Since Microsoft announced Azure Stack, excitement and interest has continued to grow among customers seeking to implement or augment a cloud computing operating model and business strategy.

To meet the demand for consultancy expertise, design sessions and proofs of concept at the Dell Technologies Customer Solution Centers have helped facilitate and accelerate the testing of Technical Preview 2. One of the first questions we always receive is “Where do we start so we can make informed decisions in the future?”

Based on our in-depth experience with Microsoft Azure Stack and our rich heritage with Fast Track Reference Architectures, CPS-Premium, and CPS-Standard based on the Windows Azure Pack and System Center, we believe that Azure Resource Manager (ARM) is the perfect place to start. The ARM model is essential to service deployment and management for both Azure and Azure Stack.  Using the ARM model, resources are organized into resource groups and deployed with JSON templates.

Since ARM templates are declarative files written in JSON, they are best created and shared within the context of a well-defined source control process.  We solution architects at the Solution Centers decided to define what this ARM template creation and source control process might look like within our globally distributed ecosystem of labs and data centers. We have shared some of our learning journey in two blog posts to help facilitate knowledge transfer and preparation.

Hopefully, these blogs will prove to be thought provoking, especially for IT professionals with limited exposure to infrastructure as code or source control processes.  Though we have depicted a manual source control process, we hope to evolve to a fully automated model using DevOps principles in the near future.  

Filling the Toolbox

Our first step was to choose the right tools for the job.  We agreed upon the following elements for creating and sharing our ARM templates:

  • Microsoft Visual Studio 2015 Community or Enterprise Editions - The flagship Microsoft IDE with fantastic features like a JSON Editor, seamless Azure SDK integration, and an extension for GitHub.  VS 2015 Enterprise Edition can be purchased or downloaded using a Visual Studio Subscription.  Community Edition can be downloaded for free.

  • GitHub account for creating and accessing public repositories - There are many great options for hosting development projects online including Microsoft Visual Studio Team Foundation Server.  GitHub seemed like an excellent choice for getting started with source control.  To get started with GitHub, GitHub Guides is the perfect place to start.

  • Azure subscription credentials - Needed to deploy our ARM templates to Microsoft Azure.

  • Azure Stack TP2 1-Node POC environment - Needed to deploy our ARM template to an Azure-inspired instance in our labs and data centers.

  • Azure Stack Tools downloaded from GitHub - A set of PowerShell modules and scripts that proved to be invaluable in working with Azure Stack TP2.

We used the Dell EMC recommended server for an Azure Stack TP2 1-Node POC environment which is the PowerEdge R630. With 2U performance packed into a compact 1U chassis, the PowerEdge R630 two-socket rack server delivers uncompromising density and productivity.  The recommended BOM can be found here:

Process Overview

After a few lively discussions about the high level process for creating and sharing our ARM templates, we felt that the following guideposts were a good place to start: 

  • First and foremost, carefully consider what problem we are trying to solve with the environment that will be deployed with the ARM template.  This is all about gathering requirements.  What type of performance will our application require?  Do we need to keep our application in close proximity to our data?  Do we need multiple types of environments like Test/DEV and Production? 
  • Craft a Visio diagram that depicts the application architecture.  We did a little digging and found a lot of great guidance on this subject.  Obviously, finding a link to the Visio Stencils themselves was key, but we also found a great site that provided examples of what the diagrams might look like.  We have provided a couple of these sites here:

  • Consult the AzureStack-QuickStart-Templates GitHub repositories for an appropriate solution.

  • Revise and test the ARM template to meet the requirements.  
  • Create the appropriate documentation for the template.

  • Inform other solution architects of the new template and invite them to deploy as-is or to make improvements using the recommended procedures outlined in these blogs.

Throughout the blog posts, original creators of templates will be referred to as the authors, and the contributors making enhancements to the templates will be referred to as collaborators.

Selecting Our First QuickStart ARM Template

One of the most powerful aspects of Microsoft Azure Stack is that it runs the same APIs as Microsoft Azure but on a customer's premises. Because of this, service providers are able to use the same ARM templates to deploy a service to both Azure Stack and Azure without modifications to the template. Only templates contained in the AzureStack-QuickStart-Templates GitHub repository have been created to deploy successfully to both Azure Stack TP2 and Azure. At this time, the templates in the Azure-QuickStark-Templates GitHub repository won't necessarily work with Azure Stack TP2 because not all Resource Providers (RP) from Azure are currently available on Azure Stack. 

For our first ARM template deployment in the Solution Center, we decided to keep it simple and select the non-HA Sharepoint template from AzureStack-QuickStart-Templates.  The diagram that follows depicts the end state of our test Sharepoint farm.  Sharepoint is a great example of an application that can be hosted by service providers and made available under a SaaS business model using Azure Stack. This gives customers a way to immediately consume all the collaboration features of Sharepoint from their trusted service provider without investing a great deal of time and effort to deploy it themselves. Other applications that service providers have hosted for customers include Microsoft Exchange and Microsoft Dynamics.


The specific template we selected was sharepoint-2013-non-ha.

Creating an Azure Resource Group Using Visual Studio

Once we selected which ARM template from GitHub we wanted to use for our first deployment, we needed to create a new Azure Resource Group project in Visual Studio on the author's laptop as depicted in the following screen print.

When creating the Resource Group, we checked the “Create directory for solution” and “Create new Git repository".  By creating a Git repository, authors are able to use version control while they are beginning work with the new ARM template on their local machine.  There are many great references online for getting started with Git in Visual Studio.  A few of us thought the following article was a good starting point:

We named the repository and associated directory chihostsp (short for "Chicago Hosted Sharepoint" since the author was in the Chicago Solution Center), which is the name that was also used for the Resource Group when it was deployed.  Then, we selected Azure Stack QuickStart from the Show templates from this location drop down. This exposed all the individual ARM templates in the AzureStack-QuickStart-Templates repository on GitHub. We selected sharepoint-2013-non-ha.

The content of the ARM template then appeared in Visual Studio.

We learned that it is important to refrain from modifying the structure of this template within the downloaded folder when just getting started – especially the Deploy-AzureResourceGroup PowerShell Script. This script deploys the newly designed Resource Group regardless of whether an Azure or Azure Stack Subscription is used. To ensure the success of a Resource Group deployment using this PowerShell script in Visual Studio, we added the necessary accounts and subscriptions into Visual Studio Cloud Explorer.  When properly configured, Cloud Explorer should look something like the following (we've blacked out part of our domain suffix in some of the screen prints going forward):

We found it desirable to test this new template from the author's machine before making any changes. To do this, we deployed the chihostsp Resource Group through Visual Studio to an Azure Stack TP2 Tenant Subscription. In the case of our lab environment, the name of the Azure Stack TP2 Tenant Subscription was FirstSubscription. We supplied the appropriate parameters when prompted. We found that many deployment failures that can occur were attributed to incorrect naming conventions on these parameters. We made sure to understand the legal resource naming conventions to ensure a successful deployment.

The sharepoint-2013-non-ha template included logic for working with the Azure Stack Key Vault.  For an introduction to the Azure Stack Key Vault, please see the following in the Azure Stack documentation:

When editing the following parameters, we clicked on the key vault icon for adminPassword in order to select the appropriate Key Vault for the FirstSubscription Tenant Subscription and supplied the Key Vault Secret.

After a successful deployment of the chihostsp Resource Group, the following was displayed in the Azure Stack Tenant Portal. (Note: Not all the resources deployed into the Resource Group are visible here).

We also made sure that the chihostsp Resource Group could also be successfully deployed to Azure.  Here is the final result of that deployment in the Azure Portal:

Committing a Change to the Local Git Repository

Since the azuredeploy.parameters.json file changed as part of deploying the chihostsp Resource Group, the author needed to commit the changes in Visual Studio to Git for proper version control. We definitely learned the importance of committing often to the local Git repository with any new project being developed in Visual Studio.  The next few screen prints from Visual Studio illustrate the process.

Final Thoughts

In the next blog post, we will show how the author shared the new chihostsp project using GitHub and proceeded to work with other solution architect collaborators.  Here is a link to Blog post 2 for convenience: